From ghc-devs at haskell.org Fri Jun 1 00:19:41 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 00:19:41 -0000 Subject: [GHC] #9724: reexport IsList class from a trustworthy module In-Reply-To: <044.b4b824d4864a7071bef003961687614b@haskell.org> References: <044.b4b824d4864a7071bef003961687614b@haskell.org> Message-ID: <059.35afb69cb224804aae76979d2c22f253@haskell.org> #9724: reexport IsList class from a trustworthy module -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: SafeHaskell 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 kostmo): * cc: kostmo (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 03:34:37 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 03:34:37 -0000 Subject: [GHC] #15209: ~# is always in scope with TypeOperators Message-ID: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> #15209: ~# is always in scope with TypeOperators -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | 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: -------------------------------------+------------------------------------- When `TypeOperators` is turned on, `~#` comes into scope automatically. As far as I know, this extremely magical operator really isn't supposed to be in Haskell at all, but if it is, it should surely be hidden in `GHC.Magic` or `GHC.Prim` or some such. {{{#!hs {-# LANGUAGE GADTs, TypeOperators #-} foo :: a ~# Int -> () foo = () -- No arguments, because of a magical `Type`/`Constraint` swap or something. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 03:35:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 03:35:58 -0000 Subject: [GHC] #15209: ~# is always in scope with TypeOperators In-Reply-To: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> References: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> Message-ID: <060.fd99e433b95f68bc819b8723d0c88673@haskell.org> #15209: ~# is always in scope with TypeOperators -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by dfeuer): Also, if I define a `~#` type, it won't be used, because the parser picks up the magical one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 03:40:42 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 03:40:42 -0000 Subject: [GHC] #15209: ~# is always in scope with TypeOperators In-Reply-To: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> References: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> Message-ID: <060.9b99d91aa77e0f52b7c936a6039e9052@haskell.org> #15209: ~# is always in scope with TypeOperators -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by dfeuer): Note: this operator doesn't seem to appear ''anywhere'' in `ghc-prim` or `base`, which makes me suspect it's some sort of hold-over from external core. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 08:00:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 08:00:21 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.83cd8e05cdf536c7e9215c282da113f9@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.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 tdammers): Replying to [comment:13 goldfire]: > I actually proposed doing exactly that when working this out with Simon. The problem is that doing so would ruin error messages, because we could report errors only with respect to the expanded syntax, instead of what the user actually wrote. My gut feeling (by all means correct me if I'm wrong!) is that this would still amount to a more elegant solution, everything considered. We would have to extend `HsSyn` to retain the original (sugared) notation, and treat such annotated syntax specially when printing error messages, but as far as type checking etc. are concerned, I would expect this to be mostly transparent. Personally, I wouldn't even mind getting error messages in desugared form, but I can understand if others feel strongly about this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 08:26:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 08:26:05 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.4477c273ef0d14d06687bf6c826290e9@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.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 tdammers): Replying to [comment:16 simonpj]: > As a short term fix how bad would it be to make `-fdefer-type-errors` incompatible with GHCi? > > We could apply that fix to HEAD (until we fix this ticket properly) and perhaps even to 8.4.3. I wouldn't be surprised to find that this breaks someone's workflow. Maybe we could get some opinions on this from the community? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 09:35:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 09:35:20 -0000 Subject: [GHC] #15163: non coercion variable in coVarKindsTypesRole In-Reply-To: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> References: <048.b3dbe8c60de34c10b2c3141afc368cad@haskell.org> Message-ID: <063.f542c1c8a9b9d07fd01687a154a0cbec@haskell.org> #15163: non coercion variable in coVarKindsTypesRole -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.4 Component: Compiler (Type | Version: 8.5 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14732 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4725 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 10:51:03 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 10:51:03 -0000 Subject: [GHC] #15209: ~# is always in scope with TypeOperators In-Reply-To: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> References: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> Message-ID: <060.aee0ace58a0460599bced613c44f43a6@haskell.org> #15209: ~# is always in scope with TypeOperators -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I don't believe it's in scope automatically. At least, I tried compiling your example program, which failed with: {{{ GHCi, version 8.5.20180501: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:2:8: error: Not in scope: type constructor or class ‘~#’ | 2 | foo :: a ~# Int -> () | ^^^^^^^^ }}} However, this variant does compile: {{{#!hs {-# LANGUAGE GADTs, TypeOperators #-} import GHC.Prim foo :: a ~# Int -> () foo = () -- No arguments, because of a magical `Type`/`Constraint` swap or something. }}} So it appears that `(~#)` //is// hidden away in `GHC.Prim` already, which is somewhat less distressing. That being said, there a couple of other bizarre things about `(~#)`: 1. Given that it ends with `#`, you'd expect to need to enable `MagicHash` in order to be able to use it. But as the program above shows, that's not that case, and even more baffling is that enabling `MagicHash` actually causes the program to //fail// to parse: {{{#!hs {-# LANGUAGE GADTs, TypeOperators #-} {-# LANGUAGE MagicHash #-} import GHC.Prim foo :: a ~# Int -> () foo = () -- No arguments, because of a magical `Type`/`Constraint` swap or something. }}} {{{ $ /opt/ghc/head/bin/ghc Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Bug.hs:6:10: error: parse error on input ‘~#’ | 6 | foo :: a ~# Int -> () | ^^ }}} 2. Since `(~#)` has the following kind: {{{ λ> :k (~#) (~#) :: k0 -> k1 -> TYPE ('GHC.Types.TupleRep '[]) }}} You can't use it as a constraint: {{{#!hs {-# LANGUAGE GADTs, TypeOperators #-} import GHC.Prim foo :: a ~# Int => () foo = () }}} {{{ $ /opt/ghc/head/bin/ghc Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Bug.hs:5:8: error: • Expecting a lifted type, but ‘a ~# Int’ is unlifted • In the type signature: foo :: a ~# Int => () | 5 | foo :: a ~# Int => () | ^^^^^^^^ }}} At one point in time, this led me to (mistakenly) conclude that `(~#)` was functionally useless in source Haskell. But now I've discovered that that's not true! As David has shown in the original description, you can use `(~#)` to the left of an arrow, and //that brings in an unboxed equality constraint into scope//! For instance, this compiles: {{{#!hs {-# LANGUAGE GADTs, TypeOperators #-} import GHC.Prim foo :: a ~# b -> a -> b foo = id }}} All of this is quite surprising. Perhaps we should just remove access to `(~#)` until we come up with a better story for source-level unboxed equality? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 11:00:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 11:00:15 -0000 Subject: [GHC] #15177: Faulty instance termination check, with PolyKinds and/or TypeInType In-Reply-To: <046.c24a808ae6f672394489dfaa7b18ebab@haskell.org> References: <046.c24a808ae6f672394489dfaa7b18ebab@haskell.org> Message-ID: <061.8d2a4c051907d5aedce864a4225718bc@haskell.org> #15177: Faulty instance termination check, with PolyKinds and/or TypeInType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Instances 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: > When checking the [http://downloads.haskell.org/~ghc/master/users- > guide/glasgow_exts.html#instance-termination-rules Paterson conditions] > for termination an instance declaration, we check for the number of > "constructors and variables" in the instance head and constraints. > '''Question''': Do we look at > A. All the arguments, visible or invisible? > B. Just the visible arguments? > > I think both will ensure termination, provided we are consistent. > > A current bug in GHC means that we are not consistent. In particular in > `TcValidity.checkInstTermination` we see > {{{ > checkInstTermination tys theta > = check_preds theta > where > ... > head_size = sizeTypes tys > > ... > check pred > = case classifyPredType pred of > ... > -> check2 pred (sizeTypes $ filterOutInvisibleTypes > (classTyCon cls) tys) > }}} > Notice the `filterOutInvisibleTypes` in the context predicate, but not > for the `head_size`! Similarly in `sizePred` (which itself looks very ad > hoc; used only for 'deriving'). Moreover, `sizeTypes` itself does not do > the `filterOutInvisibleTypes` when it finds a `TyConApp`. > > Bottom line: GHC mostly uses Plan A, except for an inconsistent use of > Plan B at top level of `checkInstTermination` and `sizePred`. > > I tried doing it both ways and fell into a swamp. > > Fails plan A: > > * `rebindable/T5908` has `instance (Category w, ...) => Monad (WriterT w > m)`. With kind arguments this is actualy `instance (Category @(TYPE > LiftedRep) w, ...) => Monad (WriterT w m)`, and now the predicate in the > context and the head both ahve size 4. So under (B) this is OK but not > under (A). > * `deriving/should_compile/T11833` is similar > * So is `overloadedrecflds/should_run/hasfieldrun02`. > > Fails plan B > > * `polykinds/T12718` has `instance Prelude.Num a => XNum a`, where `XNum` > is poly-kinded. Under (A) this would be OK, but not under B. > > * `typecheck/should_compile/T14441` is tricky. Putting in explicit kinds > we have > {{{ > type family Demote (k :: Type) :: Type > -- Demote :: forall k -> Type > > type family DemoteX (a :: k) :: Demote k > -- DemoteX :: forall k. k -> Demote k > > data Prox (a :: k) = P > -- P :: forall k (a:k). Prox @k a > > type instance DemoteX P = P > -- type instance DemoteX (Prox @k a) (P @k @a) > -- = P @(Demote k) @(DemoteX @k a) > }}} > So the LHS has 2 visible constructors and variables, namely `DemoteX` > and `P`. But the type-family applications in the RHS also each have two > visible, e.g. `Demote` and `k` for `Demote k`. Confusingly, these > applications are hidden inside the invisible argument of `P`; but we > really must look at them to ensure termination. Aaargh. > > * `dependent/should_compile/T13910` is similar, but a lot more > complicated. > > Currently, because of the bug, these all pass. But I think it should be > possible to exploit the bug to defeat the termination check, so things > are not good at all. New description: When checking the [http://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#instance-termination-rules Paterson conditions] for termination an instance declaration, we check for the number of "constructors and variables" in the instance head and constraints. '''Question''': Do we look at A. All the arguments, visible or invisible? B. Just the visible arguments? I think both will ensure termination, provided we are consistent. A current bug in GHC means that we are not consistent. In particular in `TcValidity.checkInstTermination` we see {{{ checkInstTermination tys theta = check_preds theta where ... head_size = sizeTypes tys ... check pred = case classifyPredType pred of ... -> check2 pred (sizeTypes $ filterOutInvisibleTypes (classTyCon cls) tys) }}} Notice the `filterOutInvisibleTypes` in the context predicate, but not for the `head_size`! Similarly in `sizePred` (which itself looks very ad hoc; used only for 'deriving'). Moreover, `sizeTypes` itself does not do the `filterOutInvisibleTypes` when it finds a `TyConApp`. Bottom line: GHC mostly uses Plan A, except for an inconsistent use of Plan B at top level of `checkInstTermination` and `sizePred`. I tried doing it both ways and fell into a swamp. Fails plan A: * `rebindable/T5908` has `instance (Category w, ...) => Monad (WriterT w m)`. With kind arguments this is actually `instance (Category @(TYPE LiftedRep) w, ...) => Monad (WriterT w m)`, and now the predicate in the context and the head both have size 4. So under (B) this is OK but not under (A). * `deriving/should_compile/T11833` is similar * So is `overloadedrecflds/should_run/hasfieldrun02`. Fails plan B * `polykinds/T12718` has `instance Prelude.Num a => XNum a`, where `XNum` is poly-kinded. Under (A) this would be OK, but not under B. * `typecheck/should_compile/T14441` is tricky. Putting in explicit kinds we have {{{ type family Demote (k :: Type) :: Type -- Demote :: forall k -> Type type family DemoteX (a :: k) :: Demote k -- DemoteX :: forall k. k -> Demote k data Prox (a :: k) = P -- P :: forall k (a:k). Prox @k a type instance DemoteX P = P -- type instance DemoteX (Prox @k a) (P @k @a) -- = P @(Demote k) @(DemoteX @k a) }}} So the LHS has 2 visible constructors and variables, namely `DemoteX` and `P`. But the type-family applications in the RHS also each have two visible, e.g. `Demote` and `k` for `Demote k`. Confusingly, these applications are hidden inside the invisible argument of `P`; but we really must look at them to ensure termination. Aaargh. * `dependent/should_compile/T13910` is similar, but a lot more complicated. Currently, because of the bug, these all pass. But I think it should be possible to exploit the bug to defeat the termination check, so things are not good at all. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 11:02:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 11:02:39 -0000 Subject: [GHC] #15177: Faulty instance termination check, with PolyKinds and/or TypeInType In-Reply-To: <046.c24a808ae6f672394489dfaa7b18ebab@haskell.org> References: <046.c24a808ae6f672394489dfaa7b18ebab@haskell.org> Message-ID: <061.fc52a19f681eae4c1ffe2b1de8d1254d@haskell.org> #15177: Faulty instance termination check, with PolyKinds and/or TypeInType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Instances 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: > When checking the [http://downloads.haskell.org/~ghc/master/users- > guide/glasgow_exts.html#instance-termination-rules Paterson conditions] > for termination an instance declaration, we check for the number of > "constructors and variables" in the instance head and constraints. > '''Question''': Do we look at > A. All the arguments, visible or invisible? > B. Just the visible arguments? > > I think both will ensure termination, provided we are consistent. > > A current bug in GHC means that we are not consistent. In particular in > `TcValidity.checkInstTermination` we see > {{{ > checkInstTermination tys theta > = check_preds theta > where > ... > head_size = sizeTypes tys > > ... > check pred > = case classifyPredType pred of > ... > -> check2 pred (sizeTypes $ filterOutInvisibleTypes > (classTyCon cls) tys) > }}} > Notice the `filterOutInvisibleTypes` in the context predicate, but not > for the `head_size`! Similarly in `sizePred` (which itself looks very ad > hoc; used only for 'deriving'). Moreover, `sizeTypes` itself does not do > the `filterOutInvisibleTypes` when it finds a `TyConApp`. > > Bottom line: GHC mostly uses Plan A, except for an inconsistent use of > Plan B at top level of `checkInstTermination` and `sizePred`. > > I tried doing it both ways and fell into a swamp. > > Fails plan A: > > * `rebindable/T5908` has `instance (Category w, ...) => Monad (WriterT w > m)`. With kind arguments this is actually `instance (Category @(TYPE > LiftedRep) w, ...) => Monad (WriterT w m)`, and now the predicate in the > context and the head both have size 4. So under (B) this is OK but not > under (A). > * `deriving/should_compile/T11833` is similar > * So is `overloadedrecflds/should_run/hasfieldrun02`. > > Fails plan B > > * `polykinds/T12718` has `instance Prelude.Num a => XNum a`, where `XNum` > is poly-kinded. Under (A) this would be OK, but not under B. > > * `typecheck/should_compile/T14441` is tricky. Putting in explicit kinds > we have > {{{ > type family Demote (k :: Type) :: Type > -- Demote :: forall k -> Type > > type family DemoteX (a :: k) :: Demote k > -- DemoteX :: forall k. k -> Demote k > > data Prox (a :: k) = P > -- P :: forall k (a:k). Prox @k a > > type instance DemoteX P = P > -- type instance DemoteX (Prox @k a) (P @k @a) > -- = P @(Demote k) @(DemoteX @k a) > }}} > So the LHS has 2 visible constructors and variables, namely `DemoteX` > and `P`. But the type-family applications in the RHS also each have two > visible, e.g. `Demote` and `k` for `Demote k`. Confusingly, these > applications are hidden inside the invisible argument of `P`; but we > really must look at them to ensure termination. Aaargh. > > * `dependent/should_compile/T13910` is similar, but a lot more > complicated. > > Currently, because of the bug, these all pass. But I think it should be > possible to exploit the bug to defeat the termination check, so things > are not good at all. New description: When checking the [http://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#instance-termination-rules Paterson conditions] for termination an instance declaration, we check for the number of "constructors and variables" in the instance head and constraints. '''Question''': Do we look at A. All the arguments, visible or invisible? B. Just the visible arguments? I think both will ensure termination, provided we are consistent. A current bug in GHC means that we are not consistent. In particular in `TcValidity.checkInstTermination` we see {{{ checkInstTermination tys theta = check_preds theta where ... head_size = sizeTypes tys ... check pred = case classifyPredType pred of ... -> check2 pred (sizeTypes $ filterOutInvisibleTypes (classTyCon cls) tys) }}} Notice the `filterOutInvisibleTypes` in the context predicate, but not for the `head_size`! Similarly in `sizePred` (which itself looks very ad hoc; used only for 'deriving'). Moreover, `sizeTypes` itself does not do the `filterOutInvisibleTypes` when it finds a `TyConApp`. Bottom line: GHC mostly uses Plan A, except for an inconsistent use of Plan B at top level of `checkInstTermination` and `sizePred`. I tried doing it both ways and fell into a swamp. Fails plan A: * `rebindable/T5908` has `instance (Category w, ...) => Monad (WriterT w m)`. With kind arguments this is actually `instance (Category @* w, ...) => Monad (WriterT w m)`, and now the predicate in the context and the head both have size 4. So under (B) this is OK but not under (A). * `deriving/should_compile/T11833` is similar * So is `overloadedrecflds/should_run/hasfieldrun02`. Fails plan B * `polykinds/T12718` has `instance Prelude.Num a => XNum a`, where `XNum` is poly-kinded. Under (A) this would be OK, but not under B. * `typecheck/should_compile/T14441` is tricky. Putting in explicit kinds we have {{{ type family Demote (k :: Type) :: Type -- Demote :: forall k -> Type type family DemoteX (a :: k) :: Demote k -- DemoteX :: forall k. k -> Demote k data Prox (a :: k) = P -- P :: forall k (a:k). Prox @k a type instance DemoteX P = P -- type instance DemoteX (Prox @k a) (P @k @a) -- = P @(Demote k) @(DemoteX @k a) }}} So the LHS has 2 visible constructors and variables, namely `DemoteX` and `P`. But the type-family applications in the RHS also each have two visible, e.g. `Demote` and `k` for `Demote k`. Confusingly, these applications are hidden inside the invisible argument of `P`; but we really must look at them to ensure termination. Aaargh. * `dependent/should_compile/T13910` is similar, but a lot more complicated. Currently, because of the bug, these all pass. But I think it should be possible to exploit the bug to defeat the termination check, so things are not good at all. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 11:56:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 11:56:53 -0000 Subject: [GHC] #15177: Faulty instance termination check, with PolyKinds and/or TypeInType In-Reply-To: <046.c24a808ae6f672394489dfaa7b18ebab@haskell.org> References: <046.c24a808ae6f672394489dfaa7b18ebab@haskell.org> Message-ID: <061.c95b1ea70fe7f2ee71aa899caa6b9c61@haskell.org> #15177: Faulty instance termination check, with PolyKinds and/or TypeInType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Instances 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): Perhaps it would be too confusing, but we could conceivably run ''both'' checks. If either check passes, then the instance terminates, as we've found a decreasing metric. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 11:59:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 11:59:35 -0000 Subject: [GHC] #15209: ~# is always in scope with TypeOperators In-Reply-To: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> References: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> Message-ID: <060.2de7e8a0b5c3c60f650d3c857e96a122@haskell.org> #15209: ~# is always in scope with TypeOperators -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by goldfire): My vote: ban `~#` outright. But note that we shouldn't expect to need `MagicHash` here, because `~#` is a perfectly fine and ordinary operator name. Of course, `MagicHash` shouldn't ''stop'' it from parsing... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 12:03:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 12:03:14 -0000 Subject: [GHC] #12023: Problems getting information and kind from GHC.Prim ~#, ~R#, ... In-Reply-To: <051.e18556256e79a3a1dab6064a1d75c6d2@haskell.org> References: <051.e18556256e79a3a1dab6064a1d75c6d2@haskell.org> Message-ID: <066.00d5c64c83a17760a80b61eb788804d1@haskell.org> #12023: Problems getting information and kind from GHC.Prim ~#, ~R#, ... -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: #10059, #15209 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #10059, #15209 Comment: The fact that `:info` doesn't work for `(~)` is being tracked separately at #10059. I'm not surprised that `:info (~R#)` and `:info (~#P)` don't work, since I wouldn't expect users to be able to make use of these (see also #15209, which proposes to remove the ability to query `:info (~#)`.) It's a bit unfortunate that `:browse GHC.Prim` exposes `(~#)` and friends—perhaps we could alter `:browse` to avoid printing them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 12:03:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 12:03:59 -0000 Subject: [GHC] #10059: :i doesn't work for ~ In-Reply-To: <045.e4d34da19e8a219c9836208516141cc9@haskell.org> References: <045.e4d34da19e8a219c9836208516141cc9@haskell.org> Message-ID: <060.c0e85282215c004f34542d7e14382342@haskell.org> #10059: :i doesn't work for ~ -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10056, #12023 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #10056 => #10056, #12023 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 12:08:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 12:08:34 -0000 Subject: [GHC] #10059: :i doesn't work for ~ In-Reply-To: <045.e4d34da19e8a219c9836208516141cc9@haskell.org> References: <045.e4d34da19e8a219c9836208516141cc9@haskell.org> Message-ID: <060.d2c8e3d98e502d41c725e072518428cf@haskell.org> #10059: :i doesn't work for ~ -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10056, #12023 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): After some digging, it turns out that the reason this doesn't work is because the `identifier` parser production doesn't catch `(~)`. It turns out that this patch: {{{#!diff diff --git a/compiler/parser/Parser.y b/compiler/parser/Parser.y index c6face8..06a5722 100644 --- a/compiler/parser/Parser.y +++ b/compiler/parser/Parser.y @@ -629,6 +629,8 @@ identifier :: { Located RdrName } | qconop { $1 } | '(' '->' ')' {% ams (sLL $1 $> $ getRdrName funTyCon) [mj AnnOpenP $1,mu AnnRarrow $2,mj AnnCloseP $3] } + | '(' '~' ')' {% ams (sLL $1 $> $ eqTyCon_RDR) + [mop $1,mj AnnTilde $2,mcp $3] } ----------------------------------------------------------------------------- -- Backpack stuff }}} Is enough to make `:info (~)` go through: {{{ λ> :info (~) class (a ~ b) => (~) (a :: k) (b :: k) -- Defined in ‘Data.Type.Equality’ instance [incoherent] forall k (a :: k) (b :: k). (a ~ b) => a ~ b -- Defined in ‘Data.Type.Equality’ }}} (The pretty-printing of the class definition of `(~)` is gnarly, though—I'm still figuring out how to work around that.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 13:08:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 13:08:47 -0000 Subject: [GHC] #15209: ~# is always in scope with TypeOperators In-Reply-To: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> References: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> Message-ID: <060.bd6d223bf1ded4d8c9c089ccc3ce7ffc@haskell.org> #15209: ~# is always in scope with TypeOperators -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by dfeuer): I was wrong about it coming into scope automatically. Sorry for the confusion. I definitely think this should be removed from the parser unless and until we have a proper story for unboxed coercions in Haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 14:03:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 14:03:15 -0000 Subject: [GHC] #15210: Use ByteStrings for strings that don't use FastString's features Message-ID: <046.760618d6d6e6b869eb15814a74e0928c@haskell.org> #15210: Use ByteStrings for strings that don't use FastString's features -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Keywords: performance, | Operating System: Unknown/Multiple strings | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15157 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The first two candidates that I have in mind are SourceText and StringLiteral's sl_fs field. There might be a point in creating a simple wrapper for UTF8-encoded ByteString. HsDocString could use that one too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 14:17:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 14:17:44 -0000 Subject: [GHC] #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 In-Reply-To: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> References: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> Message-ID: <061.4f3ce33414006ee900ed0950ba4e2783@haskell.org> #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.2.3 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 gbaz): * cc: gbaz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 14:22:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 14:22:35 -0000 Subject: [GHC] #6089: Allow declaration splices inside declaration brackets In-Reply-To: <044.85bbefd435d2792cc792b502a5ebe47e@haskell.org> References: <044.85bbefd435d2792cc792b502a5ebe47e@haskell.org> Message-ID: <059.a60c6c8d0cb237b22396fabdbcf47e96@haskell.org> #6089: Allow declaration splices inside declaration brackets -------------------------------------+------------------------------------- Reporter: igloo | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gbaz): * cc: gbaz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 14:29:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 14:29:35 -0000 Subject: [GHC] #6089: Allow declaration splices inside declaration brackets In-Reply-To: <044.85bbefd435d2792cc792b502a5ebe47e@haskell.org> References: <044.85bbefd435d2792cc792b502a5ebe47e@haskell.org> Message-ID: <059.0ab815239b5aa50778a6ae7dd39bb868@haskell.org> #6089: Allow declaration splices inside declaration brackets -------------------------------------+------------------------------------- Reporter: igloo | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gbaz): * cc: gbaz (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 14:44:08 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 14:44:08 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails In-Reply-To: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> References: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> Message-ID: <065.789d16a949d7903f32158e7e7f1c4993@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, CUSKs 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): Simon says: when there is a CUSK, quantify over any free kind variables. Example at the term level {{{ f :: forall (a :: Proxy k). Proxy a -> Int }}} Then we infer (notice the `k2`): {{{ f :: forall k2 (k :: k2). forall (a :: Proxy k). Proxy a -> Int }}} So similarly at tke type level if we have this CUSK {{{ data T (a :: Proxy k) :: Proxy a -> Type where ... }}} we should quantify over the kind to get {{{ T :: forall k2 (k :: k2). forall (a :: Proxy k). Proxy a -> Type }}} This would require changing code in the CUSK case of `kcLHsQTyVars`, which currently calls `report_non_cusk_tvs` to complain. Instead, generalise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 14:53:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 14:53:48 -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.ef25e9f065be7718e91401df0100f302@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.6.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: #7258 | Differential Rev(s): Phab:D3399, Wiki Page: | Phab:D3400, Phab:D3421 -------------------------------------+------------------------------------- Changes (by gbaz): * cc: gbaz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 14:54:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 14:54:47 -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.9d48a34b1fd18e5c36b67e054527b4a1@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.6.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: #7258 | Differential Rev(s): Phab:D3399, Wiki Page: | Phab:D3400, Phab:D3421 -------------------------------------+------------------------------------- Changes (by gbaz): * cc: gbaz (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 15:42:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 15:42:59 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.15b221d882c10617e4c8c47c03a58fa2@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.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 elaforge): Surely those people's workflows are already broken by the fact that you can't evaluate much of anything without causing a panic. If they are just loading the modules to check types and not actually running them, then they don't need `-fdefer-type-errors` in the first place. So if someone's tool is thrown by an extra warning msg, they can probably just remove the flag. I also think it's reasonable to expect tools to be robust against unexpected messages at startup before the prompt comes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 18:18:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 18:18:47 -0000 Subject: [GHC] #15211: exprFreeVars does not include type variables Message-ID: <047.2d30bc163a3c3f3a1e1fc1344efb9efd@haskell.org> #15211: exprFreeVars does not include type variables -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- The `exprFreeVars` function returns the free variables of an expression. However, this function doesn't include the type variables free in the free term variables. This might be OK for some uses, but it seems ''not'' OK if we use the result of `exprFreeVars` in an `InScopeSet`, which is done in many places. I don't have a program that exhibits misbehavior, but I feel fairly sure that we have a problem here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 19:30:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 19:30:26 -0000 Subject: [GHC] #15209: ~# is always in scope with TypeOperators In-Reply-To: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> References: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> Message-ID: <060.653ec54d043352b3ed2405e73991ceb0@haskell.org> #15209: ~# is always in scope with TypeOperators -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4763 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4763 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 19:42:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 19:42:38 -0000 Subject: [GHC] #15212: powerpc64le-unknown-linux is missing from llvm-targets Message-ID: <045.5d6d39c8631e163a5e27c5b5cbbf3073@haskell.org> #15212: powerpc64le-unknown-linux is missing from llvm-targets ---------------------------------+--------------------------------- Reporter: admock | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+--------------------------------- T5681 fails with: Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180531 for powerpc64le-unknown-linux): Failed to lookup the datalayout for powerpc64le-unknown-linux; available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64 -unknown-windows","arm-unknown-linux-gnueabihf","armv6-unkno wn-linux-gnueabihf","armv6l-unknown-linux-gnueabihf","armv7-unknown-linux- gnueabihf","armv7a-unknown-linux-gnueabi","armv7l-unknown-linux- gnueabihf","aarch64-unknown-linux-gnu","aarch64-unknown-linux","i3 86-unknown-linux-gnu","i386-unknown-linux","x86_64-unknown-linux- gnu","x86_64-unknown-linux","armv7-unknown-linux-androideabi","aarch64 -unknown-linux-android","arm-unknown-nto-qnx-eabi","i386-apple-darwin ","x86_64-apple-darwin","armv7-apple-ios","aarch64-apple-ios","i386-apple- ios","x86_64-apple-ios"] CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen.hs:96:24 in ghc:LlvmCodeGen 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 Fri Jun 1 19:57:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 19:57:49 -0000 Subject: [GHC] #15213: 32 bit Haddock runs out of memory compiling 32 bit GHC Message-ID: <044.953b3633442fb5d6beadb7e79e6f44ca@haskell.org> #15213: 32 bit Haddock runs out of memory compiling 32 bit GHC --------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------- Final parts of stage2 fails with {{{ Warning: DriverBkp: could not find link destinations for: BkpEnv BkpM backpackProgressMsg haddock.exe: Out of memory make[1]: *** [compiler/ghc.mk:448: compiler/stage2/doc/html/ghc/ghc.haddock] Error 251 make: *** [Makefile:127: all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 19:58:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 19:58:19 -0000 Subject: [GHC] #15213: 32 bit Haddock runs out of memory compiling 32 bit GHC In-Reply-To: <044.953b3633442fb5d6beadb7e79e6f44ca@haskell.org> References: <044.953b3633442fb5d6beadb7e79e6f44ca@haskell.org> Message-ID: <059.4a83655a017ad3a769a0c962bf483079@haskell.org> #15213: 32 bit Haddock runs out of memory compiling 32 bit GHC ----------------------------------------+------------------------------ Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by Phyx-): * failure: None/Unknown => Building GHC failed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 23:39:30 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 23:39:30 -0000 Subject: [GHC] #15214: Redefining (~) yields a baffling error message Message-ID: <050.3974773989d33b480bdee6d95a089f76@haskell.org> #15214: Redefining (~) yields a baffling error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Running this code: {{{#!hs {-# LANGUAGE TypeOperators #-} module Bug where type (~) = Either }}} Yields a rather strange error: {{{ $ /opt/ghc/8.4.3/bin/ghci Bug2.hs GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug2.hs, interpreted ) Bug2.hs:4:1: error: Cannot redefine a Name retrieved by a Template Haskell quote: ~ | 4 | type (~) = Either | ^^^^^^^^^^^^^^^^^ }}} Since Template Haskell certainly isn't involved here. The culprit is that `(~)` isn't listed within `isBuiltInOcc_maybe`. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 1 23:42:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Jun 2018 23:42:39 -0000 Subject: [GHC] #15214: Redefining (~) yields a baffling error message In-Reply-To: <050.3974773989d33b480bdee6d95a089f76@haskell.org> References: <050.3974773989d33b480bdee6d95a089f76@haskell.org> Message-ID: <065.dbd89b5fec4b39dd0dd769dbb174a344@haskell.org> #15214: Redefining (~) yields a baffling error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4768 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4768 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 2 03:00:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jun 2018 03:00:06 -0000 Subject: [GHC] #15210: Use ByteStrings for strings that don't use FastString's features In-Reply-To: <046.760618d6d6e6b869eb15814a74e0928c@haskell.org> References: <046.760618d6d6e6b869eb15814a74e0928c@haskell.org> Message-ID: <061.9689d42e26400549927e7201dc637df1@haskell.org> #15210: Use ByteStrings for strings that don't use FastString's features -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: performance, | strings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15157 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Note that we also have `LitString` for literal strings. Otherwise I agree that a newtype-wrapped UTF-8 `ByteString` would make sense here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 2 04:01:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jun 2018 04:01:22 -0000 Subject: [GHC] #12939: ghc-8.0.1.20161117 did not install ghc.1 manpage In-Reply-To: <050.1a6f83d836fa085ef75b0067487924cd@haskell.org> References: <050.1a6f83d836fa085ef75b0067487924cd@haskell.org> Message-ID: <065.872285d916da8e7422f82862c840b8df@haskell.org> #12939: ghc-8.0.1.20161117 did not install ghc.1 manpage ---------------------------------+---------------------------------------- Reporter: juhpetersen | Owner: bgamari Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Build System | Version: 8.0.2-rc1 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 juhpetersen): "Mystery" resolved!: I had "BUILD_MAN=yes" instead of "BUILD_MAN=YES" in build.mk, doh. Of course it might be better not to care about case (eg build fails completely with HADDOCK_DOCS=yes). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 2 04:03:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jun 2018 04:03:56 -0000 Subject: [GHC] #12939: ghc-8.0.1.20161117 did not install ghc.1 manpage In-Reply-To: <050.1a6f83d836fa085ef75b0067487924cd@haskell.org> References: <050.1a6f83d836fa085ef75b0067487924cd@haskell.org> Message-ID: <065.d81a17ba1c4635f6f75765da17b4b650@haskell.org> #12939: ghc-8.0.1.20161117 did not install ghc.1 manpage ---------------------------------+---------------------------------------- Reporter: juhpetersen | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.2-rc1 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 juhpetersen): * status: infoneeded => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 2 05:12:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jun 2018 05:12:06 -0000 Subject: [GHC] #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented In-Reply-To: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> References: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> Message-ID: <061.92366df0a483cff127a51127a3c300b2@haskell.org> #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Azel Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.2 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:D4736 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Azel): Continuing on that vein, I think `Integral` instances are expected to form Euclidean rings (or is it Euclidean fields?). However, I have no idea for `RealFrac` instances…subsets of ℚ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 2 08:04:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jun 2018 08:04:14 -0000 Subject: [GHC] #15193: QSem makes nonsense claim In-Reply-To: <045.c822f45289d183bc488d863511958b32@haskell.org> References: <045.c822f45289d183bc488d863511958b32@haskell.org> Message-ID: <060.ee54da7cefa1cd74a4bcb80bd4edd70a@haskell.org> #15193: QSem makes nonsense claim -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: 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 simonmar): "first in" has a perfectly reasonable meaning: the execution of the program corresponds to some unspecified interleaving that sequentialises the operations, and you can define first-in using that ordering. Yes you can construct programs where the ordering is non-deterministic, but you can also construct programs where the ordering is deterministic, and in those cases the FIFO ordering property is useful to the programmer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 2 12:21:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jun 2018 12:21:42 -0000 Subject: [GHC] #14164: GHC hangs on type family dependency In-Reply-To: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> References: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> Message-ID: <066.ec354e991344a9d7aff80af4ca4d10a9@haskell.org> #14164: GHC hangs on type family dependency -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | InjectiveFamilies 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 somewhat smaller example that also loops at compile-time: {{{#!hs {-# LANGUAGE TypeFamilyDependencies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where data G (x :: a) = GNil | GCons (G x) type family F (xs :: [a]) (g :: G (z :: a)) = (res :: [a]) | res -> a where F (x:xs) GNil = x:xs F (x:xs) (GCons rest) = x:F xs rest }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 2 18:22:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jun 2018 18:22:38 -0000 Subject: [GHC] #15212: powerpc64le-unknown-linux is missing from llvm-targets In-Reply-To: <045.5d6d39c8631e163a5e27c5b5cbbf3073@haskell.org> References: <045.5d6d39c8631e163a5e27c5b5cbbf3073@haskell.org> Message-ID: <060.ba34d09375265e1d275730b40b563015@haskell.org> #15212: powerpc64le-unknown-linux is missing from llvm-targets ---------------------------------+---------------------------------- Reporter: admock | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4765 Wiki Page: | ---------------------------------+---------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4765 Old description: > T5681 fails with: > > Compile failed (exit code 1) errors were: > ghc-stage2: panic! (the 'impossible' happened) > (GHC version 8.5.20180531 for powerpc64le-unknown-linux): > Failed to lookup the datalayout for powerpc64le-unknown-linux; > available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64 > -unknown-windows","arm-unknown-linux-gnueabihf","armv6-unkno > wn-linux-gnueabihf","armv6l-unknown-linux-gnueabihf","armv7-unknown- > linux-gnueabihf","armv7a-unknown-linux-gnueabi","armv7l-unknown-linux- > gnueabihf","aarch64-unknown-linux-gnu","aarch64-unknown-linux","i3 > 86-unknown-linux-gnu","i386-unknown-linux","x86_64-unknown-linux- > gnu","x86_64-unknown-linux","armv7-unknown-linux-androideabi","aarch64 > -unknown-linux-android","arm-unknown-nto-qnx-eabi","i386-apple-darwin > ","x86_64-apple-darwin","armv7-apple-ios","aarch64-apple-ios","i386 > -apple-ios","x86_64-apple-ios"] > CallStack (from HasCallStack): > error, called at compiler/llvmGen/LlvmCodeGen.hs:96:24 in > ghc:LlvmCodeGen > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug New description: T5681 fails with: {{{ Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180531 for powerpc64le-unknown-linux): Failed to lookup the datalayout for powerpc64le-unknown-linux; available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64 -unknown-windows","arm-unknown-linux-gnueabihf","armv6-unkno wn-linux-gnueabihf","armv6l-unknown-linux-gnueabihf","armv7-unknown-linux- gnueabihf","armv7a-unknown-linux-gnueabi","armv7l-unknown-linux- gnueabihf","aarch64-unknown-linux-gnu","aarch64-unknown-linux","i3 86-unknown-linux-gnu","i386-unknown-linux","x86_64-unknown-linux- gnu","x86_64-unknown-linux","armv7-unknown-linux-androideabi","aarch64 -unknown-linux-android","arm-unknown-nto-qnx-eabi","i386-apple-darwin ","x86_64-apple-darwin","armv7-apple-ios","aarch64-apple-ios","i386-apple- ios","x86_64-apple-ios"] CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen.hs:96:24 in ghc:LlvmCodeGen 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 Jun 2 19:13:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jun 2018 19:13:06 -0000 Subject: [GHC] #13777: Poor error message around CUSKs In-Reply-To: <047.11d027cf313fa6dbfb640c7b49929a8b@haskell.org> References: <047.11d027cf313fa6dbfb640c7b49929a8b@haskell.org> Message-ID: <062.0f2d8c76dc3b518a9b12dd872cfa16fe@haskell.org> #13777: Poor error message around CUSKs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4771 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4771 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 2 20:13:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jun 2018 20:13:19 -0000 Subject: [GHC] #15103: Speed optimizations for elimCommonBlocks In-Reply-To: <047.9c0ab9c0febb7c3619c049fda5d8f884@haskell.org> References: <047.9c0ab9c0febb7c3619c049fda5d8f884@haskell.org> Message-ID: <062.bfd7135e1ac71ba9b427d4394202f84b@haskell.org> #15103: Speed optimizations for elimCommonBlocks -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4597 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"bd43378dfba1d6c5f19246b972b761640eedb35c/ghc" bd43378d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bd43378dfba1d6c5f19246b972b761640eedb35c" Optimizations for CmmBlockElim. * Use toBlockList instead of revPostorder. Block elimination works on a given Cmm graph by: * Getting a list of blocks. * Looking for duplicates in these blocks. * Removing all but one instance of duplicates. There are two (reasonable) ways to get the list of blocks. * The fast way: `toBlockList` This just flattens the underlying map into a list. * The convenient way: `revPostorder` Start at the entry label, scan for reachable blocks and return only these. This has the advantage of removing all dead code. If there is dead code the later is better. Work done on unreachable blocks is clearly wasted work. However by the point we run the common block elimination pass the input graph already had all dead code removed. This is done during control flow optimization in CmmContFlowOpt which is our first Cmm pass. This means common block elimination is free to use toBlockList because revPostorder would return the same blocks. (Although in a different order). * Change the triemap used for grouping by a label list from `(TM.ListMap UniqDFM)` to `ListMap (GenMap LabelMap)`. * Using GenMap offers leaf compression. Which is a trie optimization described by the Note [Compressed TrieMap] in CoreSyn/TrieMap.hs * Using LabelMap removes the overhead associated with UniqDFM. This is deterministic since if we have the same input keys the same LabelMap will be constructed. Test Plan: ci, profiling output Reviewers: bgamari, simonmar Reviewed By: bgamari Subscribers: dfeuer, thomie, carter GHC Trac Issues: #15103 Differential Revision: https://phabricator.haskell.org/D4597 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 2 20:13:33 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jun 2018 20:13:33 -0000 Subject: [GHC] #15186: ghc 8.4.2 panic in profiling build In-Reply-To: <045.764163a11088d02a8878689da6d8a04b@haskell.org> References: <045.764163a11088d02a8878689da6d8a04b@haskell.org> Message-ID: <060.66b9caf3d1300e6612e7bde89f1f4003@haskell.org> #15186: ghc 8.4.2 panic in profiling build -------------------------------------+------------------------------------- Reporter: kquick | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.4.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: T15186 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4755, Wiki Page: | Phab:D4757 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c983a1dbc01bb6ee68f67af5c7d662bc70845f6f/ghc" c983a1d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c983a1dbc01bb6ee68f67af5c7d662bc70845f6f" testsuite: Add test for #15186 Summary: Currently broken. Test Plan: Validate Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15186 Differential Revision: https://phabricator.haskell.org/D4757 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 2 20:13:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jun 2018 20:13:48 -0000 Subject: [GHC] #15186: ghc 8.4.2 panic in profiling build In-Reply-To: <045.764163a11088d02a8878689da6d8a04b@haskell.org> References: <045.764163a11088d02a8878689da6d8a04b@haskell.org> Message-ID: <060.b6c93fba90317a89f613ace5161e0289@haskell.org> #15186: ghc 8.4.2 panic in profiling build -------------------------------------+------------------------------------- Reporter: kquick | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.4.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: T15186 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4755, Wiki Page: | Phab:D4757 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f0c1eb8b5640b0ec86b9fabb465ea5b841808d56/ghc" f0c1eb8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f0c1eb8b5640b0ec86b9fabb465ea5b841808d56" Conservatively estimate levity in worker/wrapper The worker/wrapper transform needs to determine the levity of the result to determine whether it needs to introduce a lambda to preserve laziness of the result. For this is previously used isUnliftedType. However, this may fail in the presence of levity polymorphism. We now instead use isLiftedType_maybe, assuming that a lambda is needed if the levity of the result cannot be determined. Fixes #15186. Test Plan: make test=T15186 Reviewers: simonpj, goldfire, tdammers Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15186 Differential Revision: https://phabricator.haskell.org/D4755 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 2 20:17:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jun 2018 20:17:43 -0000 Subject: [GHC] #15212: powerpc64le-unknown-linux is missing from llvm-targets In-Reply-To: <045.5d6d39c8631e163a5e27c5b5cbbf3073@haskell.org> References: <045.5d6d39c8631e163a5e27c5b5cbbf3073@haskell.org> Message-ID: <060.9230752a08ab472fe0c632f1d05b6428@haskell.org> #15212: powerpc64le-unknown-linux is missing from llvm-targets ---------------------------------+---------------------------------- Reporter: admock | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4765 Wiki Page: | ---------------------------------+---------------------------------- Comment (by Ben Gamari ): In [changeset:"13a86606e51400bc2a81a0e04cfbb94ada5d2620/ghc" 13a86606/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="13a86606e51400bc2a81a0e04cfbb94ada5d2620" Add llvm-target for powerpc64le-unknown-linux Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15212 Differential Revision: https://phabricator.haskell.org/D4765 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 2 21:42:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jun 2018 21:42:47 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.3d1ff78ef02aacdf02a3682a13544430@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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 sgillespie): What specific message should we show? I was thinking: {{{ Prelude> :m + Control.Monad.Random : error: Could not find module ‘Control.Monad.Random’ It is a member of the package ‘MonadRandom-0.5.1-1421RgpXdhC8e8UI7D3emA’ which is unusable due to missing dependencies: fail-4.9.0.0-BAHmj60kS5K7NVhhKpm9J5 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 2 22:50:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jun 2018 22:50:22 -0000 Subject: [GHC] #15040: DTrace enabled GHC does not work as a bootstrap compiler on FreeBSD In-Reply-To: <046.4248b292a38cdda9701c70fc8d24c20a@haskell.org> References: <046.4248b292a38cdda9701c70fc8d24c20a@haskell.org> Message-ID: <061.c67f9e7891cd8e453620e782f506c817@haskell.org> #15040: DTrace enabled GHC does not work as a bootstrap compiler on FreeBSD -------------------------------------+------------------------------------- Reporter: raichoo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.4.1 Resolution: | Keywords: dtrace 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 raichoo): I have a patch on Phabricator that seems to fix this issue. https://phabricator.haskell.org/D4772 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 2 22:51:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jun 2018 22:51:37 -0000 Subject: [GHC] #15051: -split-objs generates excessively many files on Windows In-Reply-To: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> References: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> Message-ID: <060.da8746f8903eca3aafd6f6068b2376e8@haskell.org> #15051: -split-objs generates excessively many files on Windows ---------------------------------+-------------------------------------- Reporter: kanetw | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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 Phyx-): * priority: normal => highest Comment: Default builds are now broken. it's now generating over 18k worth of split markers, which means Windows builds don't finish in any reasonable amount of time. Does GHC prim really have over 18k worth of symbols now in a single module? Other platforms don't notice this because they use split-sections. Which we can't use on Windows due to a lack of a fast linking process and non-existent x86 implementation. *sigh* perhaps it's time to fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 2 22:53:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jun 2018 22:53:09 -0000 Subject: [GHC] #15051: -split-objs generates excessively many files on Windows In-Reply-To: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> References: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> Message-ID: <060.20805d4d59139a2e7715dc62765dadaa@haskell.org> #15051: -split-objs generates excessively many files on Windows ---------------------------------+-------------------------------------- Reporter: kanetw | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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 Phyx-): @kanetw do you happen to know which hash you noticed this on first? It seems to affect the 8.4.1 release tag already. I guess @bgamari just waited hours and hours for the builds to finish? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 2 22:57:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jun 2018 22:57:17 -0000 Subject: [GHC] #15215: GHC HEAD internal error when FlexibleContexts isn't enabled Message-ID: <050.f3a694ecbd9a7c8505c4c0847398da29@haskell.org> #15215: GHC HEAD internal error when FlexibleContexts isn't enabled -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code produces a GHC internal error on GHC HEAD: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind data A :: Type -> Type where MkA :: Show (Maybe a) => A a data SA :: forall a. A a -> Type where SMkA :: SA MkA }}} {{{ $ ~/Software/ghc5/inplace/bin/ghc-stage2 Bug.hs[1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:3: error: • Non type-variable argument in the constraint: Show (Maybe a) (Use FlexibleContexts to permit this) • In the definition of data constructor ‘MkA’ In the data type declaration for ‘A’ | 9 | MkA :: Show (Maybe a) => A a | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Bug.hs:12:14: error: • GHC internal error: ‘MkA’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [rqU :-> ATcTyCon SA :: forall a. A a -> *, rsV :-> APromotionErr RecDataConPE] • In the first argument of ‘SA’, namely ‘MkA’ In the type ‘SA MkA’ In the definition of data constructor ‘SMkA’ | 12 | SMkA :: SA MkA | ^^^ }}} Enabling `FlexibleContexts` causes the internal error to go away. This is a regression from GHC 8.4, which does not give an internal error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 2 23:03:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jun 2018 23:03:28 -0000 Subject: [GHC] #15186: ghc 8.4.2 panic in profiling build In-Reply-To: <045.764163a11088d02a8878689da6d8a04b@haskell.org> References: <045.764163a11088d02a8878689da6d8a04b@haskell.org> Message-ID: <060.3bf7e0d5a6d8e31a2b8bb76dbf731b73@haskell.org> #15186: ghc 8.4.2 panic in profiling build -------------------------------------+------------------------------------- Reporter: kquick | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.4.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: T15186 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4755, Wiki Page: | Phab:D4757 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 2 23:05:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jun 2018 23:05:10 -0000 Subject: [GHC] #77: Compiling with -O yields broken .hc file In-Reply-To: <045.bc757a6583f48a94446fb97e5a63eab2@haskell.org> References: <045.bc757a6583f48a94446fb97e5a63eab2@haskell.org> Message-ID: <060.0517ba0bfbb72a87bf65e6087ccddf87@haskell.org> #77: Compiling with -O yields broken .hc file --------------------------------+-------------------- Reporter: nobody | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 5.04 Resolution: Fixed | Keywords: Type of failure: None/Unknown | --------------------------------+-------------------- Changes (by Ben Gamari ): * failure: => None/Unknown Comment: In [changeset:"a122d4fdd0a5858e44f9d3be90a258903e0288b2/ghc" a122d4fd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a122d4fdd0a5858e44f9d3be90a258903e0288b2" rts: Rip out support for STM invariants This feature has some very serious correctness issues (#14310), introduces a great deal of complexity, and hasn't seen wide usage. Consequently we are removing it, as proposed in Proposal #77 [1]. This is heavily based on a patch from fryguybob. Updates stm submodule. [1] https://github.com/ghc-proposals/ghc-proposals/pull/77 Test Plan: Validate Reviewers: erikd, simonmar, hvr Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14310 Differential Revision: https://phabricator.haskell.org/D4760 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 2 23:05:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Jun 2018 23:05:10 -0000 Subject: [GHC] #14310: Assertion triggered by STM invariant. In-Reply-To: <042.9c3fac38bbd2247bedc1f2616e6e2820@haskell.org> References: <042.9c3fac38bbd2247bedc1f2616e6e2820@haskell.org> Message-ID: <057.b6d24117aad5a413f0c734111c71eb68@haskell.org> #14310: Assertion triggered by STM invariant. -------------------------------------+------------------------------------- Reporter: mbw | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14324 | Differential Rev(s): Phab:D4065, Wiki Page: | Phab:D4067, Phab:D4073, Phab:D4760 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a122d4fdd0a5858e44f9d3be90a258903e0288b2/ghc" a122d4fd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a122d4fdd0a5858e44f9d3be90a258903e0288b2" rts: Rip out support for STM invariants This feature has some very serious correctness issues (#14310), introduces a great deal of complexity, and hasn't seen wide usage. Consequently we are removing it, as proposed in Proposal #77 [1]. This is heavily based on a patch from fryguybob. Updates stm submodule. [1] https://github.com/ghc-proposals/ghc-proposals/pull/77 Test Plan: Validate Reviewers: erikd, simonmar, hvr Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14310 Differential Revision: https://phabricator.haskell.org/D4760 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 02:30:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 02:30:34 -0000 Subject: [GHC] #14324: Consider deprecating STM invariant mechanism In-Reply-To: <046.7d9457872c0d5f0243f1b38705442b7b@haskell.org> References: <046.7d9457872c0d5f0243f1b38705442b7b@haskell.org> Message-ID: <061.6530dae5da610c014291151778c45277@haskell.org> #14324: Consider deprecating STM invariant mechanism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14310 | Differential Rev(s): Phab:D4372, Wiki Page: | Phab:D4760 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 03:19:33 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 03:19:33 -0000 Subject: [GHC] #15216: plugins10 broken Message-ID: <046.4e5e0be222cd091f3b7f1aa715644fd7@haskell.org> #15216: plugins10 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- `plugins10` from Phab:D4342 is broken, but I am merging regardless and will sort it out later. {{{ =====> plugins10(normal) 7 of 22 [0, 1, 0] cd "./plugins/plugins10.run" && $MAKE -s --no-print-directory -C simple- plugin package.plugins10 TOP=/mnt/work/ghc/ghc/testsuite cd "./plugins/plugins10.run" && $MAKE -s --no-print-directory plugins10 Wrong exit code for plugins10()(expected 0 , actual 2 ) Stdout ( plugins10 ): parsePlugin() interfacePlugin: Prelude interfacePlugin: Language.Haskell.TH interfacePlugin: Language.Haskell.TH.Quote interfacePlugin: GHC.Float interfacePlugin: GHC.Base interfacePlugin: Language.Haskell.TH.Syntax interfacePlugin: GHC.Types typeCheckPlugin (rn) typeCheckPlugin (tc) interfacePlugin: GHC.Integer.Type parsePlugin(a) interfacePlugin: Language.Haskell.TH.Lib.Internal metaPlugin: return [] metaPlugin: quoteExp stringify "x" interfacePlugin: GHC.CString Stderr ( plugins10 ): plugins10.hs:9:5: fatal: cannot find object file for module ‘Simple.SourcePlugin’ while linking an interpreted expression make[2]: *** [Makefile:30: plugins10] Error 1 *** unexpected failure for plugins10(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 03:21:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 03:21:14 -0000 Subject: [GHC] #14709: Extend the plugin mechanism to access program representation In-Reply-To: <044.2e69c960decc5283f7ff746e6b782d96@haskell.org> References: <044.2e69c960decc5283f7ff746e6b782d96@haskell.org> Message-ID: <059.29f444a7b7afdbac3d023d3a60c6e18e@haskell.org> #14709: Extend the plugin mechanism to access program representation -------------------------------------+------------------------------------- Reporter: lazac | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.2.2 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D4342 https://ghc.haskell.org/trac/ghc/wiki/ExtendedPluginsProposal| -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c2783ccf545faabd21a234a4dfc569cd856082b9/ghc" c2783cc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c2783ccf545faabd21a234a4dfc569cd856082b9" Extended the plugin system to run plugins on more representations Extend GHC plugins to access parsed, type checked representation, interfaces that are loaded. And splices that are evaluated. The goal is to enable development tools to access the GHC representation in the pre-existing build environment. See the full proposal here: https://ghc.haskell.org/trac/ghc/wiki/ExtendedPluginsProposal Reviewers: goldfire, bgamari, ezyang, angerman, mpickering Reviewed By: mpickering Subscribers: ezyang, angerman, mpickering, ulysses4ever, rwbarton, thomie, carter GHC Trac Issues: #14709 Differential Revision: https://phabricator.haskell.org/D4342 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 03:21:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 03:21:28 -0000 Subject: [GHC] #13777: Poor error message around CUSKs In-Reply-To: <047.11d027cf313fa6dbfb640c7b49929a8b@haskell.org> References: <047.11d027cf313fa6dbfb640c7b49929a8b@haskell.org> Message-ID: <062.61f8a8bc8d56e81ca25755025c827fa6@haskell.org> #13777: Poor error message around CUSKs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4771 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ac91d07399207f4e22467bea3577cafd27a937d7/ghc" ac91d073/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ac91d07399207f4e22467bea3577cafd27a937d7" Fix #13777 by improving the underdetermined CUSK error message The error message that GHC emits from underdetermined CUSKs is rather poor, since: 1. It may print an empty list of user-written variables if there are none in the declaration. 2. It may not mention any `forall`-bound, underdetermined variables in the result kind. To resolve these issues, this patch: 1. Doesn't bother printing a herald about user-written variables if there are none. 2. Prints the result kind to advertise any underdetermination it may exhibit. Test Plan: make test TEST=T13777 Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: rwbarton, thomie, carter GHC Trac Issues: #13777 Differential Revision: https://phabricator.haskell.org/D4771 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 03:21:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 03:21:58 -0000 Subject: [GHC] #15214: Redefining (~) yields a baffling error message In-Reply-To: <050.3974773989d33b480bdee6d95a089f76@haskell.org> References: <050.3974773989d33b480bdee6d95a089f76@haskell.org> Message-ID: <065.1b83ef2d14626f4c0e9ccc28a3c0796a@haskell.org> #15214: Redefining (~) yields a baffling error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4768 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"21e9d4f5f67dca22fbe3495f637347c5a8f7b52c/ghc" 21e9d4f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="21e9d4f5f67dca22fbe3495f637347c5a8f7b52c" Fix #15214 by listing (~) in isBuiltInOcc_maybe This changes an obscure error (which mistakenly mentions Template Haskell) to one that makes more sense. Test Plan: make test TEST=T15214 Reviewers: bgamari, mpickering Reviewed By: bgamari, mpickering Subscribers: mpickering, rwbarton, thomie, carter GHC Trac Issues: #15214 Differential Revision: https://phabricator.haskell.org/D4768 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 03:22:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 03:22:14 -0000 Subject: [GHC] #14492: Tiered memory allocation restricts available memory In-Reply-To: <044.e21e37476590d999c81ca942af908658@haskell.org> References: <044.e21e37476590d999c81ca942af908658@haskell.org> Message-ID: <059.ec35dea06db465f5a797e2b16bdc3eac@haskell.org> #14492: Tiered memory allocation restricts available memory -------------------------------------+------------------------------------- Reporter: unode | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: memory ulimit Operating System: Linux | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4215 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"26273774661bd0780b1ae8f0755ea135a0ceaf92/ghc" 26273774/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="26273774661bd0780b1ae8f0755ea135a0ceaf92" rts: Query system rlimit for maximum address-space size When we attempt to reserve the heap, we query the system's rlimit to establish the starting point for our search over sizes. Test Plan: Validate Reviewers: erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14492 Differential Revision: https://phabricator.haskell.org/D4754 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 03:22:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 03:22:28 -0000 Subject: [GHC] #14381: Consider making ghc-pkg fill in abi-depends based on depends In-Reply-To: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> References: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> Message-ID: <060.d9db52b7092cecbf128ff7e446a50e94@haskell.org> #14381: Consider making ghc-pkg fill in abi-depends based on depends -------------------------------------+------------------------------------- Reporter: ezyang | Owner: tdammers Type: bug | Status: patch Priority: highest | Milestone: 8.4.3 Component: ghc-pkg | 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:D4159 Wiki Page: | Phab:D4729 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1626fe600672d3dabcf95d11a6c16da5f5ec1068/ghc" 1626fe6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1626fe600672d3dabcf95d11a6c16da5f5ec1068" Handle abi-depends correctly in ghc-pkg When inferring the correct abi-depends, we now look at all the package databases in the stack, up to and including the current one, because these are the ones that the current package can legally depend on. While doing so, we will issue warnings: - In verbose mode, we warn about every package that declares abi-depends:, whether we actually end up overriding them with the inferred ones or not ("possibly broken abi-depends"). - Otherwise, we only warn about packages whose declared abi-depends does not match what we inferred ("definitely broken abi-depends"). Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14381 Differential Revision: https://phabricator.haskell.org/D4729 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 03:22:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 03:22:43 -0000 Subject: [GHC] #15209: ~# is always in scope with TypeOperators In-Reply-To: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> References: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> Message-ID: <060.811117de6bd47f16a643dee53b40a4b8@haskell.org> #15209: ~# is always in scope with TypeOperators -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4763 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5b82ee695e1dbbe355c775e265521c4c3ee8cdbb/ghc" 5b82ee69/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5b82ee695e1dbbe355c775e265521c4c3ee8cdbb" Remove ~# from surface syntax For some reason, it seems that the `ConstraintKinds` commit introduced `~#` into Haskell syntax, in a pretty broken manner. Unless and until we have an actual story for unboxed equality, it doesn't make sense to expose it. Moreover, the way it was donet was wrong enough and small enough that it will probably be easier to start over if we do that. Yank it out. Reviewers: bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, thomie, mpickering, carter GHC Trac Issues: #15209 Differential Revision: https://phabricator.haskell.org/D4763 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 03:26:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 03:26:22 -0000 Subject: [GHC] #14709: Extend the plugin mechanism to access program representation In-Reply-To: <044.2e69c960decc5283f7ff746e6b782d96@haskell.org> References: <044.2e69c960decc5283f7ff746e6b782d96@haskell.org> Message-ID: <059.b33fffd28cf0953da7105b5df64b9332@haskell.org> #14709: Extend the plugin mechanism to access program representation -------------------------------------+------------------------------------- Reporter: lazac | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.2.2 Resolution: fixed | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D4342 https://ghc.haskell.org/trac/ghc/wiki/ExtendedPluginsProposal| -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 03:26:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 03:26:36 -0000 Subject: [GHC] #13777: Poor error message around CUSKs In-Reply-To: <047.11d027cf313fa6dbfb640c7b49929a8b@haskell.org> References: <047.11d027cf313fa6dbfb640c7b49929a8b@haskell.org> Message-ID: <062.a73618f4132947236fbc7ce6da88e24b@haskell.org> #13777: Poor error message around CUSKs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: fixed | Keywords: TypeInType, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4771 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 03:27:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 03:27:03 -0000 Subject: [GHC] #15214: Redefining (~) yields a baffling error message In-Reply-To: <050.3974773989d33b480bdee6d95a089f76@haskell.org> References: <050.3974773989d33b480bdee6d95a089f76@haskell.org> Message-ID: <065.7b437a1141928d82d1241cb8eeadbecd@haskell.org> #15214: Redefining (~) yields a baffling error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4768 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 03:27:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 03:27:57 -0000 Subject: [GHC] #14492: Tiered memory allocation restricts available memory In-Reply-To: <044.e21e37476590d999c81ca942af908658@haskell.org> References: <044.e21e37476590d999c81ca942af908658@haskell.org> Message-ID: <059.f37b839cb52aec3b454d62b851fd94b9@haskell.org> #14492: Tiered memory allocation restricts available memory -------------------------------------+------------------------------------- Reporter: unode | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.0.2 Resolution: fixed | Keywords: memory ulimit Operating System: Linux | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4215 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 03:28:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 03:28:34 -0000 Subject: [GHC] #14381: Consider making ghc-pkg fill in abi-depends based on depends In-Reply-To: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> References: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> Message-ID: <060.2bcde4303ca9ae23134c58f27c65cb7f@haskell.org> #14381: Consider making ghc-pkg fill in abi-depends based on depends -------------------------------------+------------------------------------- Reporter: ezyang | Owner: tdammers Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: ghc-pkg | Version: 8.2.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:D4159 Wiki Page: | Phab:D4729 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: 8.4.3 => 8.6.1 Comment: Fixed correctly in 8.6.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 03:28:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 03:28:57 -0000 Subject: [GHC] #15209: ~# is always in scope with TypeOperators In-Reply-To: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> References: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> Message-ID: <060.a358f877ba2333bd1d650ac3d347c5ec@haskell.org> #15209: ~# is always in scope with TypeOperators -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4763 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 04:30:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 04:30: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.c866325732466325d830a948214d917d@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): Phab:D4752 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4d8004483387c087f5132736863d895ae4869163/ghc" 4d80044/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4d8004483387c087f5132736863d895ae4869163" Fix a bad interaction between GADTs and COMPLETE sets As observed in #14059 (starting at comment 5), the error messages surrounding a program involving GADTs and a `COMPLETE` set became worse between 8.2 and 8.4. The culprit was a new validity check in 8.4 which filters out `COMPLETE` set candidates if a return type of any conlike in the set doesn't match the type of the scrutinee. However, this check was too conservative, since it removed perfectly valid `COMPLETE` sets that contained GADT constructors, which quite often have return types that don't match the type of a scrutinee. To fix this, I adopted the most straightforward possible solution of only performing this validity check on //pattern synonym// constructors, not //data// constructors. Note that this does not fix #14059 entirely, but instead simply fixes a particular buglet that was discovered in that ticket. Test Plan: make test TEST=T14059 Reviewers: bgamari, mpickering Reviewed By: mpickering Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14059 Differential Revision: https://phabricator.haskell.org/D4752 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 04:30:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 04:30:29 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.4db001ebaed303faa1f93b5c409ff334@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454, Wiki Page: | Phab:D4744 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"08073e16cf672d8009309e4e55d4566af1ecaff4/ghc" 08073e16/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="08073e16cf672d8009309e4e55d4566af1ecaff4" Turn "inaccessible code" error into a warning With GADTs, it is possible to write programs such that the type constraints make some code branches inaccessible. Take, for example, the following program :: {-# LANGUAGE GADTs #-} data Foo a where Foo1 :: Foo Char Foo2 :: Foo Int data TyEquality a b where Refl :: TyEquality a a checkTEQ :: Foo t -> Foo u -> Maybe (TyEquality t u) checkTEQ x y = error "unimportant" step2 :: Bool step2 = case checkTEQ Foo1 Foo2 of Just Refl -> True -- Inaccessible code Nothing -> False Clearly, the `Just Refl` case cannot ever be reached, because the `Foo1` and `Foo2` constructors say `t ~ Char` and `u ~ Int`, while the `Refl` constructor essentially mandates `t ~ u`, and thus `Char ~ Int`. Previously, GHC would reject such programs entirely; however, in practice this is too harsh. Accepting such code does little harm, since attempting to use the "impossible" code will still produce errors down the chain, while rejecting it means we cannot legally write or generate such code at all. Hence, we turn the error into a warning, and provide `-Winaccessible-code` to control GHC's behavior upon encountering this situation. Test Plan: ./validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #11066 Differential Revision: https://phabricator.haskell.org/D4744 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 04:30:44 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 04:30:44 -0000 Subject: [GHC] #15017: Come up with a better name for `tcExtendTyVarEnv2` In-Reply-To: <049.2f6cb29d63f77904dc597e5d50b02b5c@haskell.org> References: <049.2f6cb29d63f77904dc597e5d50b02b5c@haskell.org> Message-ID: <064.5d9f334a437fe14f90c5539e33f59d76@haskell.org> #15017: Come up with a better name for `tcExtendTyVarEnv2` -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.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 Ben Gamari ): In [changeset:"9b7eec8614f531e20a34e8dd2f62293ab0fedf8c/ghc" 9b7eec8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9b7eec8614f531e20a34e8dd2f62293ab0fedf8c" tcExtendTyVarEnv2 changed to tcExtendNameTyVarEnv Reviewers: mpickering, goldfire, bgamari Reviewed By: mpickering Subscribers: goldfire, rwbarton, thomie, carter GHC Trac Issues: #15017 Differential Revision: https://phabricator.haskell.org/D4732 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 04:31:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 04:31:00 -0000 Subject: [GHC] #15017: Come up with a better name for `tcExtendTyVarEnv2` In-Reply-To: <049.2f6cb29d63f77904dc597e5d50b02b5c@haskell.org> References: <049.2f6cb29d63f77904dc597e5d50b02b5c@haskell.org> Message-ID: <064.39d7e5d85ce5630f2d511596a08a5fde@haskell.org> #15017: Come up with a better name for `tcExtendTyVarEnv2` -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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.4.3 => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 04:31:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 04:31:04 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.a425adcd661bada2f629a93da54e1065@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 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: #8128, #8740 | Differential Rev(s): Phab:D1454, Wiki Page: | Phab:D4744 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 04:35:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 04:35:01 -0000 Subject: [GHC] #15051: -split-objs generates excessively many files on Windows In-Reply-To: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> References: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> Message-ID: <060.99930087b3c5dce152a2405b87c295d5@haskell.org> #15051: -split-objs generates excessively many files on Windows ---------------------------------+-------------------------------------- Reporter: kanetw | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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 kanetw): Um, whatever built was most recent 7 weeks ago. I can give you the hash once I'm back home, but that won't be for another week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 05:40:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 05:40:24 -0000 Subject: [GHC] #15148: Allow setting of custom alignments In-Reply-To: <047.65d79bc1b0303b6249ecd616495d5687@haskell.org> References: <047.65d79bc1b0303b6249ecd616495d5687@haskell.org> Message-ID: <062.2b01d017bde36c362e041e3b1be26661@haskell.org> #15148: Allow setting of custom alignments -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (NCG) | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15124 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f68c2cb60f881a0a41ae2e8cafc5de193ef9c3fb/ghc" f68c2cb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f68c2cb60f881a0a41ae2e8cafc5de193ef9c3fb" Allow aligning of cmm procs at specific boundry Allows to align CmmProcs at the given boundries. It makes performance usually worse but can be helpful to limit the effect of a unrelated function B becoming faster/slower after changing function A. Test Plan: ci, using it. Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15148 Differential Revision: https://phabricator.haskell.org/D4706 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 05:40:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 05:40:38 -0000 Subject: [GHC] #14546: -Woverlapping-patterns warns on wrong patterns for Int In-Reply-To: <046.65cf2f969bf40f1f8653cdbe0242cf31@haskell.org> References: <046.65cf2f969bf40f1f8653cdbe0242cf31@haskell.org> Message-ID: <061.da04d7a40158f17c3e69fa624325db86@haskell.org> #14546: -Woverlapping-patterns warns on wrong patterns for Int -------------------------------------+------------------------------------- Reporter: Lemming | Owner: sighingnow Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: Resolution: | PatternMatchWarnings 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): Phab:D4571 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1f88f541aad1e36d01f22f9e71dfbc247e6558e2/ghc" 1f88f54/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1f88f541aad1e36d01f22f9e71dfbc247e6558e2" Improve exhaustiveness checking for literal values and patterns, fix #14546 Currently, we parse both the **integral literal** value and the patterns as `OverLit HsIntegral`. For example: ``` case 0::Int of 0 -> putStrLn "A" 1 -> putStrLn "B" _ -> putStrLn "C" ``` When checking the exhaustiveness of pattern matching, we translate the `0` in value position as `PmOLit`, but translate the `0` and `1` in pattern position as `PmSLit`. The inconsistency leads to the failure of `eqPmLit` to detect the equality and report warning of "Pattern match is redundant" on pattern `0`, as reported in #14546. In this patch we remove the specialization of `OverLit` patterns, and keep the overloaded number literal in pattern as it is to maintain the consistency. Now we can capture the exhaustiveness of pattern `0` and the redundancy of pattern `1` and `_`. For **string literals**, we parse the string literals as `HsString`. When `OverloadedStrings` is enabled, it further be turned as `HsOverLit HsIsString`, whether it's type is `String` or not. For example: ``` case "foo" of "foo" -> putStrLn "A" "bar" -> putStrLn "B" "baz" -> putStrLn "C" ``` Previously, the overloaded string values are translated to `PmOLit` and the non-overloaded string values are translated to `PmSLit`. However the string patterns, both overloaded and non-overloaded, are translated to list of characters. The inconsistency leads to wrong warnings about redundant and non-exhaustive pattern matching warnings, as reported in #14546. In order to catch the redundant pattern in following case: ``` case "foo" of ('f':_) -> putStrLn "A" "bar" -> putStrLn "B" ``` In this patch, we translate non-overloaded string literals, both in value position and pattern position, as list of characters. For overloaded string literals, we only translate it to list of characters only when it's type is `stringTy`, since we know nothing about the `toString` methods. But we know that if two overloaded strings are syntax equal, then they are equal. Then if it's type is not `stringTy`, we just translate it to `PmOLit`. We can still capture the exhaustiveness of pattern `"foo"` and the redundancy of pattern `"bar"` and `"baz"` in the following code: ``` {-# LANGUAGE OverloadedStrings #-} main = do case "foo" of "foo" -> putStrLn "A" "bar" -> putStrLn "B" "baz" -> putStrLn "C" ``` Test Plan: make test TEST="T14546" Reviewers: bgamari, simonpj Reviewed By: bgamari, simonpj Subscribers: simonpj, thomie, carter GHC Trac Issues: #14546 Differential Revision: https://phabricator.haskell.org/D4571 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 06:42:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 06:42:35 -0000 Subject: [GHC] #15217: Typo in documentation Message-ID: <046.d49d213112bb0ead0be17ba86fed0b09@haskell.org> #15217: Typo in documentation -------------------------------------+------------------------------------- Reporter: elpinal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In "10.8.5. Overloaded labels" it says "an overloaded label can written with a prefix hash," but I think it should be "an overloaded label can **be** written with a prefix hash." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 08:09:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 08:09:53 -0000 Subject: [GHC] #15217: Typo in documentation In-Reply-To: <046.d49d213112bb0ead0be17ba86fed0b09@haskell.org> References: <046.d49d213112bb0ead0be17ba86fed0b09@haskell.org> Message-ID: <061.bb2ec884a01dfe6160e5fcdbe10709d5@haskell.org> #15217: Typo in documentation -------------------------------------+------------------------------------- Reporter: elpinal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Resolution: | Keywords: 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 Joachim Breitner ): In [changeset:"61280373f4531e87e8429f21cc6f72aa7182d139/ghc" 61280373/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="61280373f4531e87e8429f21cc6f72aa7182d139" Fix typo in OverloadedLabels docs as helpfully reported by elpinal (#15217). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 08:10:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 08:10:10 -0000 Subject: [GHC] #15217: Typo in documentation In-Reply-To: <046.d49d213112bb0ead0be17ba86fed0b09@haskell.org> References: <046.d49d213112bb0ead0be17ba86fed0b09@haskell.org> Message-ID: <061.8ecc0a1417c1743fc28df333dbb7755e@haskell.org> #15217: Typo in documentation -------------------------------------+------------------------------------- Reporter: elpinal | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: Thanks, fixed! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 11:24:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 11:24:14 -0000 Subject: [GHC] #15209: ~# is always in scope with TypeOperators In-Reply-To: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> References: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> Message-ID: <060.954020ea1f0063d7f7e8af303cfe6422@haskell.org> #15209: ~# is always in scope with TypeOperators -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4763 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: closed => new * resolution: fixed => Comment: Unfortunately, it turns out that removing the `'(' '~#' ')'` production from the parser is //not// enough, as the original program in this ticket can still be written even after this most recent patch. In order to truly cut off access to `(~#)` from users, we need to find some way to avoid exporting `(~#)` from `GHC.Prim`. We should probably also do the same for `(~R#)` and `(~P#)`, because while you can't actually use those in the source syntax, you //can// view them with `:browse` (as discovered in #12023). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 11:26:33 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 11:26:33 -0000 Subject: [GHC] #14546: -Woverlapping-patterns warns on wrong patterns for Int In-Reply-To: <046.65cf2f969bf40f1f8653cdbe0242cf31@haskell.org> References: <046.65cf2f969bf40f1f8653cdbe0242cf31@haskell.org> Message-ID: <061.14d2eb69e6188640a6c5d8e16ee1656f@haskell.org> #14546: -Woverlapping-patterns warns on wrong patterns for Int -------------------------------------+------------------------------------- Reporter: Lemming | Owner: sighingnow Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: Resolution: fixed | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: error/warning at compile-time | deSugar/should_compile/T14546a, | deSugar/should_compile/T14546b, | deSugar/should_compile/T14546c Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4571 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => deSugar/should_compile/T14546a, deSugar/should_compile/T14546b, deSugar/should_compile/T14546c * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 11:27:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 11:27:21 -0000 Subject: [GHC] #10869: Option to dump preprocessed source In-Reply-To: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> References: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> Message-ID: <061.0f3a03c31b9f513e828b8faf66779c6f@haskell.org> #10869: Option to dump preprocessed source -------------------------------------+------------------------------------- Reporter: phischu | Owner: RolandSenn Type: feature request | Status: new Priority: low | Milestone: Component: Driver | Version: 7.10.2 Resolution: | Keywords: easy 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 RolandSenn): After looking into the code, I decided the following: The requested functionality is not a ''dump'' operation. In a dump operation we have information in memory and write (dump) it out to sysout, syserror or to a file. Here, however, we have the information already in a file and we want to keep the file after GHC processing ends. Hence, this is a ''keep'' operation, and the flag will be called '''keep-hspp-file'''. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 11:34:59 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 11:34:59 -0000 Subject: [GHC] #8740: Deriving instance conditionally compiles In-Reply-To: <050.1c0f14a319b334387d7bd66c85f19a98@haskell.org> References: <050.1c0f14a319b334387d7bd66c85f19a98@haskell.org> Message-ID: <065.0a81593ad777840dcd2c4c5e2b433f5a@haskell.org> #8740: Deriving instance conditionally compiles -------------------------------------+------------------------------------- Reporter: thomaseding | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: GADTs, Resolution: | deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #11066 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #8128 => #8128, #11066 Comment: Now that inaccessible code is a warning instead of an error (see #11066), the original program now typechecks. I'll whip up a test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 11:36:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 11:36:09 -0000 Subject: [GHC] #8128: Standalone deriving fails for GADTs due to inaccessible code In-Reply-To: <049.b5f919d61189346fb956f5afd152d2c9@haskell.org> References: <049.b5f919d61189346fb956f5afd152d2c9@haskell.org> Message-ID: <064.35bab79f42eff1cbbfca38e0d63f7100@haskell.org> #8128: Standalone deriving fails for GADTs due to inaccessible code -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Keywords: GADTs, Resolution: | deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8740, #11066 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Now that inaccessible code is a warning instead of an error (see #11066), the original program now typechecks. I'll whip up a test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 11:49:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 11:49:23 -0000 Subject: [GHC] #8128: Standalone deriving fails for GADTs due to inaccessible code In-Reply-To: <049.b5f919d61189346fb956f5afd152d2c9@haskell.org> References: <049.b5f919d61189346fb956f5afd152d2c9@haskell.org> Message-ID: <064.a5e3eec0614616ad984d76f477f331b3@haskell.org> #8128: Standalone deriving fails for GADTs due to inaccessible code -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Keywords: GADTs, Resolution: | deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8740, #11066 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"90e99c4cfd601601e56fc6041186ca3e070408d9/ghc" 90e99c4c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="90e99c4cfd601601e56fc6041186ca3e070408d9" Add tests for #8128 and #8740 Commit 08073e16cf672d8009309e4e55d4566af1ecaff4 (#11066) ended up fixing these, fortunately enough. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 11:49:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 11:49:23 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.23245fdc97fd5012433925fc030db70d@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 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: #8128, #8740 | Differential Rev(s): Phab:D1454, Wiki Page: | Phab:D4744 -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"90e99c4cfd601601e56fc6041186ca3e070408d9/ghc" 90e99c4c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="90e99c4cfd601601e56fc6041186ca3e070408d9" Add tests for #8128 and #8740 Commit 08073e16cf672d8009309e4e55d4566af1ecaff4 (#11066) ended up fixing these, fortunately enough. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 11:49:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 11:49:23 -0000 Subject: [GHC] #8740: Deriving instance conditionally compiles In-Reply-To: <050.1c0f14a319b334387d7bd66c85f19a98@haskell.org> References: <050.1c0f14a319b334387d7bd66c85f19a98@haskell.org> Message-ID: <065.6f3a384ee3a6264523b2b50f2d74929f@haskell.org> #8740: Deriving instance conditionally compiles -------------------------------------+------------------------------------- Reporter: thomaseding | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: GADTs, Resolution: | deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #11066 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"90e99c4cfd601601e56fc6041186ca3e070408d9/ghc" 90e99c4c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="90e99c4cfd601601e56fc6041186ca3e070408d9" Add tests for #8128 and #8740 Commit 08073e16cf672d8009309e4e55d4566af1ecaff4 (#11066) ended up fixing these, fortunately enough. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 11:50:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 11:50:45 -0000 Subject: [GHC] #8128: Standalone deriving fails for GADTs due to inaccessible code In-Reply-To: <049.b5f919d61189346fb956f5afd152d2c9@haskell.org> References: <049.b5f919d61189346fb956f5afd152d2c9@haskell.org> Message-ID: <064.7af59e9fa1f61591d5248fb57ac13114@haskell.org> #8128: Standalone deriving fails for GADTs due to inaccessible code -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 7.7 checker) | Keywords: GADTs, Resolution: fixed | deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T8128 Blocked By: | Blocking: Related Tickets: #8740, #11066 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => deriving/should_compile/T8128 * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 11:51:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 11:51:22 -0000 Subject: [GHC] #8740: Deriving instance conditionally compiles In-Reply-To: <050.1c0f14a319b334387d7bd66c85f19a98@haskell.org> References: <050.1c0f14a319b334387d7bd66c85f19a98@haskell.org> Message-ID: <065.5c4f5dbc975a85909c52d65bf508dada@haskell.org> #8740: Deriving instance conditionally compiles -------------------------------------+------------------------------------- Reporter: thomaseding | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: GADTs, Resolution: fixed | deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T8740 Blocked By: | Blocking: Related Tickets: #8128, #11066 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => deriving/should_compile/T8740 * status: new => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 12:10:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 12:10:28 -0000 Subject: [GHC] #15218: HEAD doesn't build without sphinx-build Message-ID: <042.48e52db875cf86898104c8cf24945fa7@haskell.org> #15218: HEAD doesn't build without sphinx-build -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: Build System | Version: 8.4.3 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: -------------------------------------+------------------------------------- If you git clone HEAD and run ./validate the system should build without further ado. It doesn't. The make all fails, complaining about an absence of sphinx-build. Using the mk .sample files doesn't help. Installing sphinx-bulid resolves the issue. So the documentation here and/or the default build are out of sync with each other. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 12:12:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 12:12:20 -0000 Subject: [GHC] #11477: Remove -Wamp In-Reply-To: <046.3dbac51dca4bf042073a762ce7d4fafd@haskell.org> References: <046.3dbac51dca4bf042073a762ce7d4fafd@haskell.org> Message-ID: <061.db2791be89b04a30f5ab6f08184c0c86@haskell.org> #11477: Remove -Wamp -------------------------------------+------------------------------------- Reporter: bgamari | Owner: RolandSenn Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 RolandSenn): * owner: (none) => RolandSenn Comment: I'll work on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 12:15:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 12:15:04 -0000 Subject: [GHC] #9247: Document -XDatatypeContexts in flag reference In-Reply-To: <047.5847e6375288b1fe9155bf048d9f1ac4@haskell.org> References: <047.5847e6375288b1fe9155bf048d9f1ac4@haskell.org> Message-ID: <062.65a45afb106a4240ee03789eae941ed6@haskell.org> #9247: Document -XDatatypeContexts in flag reference -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: low | Milestone: Component: Documentation | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #1880 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: This was done in commit a6c3289d0aa0c520656e918dfc9f152548d940a4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 12:18:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 12:18:54 -0000 Subject: [GHC] #14546: -Woverlapping-patterns warns on wrong patterns for Int In-Reply-To: <046.65cf2f969bf40f1f8653cdbe0242cf31@haskell.org> References: <046.65cf2f969bf40f1f8653cdbe0242cf31@haskell.org> Message-ID: <061.736243e786aa1e3ab1667288ef9612db@haskell.org> #14546: -Woverlapping-patterns warns on wrong patterns for Int -------------------------------------+------------------------------------- Reporter: Lemming | Owner: sighingnow Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: Resolution: fixed | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: error/warning at compile-time | deSugar/should_compile/T14546a, | deSugar/should_compile/T14546b, | deSugar/should_compile/T14546c Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4571 Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): It is probably this patch that breaks test T14547 {{{ cd "./T14547.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc- stage2" -c T14547.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 -Wincomplete- patterns Actual stderr output differs from expected: diff -uw "/dev/null" "./T14547.run/T14547.comp.stderr.normalised" --- /dev/null 2018-06-02 19:10:04.172693400 +0100 +++ ./T14547.run/T14547.comp.stderr.normalised 2018-06-03 13:14:15.645102495 +0100 @@ -0,0 +1,4 @@ + +T14547.hs:14:9: warning: [-Wincomplete-patterns (in -Wextra)] + Pattern match(es) are non-exhaustive + In an equation for ‘foo’: Patterns not matched: [] *** unexpected failure for T14547(normal) Unexpected results from: TEST="T14547" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 12:45:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 12:45:25 -0000 Subject: [GHC] #14546: -Woverlapping-patterns warns on wrong patterns for Int In-Reply-To: <046.65cf2f969bf40f1f8653cdbe0242cf31@haskell.org> References: <046.65cf2f969bf40f1f8653cdbe0242cf31@haskell.org> Message-ID: <061.490c585b429d3a8d9514109b668c7000@haskell.org> #14546: -Woverlapping-patterns warns on wrong patterns for Int -------------------------------------+------------------------------------- Reporter: Lemming | Owner: sighingnow Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: Resolution: fixed | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: error/warning at compile-time | deSugar/should_compile/T14546a, | deSugar/should_compile/T14546b, | deSugar/should_compile/T14546c Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4571 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): I'm building ghc-head now. I will look at this problem. Sorry for the break. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 12:52:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 12:52:18 -0000 Subject: [GHC] #15219: Implement UnliftedNewtypes proposal Message-ID: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> #15219: Implement UnliftedNewtypes proposal -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple UnliftedNewtypes | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The unlifted newtypes proposal is described here: https://github.com/ghc- proposals/ghc-proposals/blob/master/proposals/0013-unlifted-newtypes.rst I am going to be working on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 13:04:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 13:04:37 -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.269c7f2b0a5c691345a9e9f058dc5fb1@haskell.org> #8949: switch -msse2 to be on by default --------------------------------------------+------------------------------ Reporter: errge | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.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: 13624 | Blocking: Related Tickets: #13540, #13624 | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 13:09:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 13:09:13 -0000 Subject: [GHC] #15219: Implement UnliftedNewtypes proposal In-Reply-To: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> References: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> Message-ID: <064.738129584f345aefa115dfcc68133407@haskell.org> #15219: Implement UnliftedNewtypes proposal -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | UnliftedNewtypes, GhcProposal 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): * keywords: UnliftedNewtypes => UnliftedNewtypes, GhcProposal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 13:42:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 13:42:30 -0000 Subject: [GHC] #15219: Implement UnliftedNewtypes proposal In-Reply-To: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> References: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> Message-ID: <064.de2567fed521ca712c524e441f0cec74@haskell.org> #15219: Implement UnliftedNewtypes proposal -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | UnliftedNewtypes, GHCProposal 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: UnliftedNewtypes, GhcProposal => UnliftedNewtypes, GHCProposal Comment: (Does case of keywords even matter?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 13:47:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 13:47:21 -0000 Subject: [GHC] #15220: ScopedTypeVariables binds a non-existent variable Message-ID: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> #15220: ScopedTypeVariables binds a non-existent variable -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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 accepts this definition: {{{#!hs f :: (forall a. a -> a) -> () f (x :: b -> b) = x (undefined :: b) `seq` () }}} If a scoped type variable is bound always to a variable, then what variable is `b` bound to? In the desugared Core, it looks like `b` is bound to `Any`. Note that I couldn't find any valid argument for `x` here other than `undefined`. I think this definition should be rejected. In terms of implementation, the `zonkTcTypeToType` function should never encounter a unfilled-in `SigTv`. If it does, error. I don't like putting the error there, but I'm not sure I know another place to do it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 14:05:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 14:05:07 -0000 Subject: [GHC] #12152: panic: Loading temp shared object failed In-Reply-To: <047.fffa3b3df32ae27b408efe8d3e6f6a61@haskell.org> References: <047.fffa3b3df32ae27b408efe8d3e6f6a61@haskell.org> Message-ID: <062.2ad9b656e116cac339cc430d6a37b570@haskell.org> #12152: panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 7.8.1 (Linking) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by toonn): I think I ran into this with 8.2.2: {{{ Loading cabal new-repl --ghc-options=-fobject-code test-suite:mpw ... Build profile: -w ghc-8.2.2 -O1 In order, the following will be built (use -v for more details): - skeletonkey-0.0.0.0 (test:mpw) (file tests/Main.hs changed) Preprocessing test suite 'mpw' for skeletonkey-0.0.0.0.. GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help : warning: [-Wmissing-home-modules] These modules are needed for compilation but not listed in your .cabal file's other-modules: KDF MAC MPAlgorithm MPW.Path MPW.Test MPWTemplates Types Ok, 8 modules loaded. All good (8 modules, at 13:42:23) Running test... ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc24637_0/libghc_3.so: undefined symbol: MPWziPath_mpwTestsXml_closure Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ...done }}} I created `MPW.Path` so I could avoid having `{-# LANGUAGE CPP #-}` in `MPW.Tests` because that doesn't agree with string gaps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 14:07:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 14:07:15 -0000 Subject: [GHC] #15221: failure to build pandoc on Debian armhf Message-ID: <044.c95e2449a6d05724dcf3491a30d3f9d3@haskell.org> #15221: failure to build pandoc on Debian armhf --------------------------------+--------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------- {{{ [112 of 131] Compiling Text.Pandoc.Readers.HTML ( src/Text/Pandoc/Readers/HTML.hs, dist- ghc/build/Text/Pandoc/Readers/HTML.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for arm-unknown-linux): piResultTy Addr# String 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:949:35 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug /usr/share/cdbs/1/class/hlibrary.mk:147: recipe for target 'build-ghc- stamp' failed }}} https://buildd.debian.org/status/fetch.php?pkg=pandoc&arch=armhf&ver=2.2.1-1&stamp=1527886652&raw=0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 14:10:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 14:10:18 -0000 Subject: [GHC] #15199: Build fails on Debian armhf (armv7l-unknown-linux-gnueabihf) In-Reply-To: <044.81af1940b7343631708d21b21be1c899@haskell.org> References: <044.81af1940b7343631708d21b21be1c899@haskell.org> Message-ID: <059.e7c1b2babeb6aeeba46da005d2a74489@haskell.org> #15199: Build fails on Debian armhf (armv7l-unknown-linux-gnueabihf) -------------------------------------+------------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.4.4 Component: Compiler | Version: 8.4.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 clint): * version: 8.4.2 => 8.4.3 Comment: master not yet tested, but backporting e4003b6dc6a84d870116de9f47057c15b1576f36 to 8.4.3 results in {{{ utils/haddock/ghc.mk:20: recipe for target 'utils/haddock/dist/build/Haddock/GhcUtils.dyn_o' failed make[3]: *** [utils/haddock/dist/build/Haddock/GhcUtils.dyn_o] Illegal instruction make[3]: *** Waiting for unfinished jobs.... utils/haddock/ghc.mk:20: recipe for target 'utils/haddock/dist/build/ResponseFile.dyn_o' failed make[3]: *** [utils/haddock/dist/build/ResponseFile.dyn_o] Illegal instruction utils/haddock/ghc.mk:20: recipe for target 'utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o' failed make[3]: *** [utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o] Illegal instruction utils/haddock/ghc.mk:20: recipe for target 'utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o' failed make[3]: *** [utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o] Illegal instruction Makefile:122: recipe for target 'all' failed }}} https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armhf&ver=8.4.3-1&stamp=1528031879&raw=0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 14:24:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 14:24:40 -0000 Subject: [GHC] #15222: T14547 is broken Message-ID: <046.bdf448125865882daa53a202abd38798@haskell.org> #15222: T14547 is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- It fails with: {{{ 10 + 11 +T14547.hs:14:9: warning: [-Wincomplete-patterns (in -Wextra)] 12 + Pattern match(es) are non-exhaustive 13 + In an equation for ‘foo’: Patterns not matched: [] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 14:26:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 14:26:09 -0000 Subject: [GHC] #12152: panic: Loading temp shared object failed In-Reply-To: <047.fffa3b3df32ae27b408efe8d3e6f6a61@haskell.org> References: <047.fffa3b3df32ae27b408efe8d3e6f6a61@haskell.org> Message-ID: <062.521707a4f3b578002655b5af47f91c8f@haskell.org> #12152: panic: Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 7.8.1 (Linking) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by toonn): Seems I was too quick. Rerunning the ghcid command gave the same error message but running it after a run of `cabal new-test` has fixed the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 16:02:44 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 16:02:44 -0000 Subject: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened In-Reply-To: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> References: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> Message-ID: <061.7684179e2345d19eabe8851efb7874e5@haskell.org> #15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | TypeCheckerPlugins 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 nfrisby): My plugin is responsible for reducing some type families. Receiving flattened Wanteds appeals to me because all of the tyfam applications (except those under forall? hmmm) would be FunEq constraints, so I wouldn't have to seek them out in the types. So perhaps if there were a separate mechanism for the plugin to declare a custom "reducer" for a type family, that might eliminate my interest in flattened Wanteds. Another related quality of life improvement would be easier access to the unflattening substitution, e.g. without having to manually assemble the FunEq constraints. I'm not sure yet, but I think I'll eventually want to only unflatten certain "relevant" type families (and maybe other applications containing applications of those type families). (This is for givens too, not just Wanteds.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 16:18:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 16:18:45 -0000 Subject: [GHC] #15222: T14547 is broken In-Reply-To: <046.bdf448125865882daa53a202abd38798@haskell.org> References: <046.bdf448125865882daa53a202abd38798@haskell.org> Message-ID: <061.f9e591a15817070901692308245088aa@haskell.org> #15222: T14547 is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4778 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * status: new => patch * differential: => Phab:D4778 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 17:34:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 17:34:53 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.8b0e7b86c19df118aa8516df8b68c5ac@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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 Phyx-): I would change the first part to be more precise `Could not find module ‘Control.Monad.Random’` into something like `Could not load module ‘Control.Monad.Random’` since the message is a bit contradictory saying it couldn't find it yet it's part of a package it knows about. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 19:46:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 19:46:34 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.3daa93d9febe09b8e7eee8c622f05dfd@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): I have a patch that seems to fix it: -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 20:12:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 20:12:52 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.b88bed40f35102e4a404d328b63e4193@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4780 Wiki Page: | -------------------------------------+------------------------------------- Changes (by carter): * differential: => D4780 Comment: https://phabricator.haskell.org/D4780 for a candidate patch. Not perfect, and may have other issues, but fixes the mac build without impacting other platforms. I'm not 100% sure i'm fixing it perfectly, but it definitly has zero impact on non-darwin platforms, and my understanding is this particular dwarf data only works in the presence of the RTS support for stack walking which is exclusive to ELF platforms? Or is there a fundamental error in this fix? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 21:16:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 21:16:46 -0000 Subject: [GHC] #15222: T14547 is broken In-Reply-To: <046.bdf448125865882daa53a202abd38798@haskell.org> References: <046.bdf448125865882daa53a202abd38798@haskell.org> Message-ID: <061.1e365c51620504f41a1b39d33eb6c868@haskell.org> #15222: T14547 is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4778 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 22:29:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 22:29:46 -0000 Subject: [GHC] #15223: Serialising Names using the GHC API is not possible Message-ID: <049.45bf630c1830f60a7ff77c85b6f51c3f@haskell.org> #15223: Serialising Names using the GHC API is not possible -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4782 | Wiki Page: -------------------------------------+------------------------------------- In order to serialise a `Name` using `Binary` you have to initialise `UserData`. This isn't possible because the constructors necessary to write the symbol table and dictionary are not exported. However, it turns out to be easy to extract the necessary logic and provide two nice wrapper functions to provide this functionality. This makes it possible to serialise Names when writing source plugins for instance. https://phabricator.haskell.org/D4782 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 3 22:59:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Jun 2018 22:59:43 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.ae40632a2793c0353fb7f8186db9ec14@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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 sgillespie): Agreed; however, GHC does display the same contradictory message with hidden packages: {{{ Prelude> :m + Data.Map : error: Could not find module ‘Data.Map’ It is a member of the hidden package ‘containers-0.5.11.0’. You can run ‘:set -package containers’ to expose it. (Note: this unloads all the modules in the current scope.) }}} I think it would make sense to use the same language for both scenarios. I can either update both, or leave them both the same. What do you think? In the meantime, I'm going to go ahead and submit a review so someone can start reviewing it -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 02:06:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 02:06:18 -0000 Subject: [GHC] #15223: Serialising Names using the GHC API is not possible In-Reply-To: <049.45bf630c1830f60a7ff77c85b6f51c3f@haskell.org> References: <049.45bf630c1830f60a7ff77c85b6f51c3f@haskell.org> Message-ID: <064.3bf70dfc3c6c6229088c841e7e4a7fa5@haskell.org> #15223: Serialising Names using the GHC API is not possible -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4782 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"554bc7fcca30b1b6ffb6a2daca684ea74eb83ad8/ghc" 554bc7fc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="554bc7fcca30b1b6ffb6a2daca684ea74eb83ad8" Provide `getWithUserData` and `putWithUserData` Summary: This makes it possible to serialise Names and FastStrings in user programs, for example, when writing a source plugin. When writing my first source plugin, I wanted to serialise names but it wasn't possible easily without exporting additional constructors. This interface is sufficient and abstracts nicely over the symbol table and dictionary. Reviewers: alpmestan, bgamari Reviewed By: alpmestan Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15223 Differential Revision: https://phabricator.haskell.org/D4782 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 02:11:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 02:11:34 -0000 Subject: [GHC] #15223: Serialising Names using the GHC API is not possible In-Reply-To: <049.45bf630c1830f60a7ff77c85b6f51c3f@haskell.org> References: <049.45bf630c1830f60a7ff77c85b6f51c3f@haskell.org> Message-ID: <064.ebb874ccbb9c46fdbf3e76814fa8c3fa@haskell.org> #15223: Serialising Names using the GHC API is not possible -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4782 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 03:08:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 03:08:50 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.ebe8c64216cf34ff0c403c11282f99e3@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4780 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): i tested ben's alternative fix, D4781, and it seems to work (and be more useful as it doesn't remove the dwarf data, it just makes it more precise) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 07:04:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 07:04:32 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.0713049b5d675e248487c7c1d913f040@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.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 tdammers): Replying to [comment:20 elaforge]: > Surely those people's workflows are already broken by the fact that you can't evaluate much of anything without causing a panic. > > If they are just loading the modules to check types and not actually running them, then they don't need `-fdefer-type-errors` in the first place. So if someone's tool is thrown by an extra warning msg, they can probably just remove the flag. I also think it's reasonable to expect tools to be robust against unexpected messages at startup before the prompt comes. The use case for `-fdefer-type-errors` is so that you can run (and test) your module even when parts of it don't typecheck yet. E.g. suppose you write this: {{{#!hs module Pluralize where suffix :: Int -> String suffix 1 = "" suffix _ = "s" pluralize :: Int -> String -> String pluralize i s = s ++ i -- TODO }}} ...then you might want to load it into GHCi to play with the `suffix` function, or you may want to run unit tests on it, even though `pluralize` doesn't work yet (and doesn't typecheck). Deferring type errors is *especially* (some would argue *only*) useful in an interactive REPL: there isn't really a sharp workflow distinction between "compile time" and "runtime", so it is less important to produce type errors at compile time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 07:12:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 07:12:27 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.962391f473db742f25006ab95ae3e2ff@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Ran a few test, and I'm getting perplexing results. First of all, a full GHC build from scratch, with `-fno-state-hack` everywhere, gives mixed results: Regular profiling build: {{{ real 66m1.181s user 118m55.812s sys 6m9.724s }}} Profiling build with `-fno-state-hack` enabled: {{{ real 66m25.030s user 119m48.580s sys 6m7.568s }}} So the difference is small, `real` and `sys` (which, I believe, is what counts) slightly in favor of removing the state hack, `user` in favor of keeping it. I've also done `nofib` runs with both compilers, also enabling / disabling the state hack accordingly; however it turns out that disabling the state hack causes `nofib` to fail: {{{ ------------------------------------------------------------------------ == make all --no-print-directory; in /home/tobias/well-typed/devel/ghc/HEAD/nofib/shootout/fasta ------------------------------------------------------------------------ HC = /home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2 HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fno-state-hack -O2 -rtsopts -O2 -XBangPatterns -XOverloadedStrings -package bytestring RUNTEST_OPTS = -ghc-timing ==nofib== fasta: time to compile Main follows... /home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2 -O2 -Rghc- timing -H32m -hisuf hi -fno-state-hack -O2 -rtsopts -O2 -XBangPatterns -XOverloadedStrings -package bytestring -c Main.hs -o Main.o Main.hs:30:1: warning: [-Wtabs] Tab character found here, and in 13 further locations. Please use spaces instead. | 30 | let !k = min modulus (floor (fromIntegral modulus * (p::Float) + 1)) | ^^^^^^^^ <> ==nofib== fasta: size of Main.o follows... text data bss dec hex filename 7245 2624 0 9869 268d Main.o ==nofib== fasta: time to link fasta follows... <> ==nofib== fasta: size of fasta follows... text data bss dec hex filename 708996 127712 16232 852940 d03cc fasta ==nofib== fasta: time to run fasta follows... ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; 0.43user 0.02system 0:00.45elapsed 99%CPU (0avgtext+0avgdata 4824maxresident)k 0inputs+49656outputs (0major+608minor)pagefaults 0swaps ././fasta 2500000 < /dev/null expected stdout not matched by reality --- fasta.stdout 2018-06-02 03:00:43.887025433 +0200 +++ /tmp/runtest4673.1 2018-06-02 03:09:19.651755697 +0200 @@ -83337,333335 +83337,333335 @@ cttBtatcatatgctaKggNcataaaSatgtaaaDcDRtBggDtctttataattcBgtcg -tactDtDagcctatttSVHtHttKtgtHMaSattgWaHKHttttagacatWatgtRgaaa -NtactMcSMtYtcMgRtacttctWBacgaaatatagScDtttgaagacacatagtVgYgt -cattHWtMMWcStgttaggKtSgaYaaccWStcgBttgcgaMttBYatcWtgacaYcaga -gtaBDtRacttttcWatMttDBcatWtatcttactaBgaYtcttgttttttttYaaScYa -HgtgttNtSatcMtcVaaaStccRcctDaataataStcYtRDSaMtDttgttSagtRRca #### ~3.1 million similar lines follow #### -taatataagctgcgccaggggatttttccagatcatctggcctgtgtatatgttcaaatc +gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt +gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt +gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt #### ~208k identical lines follow +gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt taatagccgagagaaattac ../../mk/target.mk:101: recipe for target 'runtests' failed make[2]: *** [runtests] Error 1 Failed making all in fasta: 1 ../mk/ghc-recurse.mk:65: recipe for target 'all' failed make[1]: *** [all] Error 1 Failed making all in shootout: 1 mk/ghc-recurse.mk:65: recipe for target 'all' failed make: *** [all] Error 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 07:21:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 07:21:48 -0000 Subject: [GHC] #15224: Add -fwan-sum-type-partial-field-accessor Message-ID: <044.1bcebddcf798745fecc0745f7add512f@haskell.org> #15224: Add -fwan-sum-type-partial-field-accessor -------------------------------------+------------------------------------- Reporter: erikd | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- This a a new warning flag that would be off by default and warns when a sum type is defined with field accessors that are partial. For an example of something that would trigger the warning: {{{#!hs data Option a = Some { getSome :: a } | None }}} In production quality Haskell code it usually desirable to outright ban partial functions like `head`, `fromJust` etc by use of a custom prelude. Unfortunately partial functions can still sneak into a code base via field accessors in sum types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 07:22:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 07:22:24 -0000 Subject: [GHC] #15224: Add -fwan-sum-type-partial-field-accessor In-Reply-To: <044.1bcebddcf798745fecc0745f7add512f@haskell.org> References: <044.1bcebddcf798745fecc0745f7add512f@haskell.org> Message-ID: <059.e2b6f5dfdf9ca2563b9aa0b9be8270ee@haskell.org> #15224: Add -fwan-sum-type-partial-field-accessor -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 erikd): * owner: (none) => erikd -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 07:35:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 07:35:32 -0000 Subject: [GHC] #15224: Add -fwan-sum-type-partial-field-accessor In-Reply-To: <044.1bcebddcf798745fecc0745f7add512f@haskell.org> References: <044.1bcebddcf798745fecc0745f7add512f@haskell.org> Message-ID: <059.24f2ef2645af196d6fdaed6767637f2e@haskell.org> #15224: Add -fwan-sum-type-partial-field-accessor -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 erikd): * status: new => closed * resolution: => invalid Comment: Never mind. This seems to be `-fwarn-partial-fields`. Closing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 08:05:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 08:05:54 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails In-Reply-To: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> References: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> Message-ID: <065.6065cf48e1c654a6464a34377791a696@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, CUSKs 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): > For non-CUSKs, we can safely simply make T :: kappa, without looking at the declaration at all! Actually this is not true, as things stand. This accepted: {{{ data T k (a::k) = MkT (Proxy (T * Int)) (Proxy (T (*->*) Maybe)) }}} But `T` does not have a CUSK, and if we assigned it the mono-kind `kappa`, the recursive definition would be rejected. So currently we are cleverly (and somewhat accidentally) accepting a recursive definition with a partial kind signature. I think we should just reject this definition unless you write a CUSK. Specifying exactly what is and what is not accepted would be ... difficult. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 08:36:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 08:36:25 -0000 Subject: [GHC] #15103: Speed optimizations for elimCommonBlocks In-Reply-To: <047.9c0ab9c0febb7c3619c049fda5d8f884@haskell.org> References: <047.9c0ab9c0febb7c3619c049fda5d8f884@haskell.org> Message-ID: <062.9de9a466c8d55fdda5247e0c299e84ed@haskell.org> #15103: Speed optimizations for elimCommonBlocks -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4597 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What is the perf impact of this optimisation, if any? (I think the goal is to improve compile times, right? Not run-time.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 08:55:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 08:55:22 -0000 Subject: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened In-Reply-To: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> References: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> Message-ID: <061.ea7244ef8c6c151d9a5ee1eb34040d99@haskell.org> #15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | TypeCheckerPlugins 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 issue here is that the wanteds are now sometimes not fully unflattened, isn't it? No, the reported issue (in the Description) is that a Given `CFunEqCan` remains. I believe that all Wanted `CFunEqCans` are removed. It's inconsistent, I know, but hard to fix -- except by leaving the Wanted `CFunEqCans` too. Which might be useful for some... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 09:14:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 09:14:17 -0000 Subject: [GHC] #15211: exprFreeVars does not include type variables In-Reply-To: <047.2d30bc163a3c3f3a1e1fc1344efb9efd@haskell.org> References: <047.2d30bc163a3c3f3a1e1fc1344efb9efd@haskell.org> Message-ID: <062.3a542544254734432f9a8652601b04bc@haskell.org> #15211: exprFreeVars does not include type variables -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 simonpj): > However, this function doesn't include the type variables free in the free term variables That would indeed seem wrong. I think you are suggesting that a `closeOverKinds`-style thing is needed? If so, then in `CoreFVs.expr_fvs` {{{ expr_fvs (Type ty) fv_cand in_scope acc = tyCoFVsOfType ty fv_cand in_scope acc }}} we would ''not'' want to use a version of `tyCoFVsOfType` that closed over the kinds. (We'll do that at the end; and it's wrong to do so at the occurrences. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 09:50:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 09:50:55 -0000 Subject: [GHC] #15103: Speed optimizations for elimCommonBlocks In-Reply-To: <047.9c0ab9c0febb7c3619c049fda5d8f884@haskell.org> References: <047.9c0ab9c0febb7c3619c049fda5d8f884@haskell.org> Message-ID: <062.188db58254a9f010cd4f3d4ab70edb9b@haskell.org> #15103: Speed optimizations for elimCommonBlocks -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4597 Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): Replying to [comment:7 simonpj]: > What is the perf impact of this optimisation, if any? Generated code is the same. Compiler performance changes for the better. I think the file I looked at was nofib/spectral/simple `ghc-stage2 -fforce-recomp -c -O1 Main.hs +RTS -s -RTS` || build || Allocated (Byte) || measured time || || master || 4,475,812,248 || 3.220 s (3.204 s .. 3.251 s) || || toBlockList || 4,474,452,216 || 3.196 s (3.192 s .. 3.204 s) || || IntMap + blockList || 4,461,727,496 || 3.189 s (3.174 s .. 3.203 s) || > I think the goal is to improve compile times, right? Not run-time. Yes it's purely an "make GHC faster" patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 09:57:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 09:57:09 -0000 Subject: [GHC] #15103: Speed optimizations for elimCommonBlocks In-Reply-To: <047.9c0ab9c0febb7c3619c049fda5d8f884@haskell.org> References: <047.9c0ab9c0febb7c3619c049fda5d8f884@haskell.org> Message-ID: <062.20eff78bf3fe686638e74574f0bce0f9@haskell.org> #15103: Speed optimizations for elimCommonBlocks -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4597 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Terrific. Would you like to do a nofib run before-and-after, and dump the `nofib-analyse` summary in here? It's very helpful just to record the benefits of particular changes, for posterity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 14:05:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 14:05:59 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.9f763c34d9f2f5372bd26a92fabb6973@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The correctness issue is very concerning (especially given that this is a rather vanilla program). I would say that this deserves its own ticket. Let's focus on that before turning our attention to the performance issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 14:49:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 14:49:22 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.7f5346e776957112cf0ba8f5cfda068a@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.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 tdammers): As discussed in Hangouts, the problem is even more specific: it only appears for expressions entered at the GHCi prompt while defer-type-errors is active. Loading modules with defer-type-errors on, then turning it off and *then* evaluating expressions at the prompt works just fine. Hence, the quick fix for 8.6 will be to selectively disable deferred type checking for expressions entered interactively. This way, we will not disrupt any workflows (the error would have appeared right there and then one way or another), while still avoiding the crash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 14:59:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 14:59:58 -0000 Subject: [GHC] #15225: `-fno-state-hack` produces incorrect results in nofib Message-ID: <047.20e2da7aa2a2e4221951af3d8807d250@haskell.org> #15225: `-fno-state-hack` produces incorrect results in nofib -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: #7411 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While investigating #7411, I found that nofib fails with incorrect output from the `fasta` test. A vanilla `prof` build behaves normally; however, with the following modifications, `nofib` fails: - Compile GHC from scratch with: {{{ GhcStage2HcOpts = -O -fno-state-hack GhcLibHcOpts = -O -fno-state-hack }}} - Run nofib with `EXTRA_HC_OPTS=-fno-state-hack` Doing this, the nofib test output is: {{{ ------------------------------------------------------------------------ == make all --no-print-directory; in /home/tobias/well-typed/devel/ghc/HEAD/nofib/shootout/fasta ------------------------------------------------------------------------ HC = /home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2 HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fno-state-hack -O2 -rtsopts -O2 -XBangPatterns -XOverloadedStrings -package bytestring RUNTEST_OPTS = -ghc-timing ==nofib== fasta: time to compile Main follows... /home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2 -O2 -Rghc- timing -H32m -hisuf hi -fno-state-hack -O2 -rtsopts -O2 -XBangPatterns -XOverloadedStrings -package bytestring -c Main.hs -o Main.o Main.hs:30:1: warning: [-Wtabs] Tab character found here, and in 13 further locations. Please use spaces instead. | 30 | let !k = min modulus (floor (fromIntegral modulus * (p::Float) + 1)) | ^^^^^^^^ <> ==nofib== fasta: size of Main.o follows... text data bss dec hex filename 7245 2624 0 9869 268d Main.o ==nofib== fasta: time to link fasta follows... <> ==nofib== fasta: size of fasta follows... text data bss dec hex filename 708996 127712 16232 852940 d03cc fasta ==nofib== fasta: time to run fasta follows... ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; 0.43user 0.02system 0:00.45elapsed 99%CPU (0avgtext+0avgdata 4824maxresident)k 0inputs+49656outputs (0major+608minor)pagefaults 0swaps ././fasta 2500000 < /dev/null expected stdout not matched by reality --- fasta.stdout 2018-06-02 03:00:43.887025433 +0200 +++ /tmp/runtest4673.1 2018-06-02 03:09:19.651755697 +0200 @@ -83337,333335 +83337,333335 @@ cttBtatcatatgctaKggNcataaaSatgtaaaDcDRtBggDtctttataattcBgtcg -tactDtDagcctatttSVHtHttKtgtHMaSattgWaHKHttttagacatWatgtRgaaa -NtactMcSMtYtcMgRtacttctWBacgaaatatagScDtttgaagacacatagtVgYgt -cattHWtMMWcStgttaggKtSgaYaaccWStcgBttgcgaMttBYatcWtgacaYcaga -gtaBDtRacttttcWatMttDBcatWtatcttactaBgaYtcttgttttttttYaaScYa -HgtgttNtSatcMtcVaaaStccRcctDaataataStcYtRDSaMtDttgttSagtRRca #### ~3.1 million similar lines follow #### -taatataagctgcgccaggggatttttccagatcatctggcctgtgtatatgttcaaatc +gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt +gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt +gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt #### ~208k identical lines follow +gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt taatagccgagagaaattac ../../mk/target.mk:101: recipe for target 'runtests' failed make[2]: *** [runtests] Error 1 Failed making all in fasta: 1 ../mk/ghc-recurse.mk:65: recipe for target 'all' failed make[1]: *** [all] Error 1 Failed making all in shootout: 1 mk/ghc-recurse.mk:65: recipe for target 'all' failed make: *** [all] Error 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 15:12:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 15:12:26 -0000 Subject: [GHC] #15225: `-fno-state-hack` produces incorrect results in nofib In-Reply-To: <047.20e2da7aa2a2e4221951af3d8807d250@haskell.org> References: <047.20e2da7aa2a2e4221951af3d8807d250@haskell.org> Message-ID: <062.62d1f6363fc59ce6e0d6e2a709bbe988@haskell.org> #15225: `-fno-state-hack` produces incorrect results in nofib -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7411 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 15:18:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 15:18:55 -0000 Subject: [GHC] #15225: `-fno-state-hack` produces incorrect results in nofib In-Reply-To: <047.20e2da7aa2a2e4221951af3d8807d250@haskell.org> References: <047.20e2da7aa2a2e4221951af3d8807d250@haskell.org> Message-ID: <062.14476f8ef98b7af017325e438a63b4ec@haskell.org> #15225: `-fno-state-hack` produces incorrect results in nofib -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7411 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * owner: (none) => tdammers -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 15:21:40 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 15:21:40 -0000 Subject: [GHC] #11126: Entered absent arg in a Repa program In-Reply-To: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> References: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> Message-ID: <064.257191274900127940b62583b9f25b2f@haskell.org> #11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 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:D3221 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 15:43:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 15:43:00 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.cc41ff93da9cce70f8518b858618de26@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): A program that might run slower without the state hack is {{{ f :: Char -> IO () f 'x' = return () f c = putChar c }}} Now call that `f` many times. Without the state hack I think it'll have arity 1, returning a lambda that does the I/O. We must find out what happens with fasta, yes, but what are the perf results from nofib? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 15:54:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 15:54:15 -0000 Subject: [GHC] #14939: Lint error in forall type In-Reply-To: <051.8bc9e96ca4b89b1613c7c0914d47c2a8@haskell.org> References: <051.8bc9e96ca4b89b1613c7c0914d47c2a8@haskell.org> Message-ID: <066.15d326183fbeb3656d49888a8fc7a7b0@haskell.org> #14939: Lint error in forall type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | StaticPointers 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:"9d600ea68c283b0d38ac663c3cc48baba6b94f57/ghc" 9d600ea6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9d600ea68c283b0d38ac663c3cc48baba6b94f57" Expand type synonyms when Linting a forall Trac #14939 showed a type like type Alg cls ob = ob f :: forall (cls :: * -> Constraint) (b :: Alg cls *). b where the kind of the forall looks like (Alg cls *), with a free cls. This tripped up Core Lint. I fixed this by making Core Lint a bit more forgiving, expanding type synonyms if necessary. I'm worried that this might not be the whole story; notably typeKind looks suspect. But it certainly fixes this problem. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 15:55:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 15:55:32 -0000 Subject: [GHC] #14939: Lint error in forall type In-Reply-To: <051.8bc9e96ca4b89b1613c7c0914d47c2a8@haskell.org> References: <051.8bc9e96ca4b89b1613c7c0914d47c2a8@haskell.org> Message-ID: <066.1ed8cf70d5d89df86ef682a963a3cfd7@haskell.org> #14939: Lint error in forall type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | StaticPointers 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): Richard, I'd be interested in what you think here, esp re `typeKind`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 16:04:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 16:04:12 -0000 Subject: [GHC] #11477: Remove -Wamp In-Reply-To: <046.3dbac51dca4bf042073a762ce7d4fafd@haskell.org> References: <046.3dbac51dca4bf042073a762ce7d4fafd@haskell.org> Message-ID: <061.145d3f04156200deddde6c893572fe58@haskell.org> #11477: Remove -Wamp -------------------------------------+------------------------------------- Reporter: bgamari | Owner: RolandSenn Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D4785 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * status: new => patch * differential: => Phab: D4785 Comment: This is my first patch by Phabricator. I'm not sure, whether I really submitted this patch correctly. [https://phabricator.haskell.org/D4785 https://phabricator.haskell.org/D4785] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 16:25:16 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 16:25:16 -0000 Subject: [GHC] #15103: Speed optimizations for elimCommonBlocks In-Reply-To: <047.9c0ab9c0febb7c3619c049fda5d8f884@haskell.org> References: <047.9c0ab9c0febb7c3619c049fda5d8f884@haskell.org> Message-ID: <062.30c9aa52c64a6667c6922f6636f6df40@haskell.org> #15103: Speed optimizations for elimCommonBlocks -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4597 Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): Replying to [comment:9 simonpj]: > Terrific. Would you like to do a nofib run before-and-after, and dump the `nofib-analyse` summary in here? It's very helpful just to record the benefits of particular changes, for posterity. {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- maillist 0.0% 0.0% 0.024 0.025 +6.5% mate -0.0% 0.0% +4.6% +4.6% 0.0% cryptarithm1 0.0% 0.0% -1.7% -1.8% 0.0% -------------------------------------------------------------------------------- Min -0.0% -0.0% -1.7% -1.8% 0.0% Max +0.0% +0.1% +4.6% +4.6% +6.5% Geometric Mean -0.0% +0.0% +0.3% +0.3% +0.1% Compile Times ------------------------------------------------------------------------------- Program logNoOpt logWithOpt ------------------------------------------------------------------------------- -1 s.d. ----- -1.9% +1 s.d. ----- +1.5% Average ----- -0.2% Compile Allocations ------------------------------------------------------------------------------- Program logNoOpt logWithOpt ------------------------------------------------------------------------------- -1 s.d. ----- -0.3% +1 s.d. ----- -0.1% Average ----- -0.2% }}} These runtime results took me by surprise! It turns out code layout depends on uniques. And the final uniques change with this patch. So we get slightly different codelayout. I verified that the code for mate is otherwise the same. Using different starting or increment values for uniques also lead to different results with up to the same performance spread. So I don't think the runtime change is representative. Compiler performance impact is as expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 17:21:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 17:21:34 -0000 Subject: [GHC] #11477: Remove -Wamp In-Reply-To: <046.3dbac51dca4bf042073a762ce7d4fafd@haskell.org> References: <046.3dbac51dca4bf042073a762ce7d4fafd@haskell.org> Message-ID: <061.dc9566de89ef4c1e4bcee7d6cec93e43@haskell.org> #11477: Remove -Wamp -------------------------------------+------------------------------------- Reporter: bgamari | Owner: RolandSenn Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D4785 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.8.1 Comment: Thanks Roland! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 18:03:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 18:03:15 -0000 Subject: [GHC] #15225: `-fno-state-hack` produces incorrect results in nofib In-Reply-To: <047.20e2da7aa2a2e4221951af3d8807d250@haskell.org> References: <047.20e2da7aa2a2e4221951af3d8807d250@haskell.org> Message-ID: <062.6ce107e5e4bf0cac0c20e1a23a3bac83@haskell.org> #15225: `-fno-state-hack` produces incorrect results in nofib -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7411 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Running only nofib with `-fno-state-hack`, but with GHC and libraries compiled normally, the problem does not appear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 18:21:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 18:21:49 -0000 Subject: [GHC] #15222: T14547 is broken In-Reply-To: <046.bdf448125865882daa53a202abd38798@haskell.org> References: <046.bdf448125865882daa53a202abd38798@haskell.org> Message-ID: <061.83222dd5812f03b47f2875d0480c3966@haskell.org> #15222: T14547 is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4778 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d8efb0983cf90aa4224cb62ce8d7fb37e7e6dffb/ghc" d8efb098/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d8efb0983cf90aa4224cb62ce8d7fb37e7e6dffb" Fix broken test T14547. Phab:D4571 lags behind HEAD for too many commits. The commit of Phab:4571 1f88f541aad1e36d01f22f9e71dfbc247e6558e2 brought some unintentional changes (not belong to [Phab:4571's Diff 16314](https://phabricator.haskell.org/differential/diff/16314/)) into ghc-head, breaking T14557. Let's fix that. Test Plan: make test TEST="T14547" Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15222 Differential Revision: https://phabricator.haskell.org/D4778 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 18:24:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 18:24:21 -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.d0fe0c4b23124839b2f421c3a77514f5@haskell.org> #5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Keywords: Resolution: duplicate | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2893 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7df589608abb178efd6499ee705ba4eebd0cf0d1/ghc" 7df5896/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7df589608abb178efd6499ee705ba4eebd0cf0d1" Implement QuantifiedConstraints We have wanted quantified constraints for ages and, as I hoped, they proved remarkably simple to implement. All the machinery was already in place. The main ticket is Trac #2893, but also relevant are #5927 #8516 #9123 (especially! higher kinded roles) #14070 #14317 The wiki page is https://ghc.haskell.org/trac/ghc/wiki/QuantifiedConstraints which in turn contains a link to the GHC Proposal where the change is specified. Here is the relevant Note: Note [Quantified constraints] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The -XQuantifiedConstraints extension allows type-class contexts like this: data Rose f x = Rose x (f (Rose f x)) instance (Eq a, forall b. Eq b => Eq (f b)) => Eq (Rose f a) where (Rose x1 rs1) == (Rose x2 rs2) = x1==x2 && rs1 >= rs2 Note the (forall b. Eq b => Eq (f b)) in the instance contexts. This quantified constraint is needed to solve the [W] (Eq (f (Rose f x))) constraint which arises form the (==) definition. Here are the moving parts * Language extension {-# LANGUAGE QuantifiedConstraints #-} and add it to ghc-boot-th:GHC.LanguageExtensions.Type.Extension * A new form of evidence, EvDFun, that is used to discharge such wanted constraints * checkValidType gets some changes to accept forall-constraints only in the right places. * Type.PredTree gets a new constructor ForAllPred, and and classifyPredType analyses a PredType to decompose the new forall-constraints * Define a type TcRnTypes.QCInst, which holds a given quantified constraint in the inert set * TcSMonad.InertCans gets an extra field, inert_insts :: [QCInst], which holds all the Given forall-constraints. In effect, such Given constraints are like local instance decls. * When trying to solve a class constraint, via TcInteract.matchInstEnv, use the InstEnv from inert_insts so that we include the local Given forall-constraints in the lookup. (See TcSMonad.getInstEnvs.) * topReactionsStage calls doTopReactOther for CIrredCan and CTyEqCan, so they can try to react with any given quantified constraints (TcInteract.matchLocalInst) * TcCanonical.canForAll deals with solving a forall-constraint. See Note [Solving a Wanted forall-constraint] Note [Solving a Wanted forall-constraint] * We augment the kick-out code to kick out an inert forall constraint if it can be rewritten by a new type equality; see TcSMonad.kick_out_rewritable Some other related refactoring ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Move SCC on evidence bindings to post-desugaring, which fixed #14735, and is generally nicer anyway because we can use existing CoreSyn free-var functions. (Quantified constraints made the free-vars of an ev-term a bit more complicated.) * In LookupInstResult, replace GenInst with OneInst and NotSure, using the latter for multiple matches and/or one or more unifiers }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 18:24:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 18:24:20 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.ec7cf903ad244c8948f3aee3decc7f46@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Roles, Resolution: | QuantifiedConstraints 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:"7df589608abb178efd6499ee705ba4eebd0cf0d1/ghc" 7df5896/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7df589608abb178efd6499ee705ba4eebd0cf0d1" Implement QuantifiedConstraints We have wanted quantified constraints for ages and, as I hoped, they proved remarkably simple to implement. All the machinery was already in place. The main ticket is Trac #2893, but also relevant are #5927 #8516 #9123 (especially! higher kinded roles) #14070 #14317 The wiki page is https://ghc.haskell.org/trac/ghc/wiki/QuantifiedConstraints which in turn contains a link to the GHC Proposal where the change is specified. Here is the relevant Note: Note [Quantified constraints] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The -XQuantifiedConstraints extension allows type-class contexts like this: data Rose f x = Rose x (f (Rose f x)) instance (Eq a, forall b. Eq b => Eq (f b)) => Eq (Rose f a) where (Rose x1 rs1) == (Rose x2 rs2) = x1==x2 && rs1 >= rs2 Note the (forall b. Eq b => Eq (f b)) in the instance contexts. This quantified constraint is needed to solve the [W] (Eq (f (Rose f x))) constraint which arises form the (==) definition. Here are the moving parts * Language extension {-# LANGUAGE QuantifiedConstraints #-} and add it to ghc-boot-th:GHC.LanguageExtensions.Type.Extension * A new form of evidence, EvDFun, that is used to discharge such wanted constraints * checkValidType gets some changes to accept forall-constraints only in the right places. * Type.PredTree gets a new constructor ForAllPred, and and classifyPredType analyses a PredType to decompose the new forall-constraints * Define a type TcRnTypes.QCInst, which holds a given quantified constraint in the inert set * TcSMonad.InertCans gets an extra field, inert_insts :: [QCInst], which holds all the Given forall-constraints. In effect, such Given constraints are like local instance decls. * When trying to solve a class constraint, via TcInteract.matchInstEnv, use the InstEnv from inert_insts so that we include the local Given forall-constraints in the lookup. (See TcSMonad.getInstEnvs.) * topReactionsStage calls doTopReactOther for CIrredCan and CTyEqCan, so they can try to react with any given quantified constraints (TcInteract.matchLocalInst) * TcCanonical.canForAll deals with solving a forall-constraint. See Note [Solving a Wanted forall-constraint] Note [Solving a Wanted forall-constraint] * We augment the kick-out code to kick out an inert forall constraint if it can be rewritten by a new type equality; see TcSMonad.kick_out_rewritable Some other related refactoring ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Move SCC on evidence bindings to post-desugaring, which fixed #14735, and is generally nicer anyway because we can use existing CoreSyn free-var functions. (Quantified constraints made the free-vars of an ev-term a bit more complicated.) * In LookupInstResult, replace GenInst with OneInst and NotSure, using the latter for multiple matches and/or one or more unifiers }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 18:24:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 18:24:20 -0000 Subject: [GHC] #8516: Add (->) representation and the Invariant class to GHC.Generics In-Reply-To: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> References: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> Message-ID: <061.aca6b00a905b76fb7dd6a9445b5ccf5b@haskell.org> #8516: Add (->) representation and the Invariant class to GHC.Generics -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Keywords: Generics, Resolution: | QuantifiedConstraints 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:"7df589608abb178efd6499ee705ba4eebd0cf0d1/ghc" 7df5896/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7df589608abb178efd6499ee705ba4eebd0cf0d1" Implement QuantifiedConstraints We have wanted quantified constraints for ages and, as I hoped, they proved remarkably simple to implement. All the machinery was already in place. The main ticket is Trac #2893, but also relevant are #5927 #8516 #9123 (especially! higher kinded roles) #14070 #14317 The wiki page is https://ghc.haskell.org/trac/ghc/wiki/QuantifiedConstraints which in turn contains a link to the GHC Proposal where the change is specified. Here is the relevant Note: Note [Quantified constraints] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The -XQuantifiedConstraints extension allows type-class contexts like this: data Rose f x = Rose x (f (Rose f x)) instance (Eq a, forall b. Eq b => Eq (f b)) => Eq (Rose f a) where (Rose x1 rs1) == (Rose x2 rs2) = x1==x2 && rs1 >= rs2 Note the (forall b. Eq b => Eq (f b)) in the instance contexts. This quantified constraint is needed to solve the [W] (Eq (f (Rose f x))) constraint which arises form the (==) definition. Here are the moving parts * Language extension {-# LANGUAGE QuantifiedConstraints #-} and add it to ghc-boot-th:GHC.LanguageExtensions.Type.Extension * A new form of evidence, EvDFun, that is used to discharge such wanted constraints * checkValidType gets some changes to accept forall-constraints only in the right places. * Type.PredTree gets a new constructor ForAllPred, and and classifyPredType analyses a PredType to decompose the new forall-constraints * Define a type TcRnTypes.QCInst, which holds a given quantified constraint in the inert set * TcSMonad.InertCans gets an extra field, inert_insts :: [QCInst], which holds all the Given forall-constraints. In effect, such Given constraints are like local instance decls. * When trying to solve a class constraint, via TcInteract.matchInstEnv, use the InstEnv from inert_insts so that we include the local Given forall-constraints in the lookup. (See TcSMonad.getInstEnvs.) * topReactionsStage calls doTopReactOther for CIrredCan and CTyEqCan, so they can try to react with any given quantified constraints (TcInteract.matchLocalInst) * TcCanonical.canForAll deals with solving a forall-constraint. See Note [Solving a Wanted forall-constraint] Note [Solving a Wanted forall-constraint] * We augment the kick-out code to kick out an inert forall constraint if it can be rewritten by a new type equality; see TcSMonad.kick_out_rewritable Some other related refactoring ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Move SCC on evidence bindings to post-desugaring, which fixed #14735, and is generally nicer anyway because we can use existing CoreSyn free-var functions. (Quantified constraints made the free-vars of an ev-term a bit more complicated.) * In LookupInstResult, replace GenInst with OneInst and NotSure, using the latter for multiple matches and/or one or more unifiers }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 18:24:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 18:24:21 -0000 Subject: [GHC] #14317: Solve Coercible constraints over type constructors In-Reply-To: <051.6e7c0afa9b7a89daa70b165c438f90b5@haskell.org> References: <051.6e7c0afa9b7a89daa70b165c438f90b5@haskell.org> Message-ID: <066.ac920ff580a0582625e47a1270a054da@haskell.org> #14317: Solve Coercible constraints over type constructors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Roles, | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14386 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7df589608abb178efd6499ee705ba4eebd0cf0d1/ghc" 7df5896/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7df589608abb178efd6499ee705ba4eebd0cf0d1" Implement QuantifiedConstraints We have wanted quantified constraints for ages and, as I hoped, they proved remarkably simple to implement. All the machinery was already in place. The main ticket is Trac #2893, but also relevant are #5927 #8516 #9123 (especially! higher kinded roles) #14070 #14317 The wiki page is https://ghc.haskell.org/trac/ghc/wiki/QuantifiedConstraints which in turn contains a link to the GHC Proposal where the change is specified. Here is the relevant Note: Note [Quantified constraints] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The -XQuantifiedConstraints extension allows type-class contexts like this: data Rose f x = Rose x (f (Rose f x)) instance (Eq a, forall b. Eq b => Eq (f b)) => Eq (Rose f a) where (Rose x1 rs1) == (Rose x2 rs2) = x1==x2 && rs1 >= rs2 Note the (forall b. Eq b => Eq (f b)) in the instance contexts. This quantified constraint is needed to solve the [W] (Eq (f (Rose f x))) constraint which arises form the (==) definition. Here are the moving parts * Language extension {-# LANGUAGE QuantifiedConstraints #-} and add it to ghc-boot-th:GHC.LanguageExtensions.Type.Extension * A new form of evidence, EvDFun, that is used to discharge such wanted constraints * checkValidType gets some changes to accept forall-constraints only in the right places. * Type.PredTree gets a new constructor ForAllPred, and and classifyPredType analyses a PredType to decompose the new forall-constraints * Define a type TcRnTypes.QCInst, which holds a given quantified constraint in the inert set * TcSMonad.InertCans gets an extra field, inert_insts :: [QCInst], which holds all the Given forall-constraints. In effect, such Given constraints are like local instance decls. * When trying to solve a class constraint, via TcInteract.matchInstEnv, use the InstEnv from inert_insts so that we include the local Given forall-constraints in the lookup. (See TcSMonad.getInstEnvs.) * topReactionsStage calls doTopReactOther for CIrredCan and CTyEqCan, so they can try to react with any given quantified constraints (TcInteract.matchLocalInst) * TcCanonical.canForAll deals with solving a forall-constraint. See Note [Solving a Wanted forall-constraint] Note [Solving a Wanted forall-constraint] * We augment the kick-out code to kick out an inert forall constraint if it can be rewritten by a new type equality; see TcSMonad.kick_out_rewritable Some other related refactoring ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Move SCC on evidence bindings to post-desugaring, which fixed #14735, and is generally nicer anyway because we can use existing CoreSyn free-var functions. (Quantified constraints made the free-vars of an ev-term a bit more complicated.) * In LookupInstResult, replace GenInst with OneInst and NotSure, using the latter for multiple matches and/or one or more unifiers }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 18:24:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 18:24:21 -0000 Subject: [GHC] #2893: Implement "Quantified constraints" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@haskell.org> References: <045.2638646abdcf216191d07c9810407703@haskell.org> Message-ID: <060.81bde1147ec43444aa153b1fab2e2392@haskell.org> #2893: Implement "Quantified constraints" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5927 | Differential Rev(s): Phab:D4724 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7df589608abb178efd6499ee705ba4eebd0cf0d1/ghc" 7df5896/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7df589608abb178efd6499ee705ba4eebd0cf0d1" Implement QuantifiedConstraints We have wanted quantified constraints for ages and, as I hoped, they proved remarkably simple to implement. All the machinery was already in place. The main ticket is Trac #2893, but also relevant are #5927 #8516 #9123 (especially! higher kinded roles) #14070 #14317 The wiki page is https://ghc.haskell.org/trac/ghc/wiki/QuantifiedConstraints which in turn contains a link to the GHC Proposal where the change is specified. Here is the relevant Note: Note [Quantified constraints] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The -XQuantifiedConstraints extension allows type-class contexts like this: data Rose f x = Rose x (f (Rose f x)) instance (Eq a, forall b. Eq b => Eq (f b)) => Eq (Rose f a) where (Rose x1 rs1) == (Rose x2 rs2) = x1==x2 && rs1 >= rs2 Note the (forall b. Eq b => Eq (f b)) in the instance contexts. This quantified constraint is needed to solve the [W] (Eq (f (Rose f x))) constraint which arises form the (==) definition. Here are the moving parts * Language extension {-# LANGUAGE QuantifiedConstraints #-} and add it to ghc-boot-th:GHC.LanguageExtensions.Type.Extension * A new form of evidence, EvDFun, that is used to discharge such wanted constraints * checkValidType gets some changes to accept forall-constraints only in the right places. * Type.PredTree gets a new constructor ForAllPred, and and classifyPredType analyses a PredType to decompose the new forall-constraints * Define a type TcRnTypes.QCInst, which holds a given quantified constraint in the inert set * TcSMonad.InertCans gets an extra field, inert_insts :: [QCInst], which holds all the Given forall-constraints. In effect, such Given constraints are like local instance decls. * When trying to solve a class constraint, via TcInteract.matchInstEnv, use the InstEnv from inert_insts so that we include the local Given forall-constraints in the lookup. (See TcSMonad.getInstEnvs.) * topReactionsStage calls doTopReactOther for CIrredCan and CTyEqCan, so they can try to react with any given quantified constraints (TcInteract.matchLocalInst) * TcCanonical.canForAll deals with solving a forall-constraint. See Note [Solving a Wanted forall-constraint] Note [Solving a Wanted forall-constraint] * We augment the kick-out code to kick out an inert forall constraint if it can be rewritten by a new type equality; see TcSMonad.kick_out_rewritable Some other related refactoring ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Move SCC on evidence bindings to post-desugaring, which fixed #14735, and is generally nicer anyway because we can use existing CoreSyn free-var functions. (Quantified constraints made the free-vars of an ev-term a bit more complicated.) * In LookupInstResult, replace GenInst with OneInst and NotSure, using the latter for multiple matches and/or one or more unifiers }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 18:24:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 18:24:21 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.6fe6ce7f9643f9824836669e530a38db@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: | QuantifiedConstraints, deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2893 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7df589608abb178efd6499ee705ba4eebd0cf0d1/ghc" 7df5896/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7df589608abb178efd6499ee705ba4eebd0cf0d1" Implement QuantifiedConstraints We have wanted quantified constraints for ages and, as I hoped, they proved remarkably simple to implement. All the machinery was already in place. The main ticket is Trac #2893, but also relevant are #5927 #8516 #9123 (especially! higher kinded roles) #14070 #14317 The wiki page is https://ghc.haskell.org/trac/ghc/wiki/QuantifiedConstraints which in turn contains a link to the GHC Proposal where the change is specified. Here is the relevant Note: Note [Quantified constraints] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The -XQuantifiedConstraints extension allows type-class contexts like this: data Rose f x = Rose x (f (Rose f x)) instance (Eq a, forall b. Eq b => Eq (f b)) => Eq (Rose f a) where (Rose x1 rs1) == (Rose x2 rs2) = x1==x2 && rs1 >= rs2 Note the (forall b. Eq b => Eq (f b)) in the instance contexts. This quantified constraint is needed to solve the [W] (Eq (f (Rose f x))) constraint which arises form the (==) definition. Here are the moving parts * Language extension {-# LANGUAGE QuantifiedConstraints #-} and add it to ghc-boot-th:GHC.LanguageExtensions.Type.Extension * A new form of evidence, EvDFun, that is used to discharge such wanted constraints * checkValidType gets some changes to accept forall-constraints only in the right places. * Type.PredTree gets a new constructor ForAllPred, and and classifyPredType analyses a PredType to decompose the new forall-constraints * Define a type TcRnTypes.QCInst, which holds a given quantified constraint in the inert set * TcSMonad.InertCans gets an extra field, inert_insts :: [QCInst], which holds all the Given forall-constraints. In effect, such Given constraints are like local instance decls. * When trying to solve a class constraint, via TcInteract.matchInstEnv, use the InstEnv from inert_insts so that we include the local Given forall-constraints in the lookup. (See TcSMonad.getInstEnvs.) * topReactionsStage calls doTopReactOther for CIrredCan and CTyEqCan, so they can try to react with any given quantified constraints (TcInteract.matchLocalInst) * TcCanonical.canForAll deals with solving a forall-constraint. See Note [Solving a Wanted forall-constraint] Note [Solving a Wanted forall-constraint] * We augment the kick-out code to kick out an inert forall constraint if it can be rewritten by a new type equality; see TcSMonad.kick_out_rewritable Some other related refactoring ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Move SCC on evidence bindings to post-desugaring, which fixed #14735, and is generally nicer anyway because we can use existing CoreSyn free-var functions. (Quantified constraints made the free-vars of an ev-term a bit more complicated.) * In LookupInstResult, replace GenInst with OneInst and NotSure, using the latter for multiple matches and/or one or more unifiers }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 18:24:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 18:24:21 -0000 Subject: [GHC] #14735: GHC Panic with QuantifiedConstraints In-Reply-To: <051.3a02470ddbd28d332b6dd2bb0406c5fc@haskell.org> References: <051.3a02470ddbd28d332b6dd2bb0406c5fc@haskell.org> Message-ID: <066.b747cca7c993c16555fef52586e4a580@haskell.org> #14735: GHC Panic with QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: wipT2893, | QuantifiedConstraints 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:"7df589608abb178efd6499ee705ba4eebd0cf0d1/ghc" 7df5896/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7df589608abb178efd6499ee705ba4eebd0cf0d1" Implement QuantifiedConstraints We have wanted quantified constraints for ages and, as I hoped, they proved remarkably simple to implement. All the machinery was already in place. The main ticket is Trac #2893, but also relevant are #5927 #8516 #9123 (especially! higher kinded roles) #14070 #14317 The wiki page is https://ghc.haskell.org/trac/ghc/wiki/QuantifiedConstraints which in turn contains a link to the GHC Proposal where the change is specified. Here is the relevant Note: Note [Quantified constraints] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The -XQuantifiedConstraints extension allows type-class contexts like this: data Rose f x = Rose x (f (Rose f x)) instance (Eq a, forall b. Eq b => Eq (f b)) => Eq (Rose f a) where (Rose x1 rs1) == (Rose x2 rs2) = x1==x2 && rs1 >= rs2 Note the (forall b. Eq b => Eq (f b)) in the instance contexts. This quantified constraint is needed to solve the [W] (Eq (f (Rose f x))) constraint which arises form the (==) definition. Here are the moving parts * Language extension {-# LANGUAGE QuantifiedConstraints #-} and add it to ghc-boot-th:GHC.LanguageExtensions.Type.Extension * A new form of evidence, EvDFun, that is used to discharge such wanted constraints * checkValidType gets some changes to accept forall-constraints only in the right places. * Type.PredTree gets a new constructor ForAllPred, and and classifyPredType analyses a PredType to decompose the new forall-constraints * Define a type TcRnTypes.QCInst, which holds a given quantified constraint in the inert set * TcSMonad.InertCans gets an extra field, inert_insts :: [QCInst], which holds all the Given forall-constraints. In effect, such Given constraints are like local instance decls. * When trying to solve a class constraint, via TcInteract.matchInstEnv, use the InstEnv from inert_insts so that we include the local Given forall-constraints in the lookup. (See TcSMonad.getInstEnvs.) * topReactionsStage calls doTopReactOther for CIrredCan and CTyEqCan, so they can try to react with any given quantified constraints (TcInteract.matchLocalInst) * TcCanonical.canForAll deals with solving a forall-constraint. See Note [Solving a Wanted forall-constraint] Note [Solving a Wanted forall-constraint] * We augment the kick-out code to kick out an inert forall constraint if it can be rewritten by a new type equality; see TcSMonad.kick_out_rewritable Some other related refactoring ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Move SCC on evidence bindings to post-desugaring, which fixed #14735, and is generally nicer anyway because we can use existing CoreSyn free-var functions. (Quantified constraints made the free-vars of an ev-term a bit more complicated.) * In LookupInstResult, replace GenInst with OneInst and NotSure, using the latter for multiple matches and/or one or more unifiers }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 18:37:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 18:37:21 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF Message-ID: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs data Str a = Str !a bar :: Maybe a -> IO (Str (Maybe a)) bar x = do x' <- evaluate x pure (Str x') }}} This compiles to {{{#!hs Test.bar1 = \ (@ a_a3Ld) (x_a3Ah :: Maybe a_a3Ld) (s_i3Nz :: GHC.Prim.State# GHC.Prim.RealWorld) -> case GHC.Prim.seq# @ (Maybe a_a3Ld) @ GHC.Prim.RealWorld x_a3Ah s_i3Nz of { (# ipv_i3NC, ipv1_i3ND #) -> (# ipv_i3NC, Test.$WStr @ (Maybe a_a3Ld) ipv1_i3ND #) } }}} We suspend the application of `$WStr` to `ipv1_i3ND`, when all we actually need to do is apply `Str` directly. We could work around this in `base` by defining {{{#!hs evaluate x = IO $ \s -> case seq# x s of (# s', !x' #) -> (# s', x' #) }}} but that seems more than a little bit silly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 18:46:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 18:46:57 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF In-Reply-To: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> References: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> Message-ID: <060.0f01a97aec9e5582384945e2864d4f69@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 dfeuer): On the other hand, if there's no way to express that in the demand signature, then I guess changing `base` would be a reasonable alternative.... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 18:59:44 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 18:59:44 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF In-Reply-To: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> References: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> Message-ID: <060.afb5e8b9ea662912c50afaccde68bba6@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): Phab:D4789 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D4789 Comment: I've submitted a differential to change `evaluate` to work around the problem, but I don't like it very much. I'd love to have a primitive type of kind `Type -> TYPE UnliftedRep` that only holds things in WHNF; then we could make the primop return something of that type. But we don't have such a beast right now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 19:07:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 19:07:55 -0000 Subject: [GHC] #14939: Lint error in forall type In-Reply-To: <051.8bc9e96ca4b89b1613c7c0914d47c2a8@haskell.org> References: <051.8bc9e96ca4b89b1613c7c0914d47c2a8@haskell.org> Message-ID: <066.b5547d60ad266c22551f68392774e253@haskell.org> #14939: Lint error in forall type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | StaticPointers 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've commented on the commit on Phab. You're right that `typeKind` is wrong in this same way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 20:15:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 20:15:13 -0000 Subject: [GHC] #15225: `-fno-state-hack` produces incorrect results in nofib In-Reply-To: <047.20e2da7aa2a2e4221951af3d8807d250@haskell.org> References: <047.20e2da7aa2a2e4221951af3d8807d250@haskell.org> Message-ID: <062.f0bb7cc116c52cf6b6c150072aa710b5@haskell.org> #15225: `-fno-state-hack` produces incorrect results in nofib -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7411 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Two more test runs: - GHC with state hack, libraries without state hack, nofib without state hack triggers problem - GHC with state hack, libraries without state hack, nofib with state hack does not trigger problem So apparently, in order to trigger the problem, both nofib and libraries must be compiled with `-fno-state-hack`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 20:16:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 20:16:47 -0000 Subject: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened In-Reply-To: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> References: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> Message-ID: <061.aca28fac7c3e99c42aa67dfebb709b32@haskell.org> #15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | TypeCheckerPlugins 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 adamgundry): Replying to [comment:11 simonpj]: > > The issue here is that the wanteds are now sometimes not fully unflattened, isn't it? > > No, the reported issue (in the Description) is that a Given `CFunEqCan` remains. I believe that all Wanted `CFunEqCans` are removed. Perhaps I'm misunderstanding something, but as the Description shows, the plugin is being called with {{{ [WD] hole{co_a4or} {3}:: (F x_a4o6[tau:2] fsk_a4oc[fsk:0] :: *) ~# (p_a4o2[sk:2] :: *) (CNonCanonical) }}} including the flatten-skolem `fsk_a4oc`. Shouldn't that be unflattened to give {{{ (F x_a4o6[tau:2] (G () ()) :: *) ~# (p_a4o2[sk:2] :: *) }}} aka `(p ~ F x (G () ()))`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 20:24:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 20:24:50 -0000 Subject: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened In-Reply-To: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> References: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> Message-ID: <061.88520d3306b5a0849c7313aba852800e@haskell.org> #15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | TypeCheckerPlugins 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 adamgundry): Replying to [comment:10 nfrisby]: > My plugin is responsible for reducing some type families. Receiving flattened Wanteds appeals to me because all of the tyfam applications (except those under forall? hmmm) would be FunEq constraints, so I wouldn't have to seek them out in the types. > > So perhaps if there were a separate mechanism for the plugin to declare a custom "reducer" for a type family, that might eliminate my interest in flattened Wanteds. I've wanted such a thing as well ([wiki:Plugins/TypeChecker#Underdiscussion:Definingtypefamilies some discussion here]). It's not completely obvious what the right design is, though, because GHC's current type family reduction implementation is pure so it doesn't fit nicely with `TcPluginM`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 21:10:28 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 21:10:28 -0000 Subject: [GHC] #436: Declare large amounts of constant data In-Reply-To: <042.b3ed64b1f07e5878e56cd2b176657f2a@haskell.org> References: <042.b3ed64b1f07e5878e56cd2b176657f2a@haskell.org> Message-ID: <057.7a336517c4155fa9c572815a328de7c9@haskell.org> #436: Declare large amounts of constant data -------------------------------------+------------------------------------- Reporter: ajk | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: None Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: #9719 | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * failure: => None/Unknown * resolution: None => duplicate * wikipage: => #9719 Comment: I think this will be addressed with the solution to #9719 (https://github.com/ghc-proposals/ghc- proposals/pull/135/files?short_path=d675984#diff- d6759846a84df1af033ef6e51346e80f) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 21:12:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 21:12:12 -0000 Subject: [GHC] #15227: Add PrelRules for par# Message-ID: <045.f292885fced757ba9c18aa7457f6b1f1@haskell.org> #15227: Add PrelRules for par# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: Newcomer | 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: -------------------------------------+------------------------------------- `seq#` and `spark#` are elided when their arguments are known to be evaluated. `par#`, however, is not. Presumably this leads to sparks being created and then immediately going away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 4 21:26:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Jun 2018 21:26:47 -0000 Subject: [GHC] #8516: Add (->) representation and the Invariant class to GHC.Generics In-Reply-To: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> References: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> Message-ID: <061.43d4e5d06b8f7aed970651b92ff4c009@haskell.org> #8516: Add (->) representation and the Invariant class to GHC.Generics -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Keywords: Generics, Resolution: | QuantifiedConstraints 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 kosmikus): * cc: kosmikus (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 00:36:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 00:36:02 -0000 Subject: [GHC] #14832: QuantifiedConstraints: Adding to the context causes failure In-Reply-To: <051.dff6dedd461af3d1758ad7cdadcbf206@haskell.org> References: <051.dff6dedd461af3d1758ad7cdadcbf206@haskell.org> Message-ID: <066.e53e7333b953aa26352e9966ebcfc8be@haskell.org> #14832: QuantifiedConstraints: Adding to the context causes failure -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints 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): * keywords: QuantifiedConstraints wipT2893 => QuantifiedConstraints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 00:36:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 00:36:21 -0000 Subject: [GHC] #14877: QuantifiedConstraints: Can't deduce `xx' from `(xx => a, xx)' In-Reply-To: <051.a93bc7dc60f96bf37ae9f443b2fe178c@haskell.org> References: <051.a93bc7dc60f96bf37ae9f443b2fe178c@haskell.org> Message-ID: <066.1e1bf8b867424f039e9dab3ee9a8f5d4@haskell.org> #14877: QuantifiedConstraints: Can't deduce `xx' from `(xx => a, xx)' -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints 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): * keywords: QuantifiedConstraints, wipT2893 => QuantifiedConstraints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 00:36:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 00:36:36 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.18b94fcaf850ace9e7dd9d895555e9e8@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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:D4783 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgillespie): * differential: => Phab:D4783 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 00:37:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 00:37:13 -0000 Subject: [GHC] #14831: QuantifiedConstraints: Odd superclass constraint In-Reply-To: <051.631b3f4dec55319ae6028526fc90fcb8@haskell.org> References: <051.631b3f4dec55319ae6028526fc90fcb8@haskell.org> Message-ID: <066.0044699b2f74bfee939ac60269e651fe@haskell.org> #14831: QuantifiedConstraints: Odd superclass constraint -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints 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): * keywords: QuantifiedConstraints wipT2893 => QuantifiedConstraints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 00:37:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 00:37:36 -0000 Subject: [GHC] #14879: QuantifiedConstraints: Big error message + can't substitute (=>) with a class alias In-Reply-To: <051.9b359bfca6701741c297f67cb37814d6@haskell.org> References: <051.9b359bfca6701741c297f67cb37814d6@haskell.org> Message-ID: <066.920dcbb05132173cdb817bdf849caa74@haskell.org> #14879: QuantifiedConstraints: Big error message + can't substitute (=>) with a class alias -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints 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): * keywords: QuantifiedConstraints, wipT2893 => QuantifiedConstraints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 00:37:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 00:37:52 -0000 Subject: [GHC] #14883: QuantifiedConstraints don't kick in when used in TypeApplications In-Reply-To: <050.9ae7dfd18c1aed745c56cdebbc78f3e8@haskell.org> References: <050.9ae7dfd18c1aed745c56cdebbc78f3e8@haskell.org> Message-ID: <065.bac763e68e3ec15af48fc2fe46ea7d31@haskell.org> #14883: QuantifiedConstraints don't kick in when used in TypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints 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: QuantifiedConstraints, wipT2893 => QuantifiedConstraints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 00:38:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 00:38:16 -0000 Subject: [GHC] #14896: QuantifiedConstraints: GHC does doesn't discharge constraints if they are quantified In-Reply-To: <051.1cc6b03dde1d531c03c6cbc0cd468d33@haskell.org> References: <051.1cc6b03dde1d531c03c6cbc0cd468d33@haskell.org> Message-ID: <066.b327e37536f060b73dbe04f1407cc2d3@haskell.org> #14896: QuantifiedConstraints: GHC does doesn't discharge constraints if they are quantified -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints 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): * keywords: QuantifiedConstraints, wipT2893 => QuantifiedConstraints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 00:38:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 00:38:46 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.a04d3425aa9c4ea65eb7d96246816f88@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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:D4783 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgillespie): I added my phabricator revision, but it doesn't appear to be building (we're on Step 1 for over 24 hours now): https://phabricator.haskell.org/harbormaster/build/47009/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 00:55:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 00:55:08 -0000 Subject: [GHC] #14937: QuantifiedConstraints: Reify implication constraints from terms lacking them In-Reply-To: <044.d2a38f2a080b1fef4440349e47b3df3b@haskell.org> References: <044.d2a38f2a080b1fef4440349e47b3df3b@haskell.org> Message-ID: <059.850fd198f52e4d6a65d87d86c8a21d03@haskell.org> #14937: QuantifiedConstraints: Reify implication constraints from terms lacking them -------------------------------------+------------------------------------- Reporter: Bj0rn | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14822 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: QuantifiedConstraints, wipT2893 => QuantifiedConstraints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 00:55:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 00:55:20 -0000 Subject: [GHC] #14943: Make (=>) polykinded (:: k -> k -> Constraint) In-Reply-To: <051.6fe39954d13f1f127aabba85c357373f@haskell.org> References: <051.6fe39954d13f1f127aabba85c357373f@haskell.org> Message-ID: <066.4da2cd2a6737c3b348724a4a9076b2f1@haskell.org> #14943: Make (=>) polykinded (:: k -> k -> Constraint) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | QuantifiedConstraints 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): * keywords: QuantifiedConstraints, wipT2893 => QuantifiedConstraints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 00:55:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 00:55:38 -0000 Subject: [GHC] #14958: QuantifiedConstraints: Doesn't apply implication for existential? In-Reply-To: <051.4c7a20f12068d6c91dfb6a24439e15b7@haskell.org> References: <051.4c7a20f12068d6c91dfb6a24439e15b7@haskell.org> Message-ID: <066.e6a0a8fb584fa2225e695f705b19cd3c@haskell.org> #14958: QuantifiedConstraints: Doesn't apply implication for existential? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints 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): * keywords: QuantifiedConstraints, wipT2893 => QuantifiedConstraints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 00:56:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 00:56:24 -0000 Subject: [GHC] #14968: QuantifiedConstraints: Can't be RHS of type family instances In-Reply-To: <044.8604cb7a4154bec744684958eded781f@haskell.org> References: <044.8604cb7a4154bec744684958eded781f@haskell.org> Message-ID: <059.da4cccffe5850b37072fd9eb25f49a5e@haskell.org> #14968: QuantifiedConstraints: Can't be RHS of type family instances -------------------------------------+------------------------------------- Reporter: josef | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9269 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: QuantifiedConstraints wipT2893 => QuantifiedConstraints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 00:56:32 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 00:56:32 -0000 Subject: [GHC] #14995: QuantifiedConstraints: Incorrect pretty printing In-Reply-To: <051.242dc881fd2a4ef06fb4148e07f31348@haskell.org> References: <051.242dc881fd2a4ef06fb4148e07f31348@haskell.org> Message-ID: <066.b7f3e358e2e061188352c820f20a5ce5@haskell.org> #14995: QuantifiedConstraints: Incorrect pretty printing -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Resolution: | Keywords: | QuantifiedConstraints 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): * keywords: QuantifiedConstraints, wipT2893 => QuantifiedConstraints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 00:56:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 00:56:45 -0000 Subject: [GHC] #14983: Have custom type errors imply Void In-Reply-To: <051.6622dd708a6eb063fa490f3eeb9a127f@haskell.org> References: <051.6622dd708a6eb063fa490f3eeb9a127f@haskell.org> Message-ID: <066.1f9951543dc0478520db1a431ea507e8@haskell.org> #14983: Have custom type errors imply Void -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | CustomTypeErrors | QuantifiedConstraints 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): * keywords: CustomTypeErrors QuantifiedConstraints wipT2893 => CustomTypeErrors QuantifiedConstraints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 00:59:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 00:59:08 -0000 Subject: [GHC] #14733: Won't use (forall xx. f xx) with -XQuantifiedConstraints In-Reply-To: <051.d6dd7c53fb2316d2a32445d192b9d697@haskell.org> References: <051.d6dd7c53fb2316d2a32445d192b9d697@haskell.org> Message-ID: <066.0c6551fdc1c7a988aeaa12dbdc7e65f8@haskell.org> #14733: Won't use (forall xx. f xx) with -XQuantifiedConstraints -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: | QuantifiedConstraints 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): * keywords: QuantifiedConstraints, wipT2893 => QuantifiedConstraints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 00:59:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 00:59:19 -0000 Subject: [GHC] #14734: QuantifiedConstraints conflated with impredicative polymorphism? In-Reply-To: <051.b13ce9a287df15f46f4472a3cecc22de@haskell.org> References: <051.b13ce9a287df15f46f4472a3cecc22de@haskell.org> Message-ID: <066.70676214d43138f3cd4ae92087b20d9b@haskell.org> #14734: QuantifiedConstraints conflated with impredicative polymorphism? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: invalid | Keywords: | QuantifiedConstraints 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): * keywords: QuantifiedConstraints wipT2893 => QuantifiedConstraints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 00:59:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 00:59:38 -0000 Subject: [GHC] #14735: GHC Panic with QuantifiedConstraints In-Reply-To: <051.3a02470ddbd28d332b6dd2bb0406c5fc@haskell.org> References: <051.3a02470ddbd28d332b6dd2bb0406c5fc@haskell.org> Message-ID: <066.d259d84d3b7e350d6e047c0c4101fb74@haskell.org> #14735: GHC Panic with QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: | QuantifiedConstraints 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): * keywords: wipT2893, QuantifiedConstraints => QuantifiedConstraints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 01:09:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 01:09:06 -0000 Subject: [GHC] Batch modify: #14744, #14748, #14799, #14822, #14833, #14835, ... In-Reply-To: <132.b452223c2f31da1cfc8b00ebd1014546@haskell.org> References: <132.b452223c2f31da1cfc8b00ebd1014546@haskell.org> Message-ID: <147.a53afdac245b7674f46ddb93881f2e99@haskell.org> Batch modification to #14744, #14748, #14799, #14822, #14833, #14835, #14840, #14860, #14861, #14863, #14878, #14897, #14942, #14961, #14993, #15008 by RyanGlScott: -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 02:52:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 02:52:58 -0000 Subject: [GHC] #15178: Implement DerivingVia In-Reply-To: <050.e1bb998ddf8ec1616d3dc71e43dcc2db@haskell.org> References: <050.e1bb998ddf8ec1616d3dc71e43dcc2db@haskell.org> Message-ID: <065.4177eef49682b5a9ad43cde44c4ac0fb@haskell.org> #15178: Implement DerivingVia -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: deriving, | GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4684 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8ed8b037fee9611b1c4ef49adb6cf50bbd929a27/ghc" 8ed8b03/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8ed8b037fee9611b1c4ef49adb6cf50bbd929a27" Introduce DerivingVia This implements the `DerivingVia` proposal put forth in https://github.com/ghc-proposals/ghc-proposals/pull/120. This introduces the `DerivingVia` deriving strategy. This is a generalization of `GeneralizedNewtypeDeriving` that permits the user to specify the type to `coerce` from. The major change in this patch is the introduction of the `ViaStrategy` constructor to `DerivStrategy`, which takes a type as a field. As a result, `DerivStrategy` is no longer a simple enumeration type, but rather something that must be renamed and typechecked. The process by which this is done is explained more thoroughly in section 3 of this paper ( https://www.kosmikus.org/DerivingVia/deriving-via-paper.pdf ), although I have inlined the relevant parts into Notes where possible. There are some knock-on changes as well. I took the opportunity to do some refactoring of code in `TcDeriv`, especially the `mkNewTypeEqn` function, since it was bundling all of the logic for (1) deriving instances for newtypes and (2) `GeneralizedNewtypeDeriving` into one huge broth. `DerivingVia` reuses much of part (2), so that was factored out as much as possible. Bumps the Haddock submodule. Test Plan: ./validate Reviewers: simonpj, bgamari, goldfire, alanz Subscribers: alanz, goldfire, rwbarton, thomie, mpickering, carter GHC Trac Issues: #15178 Differential Revision: https://phabricator.haskell.org/D4684 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 02:57:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 02:57:19 -0000 Subject: [GHC] #15178: Implement DerivingVia In-Reply-To: <050.e1bb998ddf8ec1616d3dc71e43dcc2db@haskell.org> References: <050.e1bb998ddf8ec1616d3dc71e43dcc2db@haskell.org> Message-ID: <065.5c39cd0c528d35099d13ad224e59b8a3@haskell.org> #15178: Implement DerivingVia -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: deriving, | GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_fail/deriving-via- | fail{,2,3,4}, | deriving/should_compile/deriving- | via-compile, | deriving/should_compile/deriving- | via-standalone Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4684 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => deriving/should_fail/deriving-via-fail{,2,3,4}, deriving/should_compile/deriving-via-compile, deriving/should_compile /deriving-via-standalone * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 03:01:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 03:01:31 -0000 Subject: [GHC] #2893: Implement "Quantified constraints" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@haskell.org> References: <045.2638646abdcf216191d07c9810407703@haskell.org> Message-ID: <060.758e047c32420eb5d1552484815a21f2@haskell.org> #2893: Implement "Quantified constraints" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: | QuantifiedConstraints, GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5927 | Differential Rev(s): Phab:D4724 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: QuantifiedConstraints => QuantifiedConstraints, GHCProposal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 03:03:40 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 03:03:40 -0000 Subject: [GHC] #7414: plugins always trigger recompilation In-Reply-To: <045.791037be90cd943b6dd26df93dd060d8@haskell.org> References: <045.791037be90cd943b6dd26df93dd060d8@haskell.org> Message-ID: <060.dc356a6da970ea290f94c615430ef4d7@haskell.org> #7414: plugins always trigger recompilation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: feature request | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: plugin, | RecompilationCheck, GHCProposal Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12567 | Differential Rev(s): Phab:D4366 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: plugin, RecompilationCheck => plugin, RecompilationCheck, GHCProposal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 03:52:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 03:52:49 -0000 Subject: [GHC] #15228: Remove use of showSDocUnsafe in extending_ghc.rst Message-ID: <049.650bd7ca58a3da7c4bb024d6426a0cdd@haskell.org> #15228: Remove use of showSDocUnsafe in extending_ghc.rst -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- There are lots of usages of `showSDocUnsafe` in `extending_ghc.rst`. However, they are all unnecessary as far as I could see because the `Hsc` or `TcM` context has a copy of `DynFlags` in it. It should be possible to replace them all with `showSDoc`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 03:54:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 03:54:10 -0000 Subject: [GHC] #15229: Run typeCheckResultAction and renamedResultAction in TcM rather than Hsc Message-ID: <049.f951fbb4e9a6863ea169dbe4282670d0@haskell.org> #15229: Run typeCheckResultAction and renamedResultAction in TcM rather than Hsc -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: plugins | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4792 | Wiki Page: -------------------------------------+------------------------------------- The primary motivation for this is that this allows users to access the warnings and error machinery present in TcM. However, it also allows users to use TcM actions which means they can typecheck GhcPs which could be significantly easier than constructing GhcTc. See https://phabricator.haskell.org/D4792 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 03:54:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 03:54:19 -0000 Subject: [GHC] #15229: Run typeCheckResultAction and renamedResultAction in TcM rather than Hsc In-Reply-To: <049.f951fbb4e9a6863ea169dbe4282670d0@haskell.org> References: <049.f951fbb4e9a6863ea169dbe4282670d0@haskell.org> Message-ID: <064.eda153014fdf65a1bf6a8c83580a44df@haskell.org> #15229: Run typeCheckResultAction and renamedResultAction in TcM rather than Hsc -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4792 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: (none) => mpickering -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 08:48:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 08:48:19 -0000 Subject: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened In-Reply-To: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> References: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> Message-ID: <061.773bb808a092a29e57b71a1df3383edd@haskell.org> #15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | TypeCheckerPlugins 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): > Perhaps I'm misunderstanding something I didn't express it very clearly. As it stands, the Given CFunEqCan's remain, and hence so do the fsks. The Wanted CFunEqCans are removed (currently) along with the fmvs. So yes, currently Wanteds can contain fsks, whose definition is given by a CFunEqCan. I would have thought that most plugins would not find it hard to deal with that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 09:16:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 09:16:03 -0000 Subject: [GHC] #15227: Add PrelRules for par# In-Reply-To: <045.f292885fced757ba9c18aa7457f6b1f1@haskell.org> References: <045.f292885fced757ba9c18aa7457f6b1f1@haskell.org> Message-ID: <060.4dce5cf6470c5a81d7d44c560bb5317b@haskell.org> #15227: Add PrelRules for par# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Newcomer 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): That sounds plausible to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 10:05:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 10:05:07 -0000 Subject: [GHC] #15227: Add PrelRules for par# In-Reply-To: <045.f292885fced757ba9c18aa7457f6b1f1@haskell.org> References: <045.f292885fced757ba9c18aa7457f6b1f1@haskell.org> Message-ID: <060.2fdacf605bbb4083506388d0862c1ca3@haskell.org> #15227: Add PrelRules for par# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Newcomer 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 simonmar): `par#` should have been deprecated back in 7.2 when we added `spark#`. We don't use it any more. Let's just add a deprecated note to it and remove it in a future release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 11:16:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 11:16:57 -0000 Subject: [GHC] #15079: GHC HEAD regression: cannot instantiate higher-rank kind In-Reply-To: <050.d29ab0a2c8c230faa38439fac305fb8f@haskell.org> References: <050.d29ab0a2c8c230faa38439fac305fb8f@haskell.org> Message-ID: <065.d84453fb4b39f25f2e1f486cf0747cf3@haskell.org> #15079: GHC HEAD regression: cannot instantiate higher-rank kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType 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): Richard and I discussed this yesterday. We noted that: 1. The interaction between higher-rank kinds and binder visibility has many parallels with other unexpected properties of higher-rank kinds. In particular, because there are (currently) no type-level lambdas, higher- rank kinds' `foralls` are more rigid than their type-level counterparts. As one example, in #13399 it was noted that higher-rank kinds' `foralls` don't "float" like the ones in higher-rank types. In this sense, it's perhaps somewhat understandable that higher-rank kinds' visibility might also be more rigid. 2. If we wanted to have a more permissive treatment of invisible binders in higher-rank kinds, then we'd need to come up with a better story. Richard considered various ideas like having a subtyping relation between visibilities, but in the end, he concluded that anything we could think of was likely far too complicated for such little payoff. Thus, the conclusion we reached was that we should keep the current behavior, and make note of this behavior in the users' guide. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 11:22:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 11:22:08 -0000 Subject: [GHC] #2893: Implement "Quantified constraints" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@haskell.org> References: <045.2638646abdcf216191d07c9810407703@haskell.org> Message-ID: <060.5aae80d7f2f3515658003804a603dcd9@haskell.org> #2893: Implement "Quantified constraints" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 6.10.1 Resolution: fixed | Keywords: | QuantifiedConstraints, GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T2893{,a,c} Blocked By: | Blocking: Related Tickets: #5927 | Differential Rev(s): Phab:D4724 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => quantified-constraints/T2893{,a,c} * resolution: => fixed * milestone: ⊥ => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 11:27:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 11:27:21 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.d64a256ba6bd7f7683fd1b8245aec82e@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Roles, Resolution: fixed | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T9123{,a} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => quantified-constraints/T9123{,a} * status: new => closed * resolution: => fixed * milestone: => 8.6.1 Comment: `QuantifiedConstraints`, which has become GHC's //de facto// mechanism for expressing higher-kinded roles, has landed. As such, I'll opt to close this ticket, as we can now express the sorts of programs that this ticket originally desired. Some has expressed the desire for the ability to encode this information into the roles system itself, but there doesn't appear to be a clear roadpath to doing so at the moment. As such, I don't think we need to keep this issue open. (If someone //does// think of a way to encode higher- kinded roles into the roles system, I'd encourage them to open a new ticket.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 11:29:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 11:29:24 -0000 Subject: [GHC] #2256: Incompleteness of type inference: must quantify over implication constraints In-Reply-To: <046.2c6c7c4440a32ff5fbe5ad1f48bf6276@haskell.org> References: <046.2c6c7c4440a32ff5fbe5ad1f48bf6276@haskell.org> Message-ID: <061.f944502413ea3479d916ccea6e6c6a6f@haskell.org> #2256: Incompleteness of type inference: must quantify over implication constraints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 6.8.2 checker) | Keywords: Resolution: | QuantifiedConstraints 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): Simon, it's unclear what we should do with this ticket now that `QuantifiedConstraints` are in GHC. Was the intention here to actually change GHC to infer quantified constraints in certain places? My hunch is "no", especially in light of comment:16. If so, can we simply close this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 11:31:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 11:31:12 -0000 Subject: [GHC] #14863: QuantifiedConstraints: Can't deduce `c' from `(a, b)' and `a |- b |- c' In-Reply-To: <051.903b58847c266d2c5a5e433b5aee3bbf@haskell.org> References: <051.903b58847c266d2c5a5e433b5aee3bbf@haskell.org> Message-ID: <066.351f3de0e619fce352bb6c40786e6fa0@haskell.org> #14863: QuantifiedConstraints: Can't deduce `c' from `(a, b)' and `a |- b |- c' -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T14863 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => quantified-constraints/T14863 * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 11:31:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 11:31:42 -0000 Subject: [GHC] #14961: QuantifiedConstraints: introducing classes through equality constraints fails In-Reply-To: <046.a15bc00dd1f7753011e170d68fde9865@haskell.org> References: <046.a15bc00dd1f7753011e170d68fde9865@haskell.org> Message-ID: <061.0c0192e5c3425455c9f4710b75ee0f45@haskell.org> #14961: QuantifiedConstraints: introducing classes through equality constraints fails -------------------------------------+------------------------------------- Reporter: mrkgnao | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: invalid | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: quantified- valid program | constraints/T14961 Blocked By: | Blocking: Related Tickets: #14860 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => quantified-constraints/T14961 * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 11:32:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 11:32:38 -0000 Subject: [GHC] #14735: GHC Panic with QuantifiedConstraints In-Reply-To: <051.3a02470ddbd28d332b6dd2bb0406c5fc@haskell.org> References: <051.3a02470ddbd28d332b6dd2bb0406c5fc@haskell.org> Message-ID: <066.790850ca09d01ebfe4981610db2ec1bd@haskell.org> #14735: GHC Panic with QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T14735 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => typecheck/should_compile/T14735 * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 11:43:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 11:43:30 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.50307242b69d2c6fde674986dbce0e65@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.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 tdammers): Replying to [comment:22 tdammers]: > As discussed in Hangouts, the problem is even more specific: it only appears for expressions entered at the GHCi prompt while defer-type-errors is active. Loading modules with defer-type-errors on, then turning it off and *then* evaluating expressions at the prompt works just fine. It actually turns out that this isn't the case, as the following sample GHCi session illustrates: {{{ tobias at zoidberg:~/well-typed/devel/ghc-disable-defer-type-errors/ > ghc --interactive Foo.hs -fdefer-type-errors GHCi, version 8.4.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/tobias/dotfiles/ghc/.ghc/ghci.conf [1 of 1] Compiling Main ( Foo.hs, interpreted ) Ok, one module loaded. λ> test ghc: panic! (the 'impossible' happened) (GHC version 8.4.1 for x86_64-unknown-linux): nameModule system $dShow_a22M Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug λ> :set -fno-defer-type-errors λ> test ghc: panic! (the 'impossible' happened) (GHC version 8.4.1 for x86_64-unknown-linux): nameModule system $dShow_a289 Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} However this probably just means that `:set` doesn't properly unset the `fdefer-type-errors` flag. Hmm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 11:51:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 11:51:03 -0000 Subject: [GHC] #12075: Fails to build on powerpcspe because of inline assembly In-Reply-To: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> References: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> Message-ID: <062.5e412bb69b69f165779f5ae4b8a35894@haskell.org> #12075: Fails to build on powerpcspe because of inline assembly ----------------------------------------+---------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3540 Wiki Page: | ----------------------------------------+---------------------------------- Comment (by glaubitz): This can be closed as invalid. There is no additional patching necessary, GHC builds fine on PowerPC e500v2 when passing "--enable-unregisterised". Sorry for the long delay answering this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 11:57:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 11:57:44 -0000 Subject: [GHC] #15201: GHC 8.4 fails to build on Debian s390x In-Reply-To: <044.625246c98fa687e3f833d1f81c733f4b@haskell.org> References: <044.625246c98fa687e3f833d1f81c733f4b@haskell.org> Message-ID: <059.d266e50cdafa495630e9a079cedf56d6@haskell.org> #15201: GHC 8.4 fails to build on Debian s390x -------------------------------------+------------------------------ Reporter: clint | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Other Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Comment (by clint): (same symptoms on mips/mipsel/mips64el) / #15204 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 12:36:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 12:36:47 -0000 Subject: [GHC] #2256: Incompleteness of type inference: must quantify over implication constraints In-Reply-To: <046.2c6c7c4440a32ff5fbe5ad1f48bf6276@haskell.org> References: <046.2c6c7c4440a32ff5fbe5ad1f48bf6276@haskell.org> Message-ID: <061.e30a4aaab563230b44da46b104aae5db@haskell.org> #2256: Incompleteness of type inference: must quantify over implication constraints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler (Type | Version: 6.8.2 checker) | Keywords: Resolution: invalid | QuantifiedConstraints 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): * status: new => closed * resolution: => invalid Comment: Right. I don't think we plan (ever) to infer a quantified constraint. Let's just close this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 15:26:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 15:26:30 -0000 Subject: [GHC] #15230: unix tests fail under CircleCI's fedora environment Message-ID: <046.e75284c38f9e2e606bbb1d369702bf83@haskell.org> #15230: unix tests fail under CircleCI's fedora environment -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 Integration | 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's a bit unclear what is going on here: {{{ =====> getGroupEntryForName(normal) 6377 of 6403 [0, 0, 0] Actual stdout output differs from expected: --- ../../libraries/unix/tests/user001.run/user001.stdout.normalised 2018-06-05 15:18:37.243934191 +0000 +++ ../../libraries/unix/tests/user001.run/user001.run.stdout.normalised 2018-06-05 15:18:37.243934191 +0000 @@ -6,6 +6,6 @@ getEffectiveUserName: OK getGroupEntryForID: OK getGroupEntryForName: OK -getAllGroupEntries: OK +getAllGroupEntries: ERROR: getAllGroupEntries: does not exist (No such file or directory) getUserEntryForID: OK getAllUserEntries: OK *** unexpected failure for user001(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 15:30:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 15:30:24 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF In-Reply-To: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> References: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> Message-ID: <060.ccae62a4ba61dd377a2191d11061e9f3@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): Phab:D4789 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I think the right way for now is probably to stick this in `simplAlt`. When the scrutinee is `seq# x s`, we want to behave the way we would for a strict datacon field. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 16:49:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 16:49:02 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF In-Reply-To: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> References: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> Message-ID: <060.52e459769e5901b372e908d599c38042@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): Phab:D4796 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * differential: Phab:D4789 => Phab:D4796 Comment: Here's a differential to fix the problem properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 18:03:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 18:03:50 -0000 Subject: [GHC] #12075: Fails to build on powerpcspe because of inline assembly In-Reply-To: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> References: <047.7799711340d17162ce82b5c7159b8d72@haskell.org> Message-ID: <062.b0a186ca82196ada58ad83eedc9c020f@haskell.org> #12075: Fails to build on powerpcspe because of inline assembly ----------------------------------------+---------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3540 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by trommler): * status: infoneeded => closed * resolution: => fixed Comment: Thanks for your feedback @glaubitz. There was actually an issue that was fixed by @bgamari by Phab:D3560. Marking this ticket as resolved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 19:54:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 19:54:11 -0000 Subject: [GHC] #9672: Error message too long (full case statement printed) In-Reply-To: <051.99a860bf6093bb48bfa9c98f3e2d6cd2@haskell.org> References: <051.99a860bf6093bb48bfa9c98f3e2d6cd2@haskell.org> Message-ID: <066.68e38eaafddfb5fee207f514b2f79cda@haskell.org> #9672: Error message too long (full case statement printed) -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: RolandSenn Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn Comment: I'll work on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 20:14:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 20:14:34 -0000 Subject: [GHC] #15231: UndecidableInstances validity checking is wrong in the presence of QuantifiedConstraints Message-ID: <050.e69160ac4e3631edefda13f39672a247@haskell.org> #15231: UndecidableInstances validity checking is wrong in the presence of QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this program: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE QuantifiedConstraints #-} module Bug where import Data.Kind data ECC :: Constraint -> Type -> Type class Y a class Z a instance c => Y (ECC c a) instance (c => Z a) => Z (ECC c a) }}} I would expect both of these instances to work. But while GHC accepts the `Y` instance, it rejects the `Z` instance: {{{ $ ~/Software/ghc5/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:15:10: error: • Variable ‘c’ occurs more often in the constraint ‘c’ than in the instance head (Use UndecidableInstances to permit this) • In the instance declaration for ‘Z (ECC c a)’ | 15 | instance (c => Z a) => Z (ECC c a) | ^^^^^^^^^^^^^^^^^^^^^^^^^ }}} That error message seems completely bogus to me, since `c` appears once in both the context and instance head in both instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 20:19:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 20:19:43 -0000 Subject: [GHC] #15232: TypeError is reported as "redundant constraint" starting with GHC 8.2 Message-ID: <046.58a062782fd94acef2d8a01d6d6ea4fb@haskell.org> #15232: TypeError is reported as "redundant constraint" starting with GHC 8.2 -------------------------------------+------------------------------------- Reporter: fsoikin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple CustomTypeErrors | 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 following program compiles fine on GHC 8.0.2, but GHC 8.2.2 issues a warning, complaining that `TypeError` is a redundant constraint. This makes it very inconvenient to use `TypeError` with type classes. {{{#!hs {-# OPTIONS_GHC -Wredundant-constraints -Wall -Werror #-} import GHC.TypeLits (TypeError, ErrorMessage(..)) class C a where f :: a -> a instance {-# OVERLAPPING #-} C Int where f _ = 42 instance {-# OVERLAPPABLE #-} TypeError ( 'Text "Only Int is supported" ) => C a where f = undefined main :: IO () main = print $ f (42::Int) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 20:33:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 20:33:16 -0000 Subject: [GHC] #15211: exprFreeVars does not include type variables In-Reply-To: <047.2d30bc163a3c3f3a1e1fc1344efb9efd@haskell.org> References: <047.2d30bc163a3c3f3a1e1fc1344efb9efd@haskell.org> Message-ID: <062.5405399dff101a9fc056bb532e4e7dd9@haskell.org> #15211: exprFreeVars does not include type variables -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 goldfire): Yes, that's right. We'd have to export the non-closed traversals so that we can extend the traversal to terms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 20:45:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 20:45:34 -0000 Subject: [GHC] #15231: UndecidableInstances validity checking is wrong in the presence of QuantifiedConstraints In-Reply-To: <050.e69160ac4e3631edefda13f39672a247@haskell.org> References: <050.e69160ac4e3631edefda13f39672a247@haskell.org> Message-ID: <065.cce8648bc3ea74c4aef8b482d3eb6d4d@haskell.org> #15231: UndecidableInstances validity checking is wrong in the presence of QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints 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 is following [https://github.com/Gertjan423/ghc-proposals/blob /quantified-constraints/proposals/0000-quantified-constraints.rst the proposal (Section 3.7)]. Specifically, in the quantified predicate `c => Z a`, `c` does occur more often in the constraint to the left of the arrow, namely `c`, than in the head of the quantified constraint `Z a`. The error message is poor. How about this? {{{ • Variable ‘c’ occurs more often in the constraint ‘c’ than in the instance head `Z a' (Use UndecidableInstances to permit this) • In the quantified constraint `c => Z a` • In the instance declaration for ‘Z (ECC c a)’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 21:04:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 21:04:50 -0000 Subject: [GHC] #15231: UndecidableInstances validity checking is wrong in the presence of QuantifiedConstraints In-Reply-To: <050.e69160ac4e3631edefda13f39672a247@haskell.org> References: <050.e69160ac4e3631edefda13f39672a247@haskell.org> Message-ID: <065.7c804a208e2cf85ff90c07990f304e4f@haskell.org> #15231: UndecidableInstances validity checking is wrong in the presence of QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints 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): Ah, gotcha! That error message does sound like an improvement, yes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 22:37:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 22:37:11 -0000 Subject: [GHC] #15220: ScopedTypeVariables binds a non-existent variable In-Reply-To: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> References: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> Message-ID: <062.90fc71413942d270ccdfb16f02914c86@haskell.org> #15220: ScopedTypeVariables binds a non-existent variable -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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 suspect we'll end up saying that a type variable can be bound to an arbitrary type, in which case this will become moot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 5 23:43:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Jun 2018 23:43:17 -0000 Subject: [GHC] #15233: You can always set fixity of (:), with no effect Message-ID: <051.8c3b112281bc7b731cc4cf74f7b2040c@haskell.org> #15233: You can always set fixity of (:), with no effect -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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 works in a normal file {{{#!hs infixl 5 : }}} or in ghci {{{ $ ghci GHCi, version 8.5.20180314: http://www.haskell.org/ghc/ :? for help Prelude> infixr 5 : Prelude> }}} and has no effect -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 01:06:41 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 01:06:41 -0000 Subject: [GHC] #15234: WARNING in hptSomeThingsBelowUs when using a source plugin Message-ID: <049.15722b69a2f4eb74d7898931a7d1b55a@haskell.org> #15234: WARNING in hptSomeThingsBelowUs when using a source plugin -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple SourcePlugins, plugins | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When using a source plugin with a stage2 compiler built with the devel2 flavour, there are a fair few warnings about hptSomeThingsBelowUs. {{{ WARNING in hptSomeThingsBelowUs missing module CoercePlugin Probable cause: out-of-date interface files }}} I don't know if this just started happening or has been going on for a while. Is this warning cause for concern? Everything appears to work as expected despite this hiccup. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 03:15:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 03:15:36 -0000 Subject: [GHC] #14330: Sparks are not started promptly In-Reply-To: <049.15689449c051500fed95f985fcea2e55@haskell.org> References: <049.15689449c051500fed95f985fcea2e55@haskell.org> Message-ID: <064.5c1ba9f511c69065151d46a5c8910166@haskell.org> #14330: Sparks are not started promptly -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: sparks 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): The current behavior is strange, from GHC Commentary/Rts/Scheduler: > So how does the spark turn into a thread? When the scheduler spots that the current capability has no runnable threads, it checks the spark pool, and if there is a valid spark (a spark that points to a THUNK), then the spark is turned into a real thread and placed on the run queue: see createSparkThread in rts/Sparks.c. Also, the scheduler attempts to share its available sparks with any other idle capabilities: see schedulePushWork in rts/Schedule.c. Why do we have to wait until there is no runnable threads? A new spark should at least have a same priority with a new thread created with `forkIO`. The right way to do this IMHO is to ''always'' check the sparks pool within one scheduling loop, this can be done by start a sparks thread dedicated to check sparks just like I/O or timer manager. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 09:42:53 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 09:42:53 -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.4f15d0d752dce35495ff1cb40358ee45@haskell.org> #13564: Why does memory usage increase so much during CoreTidy? -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.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:D3516, Wiki Page: | Phab:D3524 -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Isn't this ticket fixed? Is CoreTidy pass still leaking in 8.4? Or is the ticket dangling, because the in-code docs can be improved, as in https://phabricator.haskell.org/D3524#100418? I'm asking, because I'm trying to make #13586 more useful (split or narrow down). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 11:47:17 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 11:47:17 -0000 Subject: [GHC] #15235: GHCi's claim of infixr 0 (->) is a lie Message-ID: <050.1dea13c2dffcf4fb3726d468418c6455@haskell.org> #15235: GHCi's claim of infixr 0 (->) is a lie -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Currently, if you query the `:info` for `(->)` in GHCi, it will give you: {{{ $ ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci λ> :i (->) data (->) (a :: TYPE q) (b :: TYPE r) -- Defined in ‘GHC.Prim’ infixr 0 `(->)` }}} This fixity information appears to be plain wrong, as the following program demonstrates: {{{#!hs {-# LANGUAGE TypeOperators #-} module Bug where import Data.Type.Equality type (~>) = (->) infixr 0 ~> f :: (a ~> b -> c) :~: (a ~> (b -> c)) f = Refl }}} Since `(~>)` and `(->)` are both `infixr 0`, I would expect `a ~> b -> c` to associate as `a ~> (b -> c)`, like the type signature for `f` wants to prove. However, GHC believes otherwise: {{{ $ ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:10:5: error: • Occurs check: cannot construct the infinite type: a ~ a ~> b Expected type: ((a ~> b) -> c) :~: (a ~> (b -> c)) Actual type: ((a ~> b) -> c) :~: ((a ~> b) -> c) • In the expression: Refl In an equation for ‘f’: f = Refl • Relevant bindings include f :: ((a ~> b) -> c) :~: (a ~> (b -> c)) (bound at Bug.hs:10:1) | 10 | f = Refl | ^^^^ }}} Reading the error message above, it appears that GHC gives `(->)` an even //lower// precedence than 0, since it associates `a ~> b -> c` as `(a ~> b) -> c`. I'm not sure how to reconcile these two facts. There are at least a couple of options I can think of: 1. Claim `(->)` has a negative fixity. 2. Try to change GHC so that `(->)` really is `infixr 0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 12:43:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 12:43:46 -0000 Subject: [GHC] #14713: GHCi doesn't load project. In-Reply-To: <054.d7ecad76c2756183240fb99c0fdc5e86@haskell.org> References: <054.d7ecad76c2756183240fb99c0fdc5e86@haskell.org> Message-ID: <069.2b99c4d4051395bb7019dc36653546e8@haskell.org> #14713: GHCi doesn't load project. -------------------------------------+------------------------------------- Reporter: recursion-ninja | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by quasicomputational): I'm having a look at this. I've got it reproducing locally with commit 6f1dfdf1513d7c6c55bc63606711c90643bf4dc4 from that repository, and I'm just trying to cut it down to a smaller GHC-only example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 13:55:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 13:55:20 -0000 Subject: [GHC] #15236: GHCi pretty-prints (->)'s fixity poorly Message-ID: <050.434b168bbf33573a386a6904db5f1ad2@haskell.org> #15236: GHCi pretty-prints (->)'s fixity poorly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Consider the following GHCi session: {{{ $ ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :i (->) data (->) (a :: TYPE q) (b :: TYPE r) -- Defined in ‘GHC.Prim’ infixr 0 `(->)` }}} Notice that it prints: {{{ `(->)` }}} Which is totally wrong. This should simply be `->`. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 14:05:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 14:05:28 -0000 Subject: [GHC] #15236: GHCi pretty-prints (->)'s fixity poorly In-Reply-To: <050.434b168bbf33573a386a6904db5f1ad2@haskell.org> References: <050.434b168bbf33573a386a6904db5f1ad2@haskell.org> Message-ID: <065.88a8e911023a4f1a026751107f76ae11@haskell.org> #15236: GHCi pretty-prints (->)'s fixity poorly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4799 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4799 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 14:55:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 14:55:13 -0000 Subject: [GHC] #15237: New SRT scheme breaks -fvia-C Message-ID: <046.e3fad0365f09ac73a9b55199ebd3f969@haskell.org> #15237: New SRT scheme breaks -fvia-C -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- The SRT rework implemented in 2b0918c9834be1873728176e4944bec26271234a introduces a sub-word-size field into `StgSRT`. Unfortunately `-fvia-C` doesn't support such fields. This breaks CircleCI's unregisterised target. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 15:04:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 15:04:51 -0000 Subject: [GHC] #15218: HEAD doesn't build without sphinx-build In-Reply-To: <042.48e52db875cf86898104c8cf24945fa7@haskell.org> References: <042.48e52db875cf86898104c8cf24945fa7@haskell.org> Message-ID: <057.fa0efcdf67835599d467681dcb7162b8@haskell.org> #15218: HEAD doesn't build without sphinx-build -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: Build System | Version: 8.4.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm not sure I agree that `validate` should pass if sphinx-build is missing. `Validate` is intended to serve as a comprehensive check of the tree; this includes checking that the documentation is buildable. If you want to build without documentation, I would suggest not using `validate` and configure `mk/build.mk` appropriately: {{{ BUILD_SPHINX_HTML = NO BUILD_SPHINX_PDF = NO }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 15:16:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 15:16:36 -0000 Subject: [GHC] #14713: GHCi doesn't load project. In-Reply-To: <054.d7ecad76c2756183240fb99c0fdc5e86@haskell.org> References: <054.d7ecad76c2756183240fb99c0fdc5e86@haskell.org> Message-ID: <069.f909a41f1c6c7dd350e5ebaa3dcd21f1@haskell.org> #14713: GHCi doesn't load project. -------------------------------------+------------------------------------- Reporter: recursion-ninja | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by quasicomputational): Note that `numStates_g` is declared `extern` in `ukkCheckPoint.c` via `ukkCommon.h`, and is actually defined in `ukkCommon.c`. If we inspect the command line passed to GHC, we see that `ukkCheckPoint.o` appears before `ukkCommon.o`. Reducing to a tiny example, we can reproduce the bug: {{{ $ cat a.c int numStates_g = 42; $ cat b.c extern int numStates_g; int foo(int a) { return a + numStates_g; } $ gcc -c a.c $ gcc -c b.c $ ghc --interactive a.o b.o GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help Prelude> :q Leaving GHCi. $ ghc --interactive b.o a.o GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 8.4.2 for i386-unknown-linux): Loading temp shared object failed: /tmp/ghc12016_0/libghc_1.so: undefined symbol: numStates_g Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} So GHCi is sensitive to the ordering of `.o` files passed on the command line. This is already known as #13786, so I guess this issue's a duplicate. I've verified that the reproduction repo works with GHCi if the definitions are moved into `ukkCheckPoint.c`, which is a work-around. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 15:17:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 15:17:44 -0000 Subject: [GHC] #14713: GHCi doesn't load project. In-Reply-To: <054.d7ecad76c2756183240fb99c0fdc5e86@haskell.org> References: <054.d7ecad76c2756183240fb99c0fdc5e86@haskell.org> Message-ID: <069.e53ca306e1afcdf6c7f0418c575e2d8a@haskell.org> #14713: GHCi doesn't load project. -------------------------------------+------------------------------------- Reporter: recursion-ninja | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by quasicomputational): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 15:24:31 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 15:24:31 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.c0103b648c2d7ffb3aba576636591db0@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.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 tdammers): The `:set` turns out to work just fine; I trapped the DynFlags right where GHCi runs those expressions, and both flags that control deferred type errors are now forced off; yet the panic still occurs when running ghci with `-fdefer-type-errors`. From the error message, it seems to me like GHCi is trying to print a module name, but fails, and this only happens when starting up with deferred type errors. I assume the module in question is the `Foo` module just loaded. Another data point is that the panic does not occur when I change the `Foo` module like so: {{{ module Foo where test :: IO () test = return () }}} My hypothesis here is that because GHCi does not print the result of an IO action if its type is `()`, so the whole pretty-printing machinery doesn't run. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 15:24:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 15:24:32 -0000 Subject: [GHC] #12023: Problems getting information and kind from GHC.Prim ~#, ~R#, ... In-Reply-To: <051.e18556256e79a3a1dab6064a1d75c6d2@haskell.org> References: <051.e18556256e79a3a1dab6064a1d75c6d2@haskell.org> Message-ID: <066.238ef62406d56c09894aa6a346bb5977@haskell.org> #12023: Problems getting information and kind from GHC.Prim ~#, ~R#, ... -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | 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: #10059, #15209 | Differential Rev(s): Phab:D4801 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4801 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 15:25:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 15:25:07 -0000 Subject: [GHC] #15209: ~# is always in scope with TypeOperators In-Reply-To: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> References: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> Message-ID: <060.82e26d22850aeff5ab09a3fd578dfd50@haskell.org> #15209: ~# is always in scope with TypeOperators -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4763, Wiki Page: | Phab:D4801 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: Phab:D4763 => Phab:D4763, Phab:D4801 Comment: Phab:D4801 fixes the remaining issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 15:25:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 15:25:55 -0000 Subject: [GHC] #15238: T13838 fails in ghci way Message-ID: <046.a757024938d0b3ba3bb6900057f32c31@haskell.org> #15238: T13838 fails in ghci way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- {{{ Wrong exit code for T13838(ghci) (expected 1 , actual 0 ) Stderr ( T13838 ): T13838:6:30: error: • Couldn't match expected type ‘IO a0’ with actual type ‘() -> ()’ • Probable cause: ‘main’ is applied to too few arguments In the first argument of ‘GHC.TopHandler.runIOFastExit’, namely ‘main’ In the first argument of ‘(>>)’, namely ‘GHC.TopHandler.runIOFastExit main’ In the expression: GHC.TopHandler.runIOFastExit main >> return () *** unexpected failure for T13838(ghci) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 16:04:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 16:04:37 -0000 Subject: [GHC] #15239: Is there an issue with Haskell GHC 8.4.3 on Travis? Message-ID: <044.17aaafc1d49b4b960e98036021c03c2b@haskell.org> #15239: Is there an issue with Haskell GHC 8.4.3 on Travis? -------------------------------------+------------------------------------- Reporter: Orome | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Installing GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- My Travis builds ([https://travis-ci.org/orome/crypto-enigma- hs/jobs/388291576]) are failing when they attempt to install using the nightly resolver (since 8.4.3) with: {{{ $ stack --resolver $RESOLVER --no-terminal --install-ghc test --only- dependencies Selected resolver: nightly-2018-06-05 Downloading nightly-2018-06-05 build plan ... Downloaded nightly-2018-06-05 build plan. Preparing to install GHC to an isolated location. This will not interfere with any system-level installation. Preparing to download ghc-8.4.3 ... ghc-8.4.3: download has begun ghc-8.4.3: 15.21 MiB / 144.83 MiB ( 10.50%) downloaded... ghc-8.4.3: 37.85 MiB / 144.83 MiB ( 26.13%) downloaded... ghc-8.4.3: 61.16 MiB / 144.83 MiB ( 42.23%) downloaded... ghc-8.4.3: 76.60 MiB / 144.83 MiB ( 52.89%) downloaded... ghc-8.4.3: 91.49 MiB / 144.83 MiB ( 63.17%) downloaded... ghc-8.4.3: 115.03 MiB / 144.83 MiB ( 79.42%) downloaded... ghc-8.4.3: 138.27 MiB / 144.83 MiB ( 95.47%) downloaded... ghc-8.4.3: 144.83 MiB / 144.83 MiB (100.00%) downloaded... Downloaded ghc-8.4.3. Unpacking GHC into /home/travis/.stack/programs/x86_64-linux/ghc-8.4.3.temp/ ... Configuring GHC ... Installing GHC ... Received ExitFailure 2 when running Raw command: /usr/bin/make install Run from: /home/travis/.stack/programs/x86_64-linux/ghc-8.4.3.temp/ghc-8.4.3/ The command "stack --resolver $RESOLVER --no-terminal --install-ghc test --only-dependencies" failed and exited with 1 during . }}} Is there a problem with 8.4.3 on Travis? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 17:47:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 17:47:55 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.1af31a3e40256e23b58bfd3747771f1e@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.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 tdammers): Another data point; the Core ghci generates with `-fdefer-type-errors` is slightly different from the normal output: {{{#!diff --- Foo-defer.dump-simpl 2018-06-06 17:53:34.436841703 +0200 +++ Foo.dump-simpl 2018-06-06 19:44:00.385228438 +0200 @@ -1,39 +1,39 @@ ==================== Tidy Core ==================== -2018-06-06 15:53:34.440330463 UTC +2018-06-06 17:44:00.38910864 UTC Result size of Tidy Core = {terms: 19, types: 9, coercions: 0, joins: 0/0} --- RHS size: {terms: 4, types: 2, coercions: 0, joins: 0/0} -test :: IO Int -[GblId] -test - = break<0>() return @ IO GHC.Base.$fMonadIO @ Int (GHC.Types.I# 1#) - -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} -$trModule1_r1Ss :: GHC.Prim.Addr# +$trModule1_r1Sr :: GHC.Prim.Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] -$trModule1_r1Ss = "main"# +$trModule1_r1Sr = "main"# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} -$trModule2_r1SD :: GHC.Types.TrName +$trModule2_r1SC :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] -$trModule2_r1SD = GHC.Types.TrNameS $trModule1_r1Ss +$trModule2_r1SC = GHC.Types.TrNameS $trModule1_r1Sr -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} -$trModule3_r1SE :: GHC.Prim.Addr# +$trModule3_r1SD :: GHC.Prim.Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] -$trModule3_r1SE = "Main"# +$trModule3_r1SD = "Main"# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} -$trModule4_r1SF :: GHC.Types.TrName +$trModule4_r1SE :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] -$trModule4_r1SF = GHC.Types.TrNameS $trModule3_r1SE +$trModule4_r1SE = GHC.Types.TrNameS $trModule3_r1SD -- RHS size: {terms: 3, types: 0, coercions: 0, joins: 0/0} Main.$trModule :: GHC.Types.Module [GblId, Caf=NoCafRefs, Unf=OtherCon []] -Main.$trModule = GHC.Types.Module $trModule2_r1SD $trModule4_r1SF +Main.$trModule = GHC.Types.Module $trModule2_r1SC $trModule4_r1SE + +-- RHS size: {terms: 4, types: 2, coercions: 0, joins: 0/0} +test :: IO Int +[GblId] +test + = break<0>() return @ IO GHC.Base.$fMonadIO @ Int (GHC.Types.I# 1#) }}} The only differences however are due to uniques not matching up, and putting `main` first instead of last. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 18:11:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 18:11:02 -0000 Subject: [GHC] #15079: GHC HEAD regression: cannot instantiate higher-rank kind In-Reply-To: <050.d29ab0a2c8c230faa38439fac305fb8f@haskell.org> References: <050.d29ab0a2c8c230faa38439fac305fb8f@haskell.org> Message-ID: <065.f13372513a09665d90e55c3dc3a03dcd@haskell.org> #15079: GHC HEAD regression: cannot instantiate higher-rank kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType 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:D4803 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4803 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 18:12:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 18:12:07 -0000 Subject: [GHC] #11498: GHC requires kind-polymorphic signatures on class head In-Reply-To: <047.c869cb625243c8891f031146b4e58720@haskell.org> References: <047.c869cb625243c8891f031146b4e58720@haskell.org> Message-ID: <062.235be99361587af847287a42bccad7e0@haskell.org> #11498: GHC requires kind-polymorphic signatures on class head -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2-rc2 checker) | Resolution: | Keywords: CUSKs 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: => CUSKs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 18:34:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 18:34:30 -0000 Subject: [GHC] #15239: Is there an issue with Haskell GHC 8.4.3 on Travis? In-Reply-To: <044.17aaafc1d49b4b960e98036021c03c2b@haskell.org> References: <044.17aaafc1d49b4b960e98036021c03c2b@haskell.org> Message-ID: <059.f9b821c042fef969a722252dc0cec6e2@haskell.org> #15239: Is there an issue with Haskell GHC 8.4.3 on Travis? -------------------------------------+------------------------------------- Reporter: Orome | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): I haven't experienced any issues w/ GHC 8.4.3 on Travis; see e.g. https ://travis-ci.org/haskell-hvr/HsYAML/builds/388502153 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 18:36:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 18:36:42 -0000 Subject: [GHC] #13471: segmentation fault by compiling GHC In-Reply-To: <044.dfe54ba36723fa52739de02cb7d53d4c@haskell.org> References: <044.dfe54ba36723fa52739de02cb7d53d4c@haskell.org> Message-ID: <059.6f2af458e8914d45c6130306362148b7@haskell.org> #13471: segmentation fault by compiling GHC -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.0.2 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: infoneeded => closed * resolution: => fixed Comment: It seems pretty clear that the original problem here was the user was running out of memory. I believe I have fixed the segmentation fault on out-of-memory condition, so we should fail more gracefully now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 19:20:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 19:20:12 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.68c7e0ec583d097e0885fcfd101e6b5f@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4780 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Unfortunately this appears to break on Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 19:20:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 19:20:43 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.d27eee9be877d35a8fa325010f0cb14c@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: D4780 => Phab:D4781 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 19:51:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 19:51:48 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF In-Reply-To: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> References: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> Message-ID: <060.6e4ea45dac9438d508d590e76d55ddf0@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): Phab:D4796 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"d964b054d530ea9e29ed051fdf2b49a6afe465fb/ghc" d964b05/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d964b054d530ea9e29ed051fdf2b49a6afe465fb" Let the simplifier know that seq# forces Add a special case in `simplAlt` to record that the result of `seq#` is in WHNF. Reviewers: simonmar, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #15226 Differential Revision: https://phabricator.haskell.org/D4796 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 20:08:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 20:08:18 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF In-Reply-To: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> References: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> Message-ID: <060.54e8c2d5fc1834efa2f5a1f7be21bae5@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): Phab:D4796 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => merge Comment: I think this is likely simple enough to merge. We still don't mark the ''argument'' to `seq#` as evaluated in the case branch: {{{#!hs do _ <- evaluate x pure (Str x) }}} will still think it has to force `x` again. I suspect there are likely users doing such things. I think the fix should be really simple, but I don't know how to do it. We should (I believe) rewrite {{{#!hs case seq# x s of (# s', x' #) -> E }}} to {{{#!hs case seq# x s of (# s', x' #) -> E [x -> x'] }}} In principle, we could do something like that for `spark#` as well, but it's probably better to let threads fizzle than to let users rely on the optimizer to make their parallel code do what they expect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 20:14:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 20:14:46 -0000 Subject: [GHC] #15218: HEAD doesn't build without sphinx-build In-Reply-To: <042.48e52db875cf86898104c8cf24945fa7@haskell.org> References: <042.48e52db875cf86898104c8cf24945fa7@haskell.org> Message-ID: <057.1dba440728a53575ef28e1235a6afcbe@haskell.org> #15218: HEAD doesn't build without sphinx-build -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: Build System | Version: 8.4.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by jrp): Well, I'm not sure what I did, but it used to validate without sphinx- build. Now even with sphinx-build, I get {{{ "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O0 -H64m -Wall -Werror -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/src -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 Cabal-2.3.0.0 -package-id array-0.5.2.0 -package-id base-4.12.0.0 -package-id bytestring-0.10.8.2 -package-id containers-0.5.11.0 -package-id deepseq-1.4.4.0 -package-id directory-1.3.2.3 -package-id filepath-1.4.2 -package-id ghc-8.5 -package- id ghc-boot-8.5 -package-id transformers-0.5.5.0 -package-id xhtml-3000.2.2 -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- library/vendor/attoparsec-0.13.1.0/Data/Attoparsec/ByteString/Char8.hs -o utils/haddock/dist/build/Data/Attoparsec/ByteString/Char8.dyn_o "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O0 -H64m -Wall -Werror -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/src -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 Cabal-2.3.0.0 -package-id array-0.5.2.0 -package-id base-4.12.0.0 -package-id bytestring-0.10.8.2 -package-id containers-0.5.11.0 -package-id deepseq-1.4.4.0 -package-id directory-1.3.2.3 -package-id filepath-1.4.2 -package-id ghc-8.5 -package- id ghc-boot-8.5 -package-id transformers-0.5.5.0 -package-id xhtml-3000.2.2 -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- library/vendor/attoparsec-0.13.1.0/Data/Attoparsec.hs -o utils/haddock/dist/build/Data/Attoparsec.dyn_o Warning: -rtsopts and -with-rtsopts have no effect with -shared. Call hs_init_ghc() from your main() function to set these options. utils/haddock/haddock-api/src/Haddock/Interface/Rename.hs:546:40: error: • Couldn't match type ‘GhcPass 'Renamed’ with ‘DocNameI’ Expected type: Maybe (LDerivStrategy DocNameI) Actual type: Maybe (LDerivStrategy GhcRn) • In the ‘deriv_strategy’ field of a record In the first argument of ‘return’, namely ‘(DerivDecl {deriv_ext = noExt, deriv_type = ty', deriv_strategy = strat, deriv_overlap_mode = omode})’ In a stmt of a 'do' block: return (DerivDecl {deriv_ext = noExt, deriv_type = ty', deriv_strategy = strat, deriv_overlap_mode = omode}) | 546 | , deriv_strategy = strat | ^^^^^ utils/haddock/ghc.mk:20: recipe for target 'utils/haddock/dist/build/Haddock/Interface/Rename.dyn_o' failed make[1]: *** [utils/haddock/dist/build/Haddock/Interface/Rename.dyn_o] Error 1 make[1]: *** Waiting for unfinished jobs.... Makefile:122: recipe for target 'all' failed }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 20:47:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 20:47:00 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.4fd50bba9bd30290493305df805f3604@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.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 tdammers): However the dumped Core for the interactive expression itself seems to depend only on whether type error deferring was active while loading the module. Evaluating `test` interactively without `-fdefer-type-errors`: {{{ ==================== Simplified expression ==================== GHC.Base.returnIO @ [()] (GHC.Types.: @ () ((GHC.Base.. @ (GHC.Types.IO GHC.Base.String) @ (GHC.Types.IO GHC.Base.String) @ [GHC.Types.Char] (GHC.GHCi.ghciStepIO @ GHC.Types.IO GHC.GHCi.$fGHCiSandboxIOIO @ GHC.Base.String) (\ (s_a1z7 :: [GHC.Types.Char]) -> GHC.Base.$ @ 'GHC.Types.LiftedRep @ [GHC.Types.Char] @ (GHC.Types.IO GHC.Base.String) (GHC.Base.return @ GHC.Types.IO GHC.Base.$fMonadIO @ [GHC.Types.Char]) (GHC.Base.++ @ GHC.Types.Char (GHC.CString.unpackCString# ":! pointfree \""#) (GHC.Base.++ @ GHC.Types.Char s_a1z7 (GHC.CString.unpackCString# "\""#))))) `cast` (UnsafeCo representational (GHC.Base.String -> GHC.Types.IO GHC.Base.String) () :: (GHC.Base.String -> GHC.Types.IO GHC.Base.String) ~R# ())) (GHC.Types.[] @ ())) }}} With `-fdefer-type-errors`: {{{ ==================== Simplified expression ==================== GHC.Base.bindIO @ GHC.Types.Int @ [()] (GHC.GHCi.ghciStepIO @ GHC.Types.IO GHC.GHCi.$fGHCiSandboxIOIO @ GHC.Types.Int Main.test) (\ (it_a1CU :: GHC.Types.Int) -> GHC.Base.thenIO @ () @ [()] (System.IO.print @ GHC.Types.Int $dShow_a1Rt it_a1CU) (GHC.Base.returnIO @ [()] (GHC.Types.: @ () (it_a1CU `cast` (UnsafeCo representational GHC.Types.Int () :: GHC.Types.Int ~R# ())) (GHC.Types.[] @ ())))) }}} Whether I issue `:set -fno-defer-type-errors` before invoking `test` or not makes absolutely no difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 20:49:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 20:49:30 -0000 Subject: [GHC] #14487: Can't Hide Field When DuplicateRecordFields Is Enabled In-Reply-To: <052.55fcb5f24afe31abafd77e2adcf88ad5@haskell.org> References: <052.55fcb5f24afe31abafd77e2adcf88ad5@haskell.org> Message-ID: <067.2cef235887b8e61641ec65b5c3d25a19@haskell.org> #14487: Can't Hide Field When DuplicateRecordFields Is Enabled -------------------------------------+------------------------------------- Reporter: iansullivan88 | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | DuplicateRecordFields ORF Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 20:49:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 20:49:56 -0000 Subject: [GHC] #14783: Initializing record with similarly named field from a different record results in warning rather than error In-Reply-To: <053.5b725cc1d4e4c8f45180bb4a879fba30@haskell.org> References: <053.5b725cc1d4e4c8f45180bb4a879fba30@haskell.org> Message-ID: <068.c0c63686773cd1465c93dfb3212634c5@haskell.org> #14783: Initializing record with similarly named field from a different record results in warning rather than error -------------------------------------+------------------------------------- Reporter: ulrikrasmussen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: records | DuplicateRecordFields ORF 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 adamgundry): * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 21:25:58 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 21:25:58 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF In-Reply-To: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> References: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> Message-ID: <060.b4d3711c8492805727602ef03fcb8973@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): Phab:D4796 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > We should (I believe) rewrite Yes -- this is a variant of the case binder-swap in `OccurAnal`. See `Note [Binder swap]` in `OccurAnal`. This is the place to do it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 21:35:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 21:35:43 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF In-Reply-To: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> References: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> Message-ID: <060.8fded409862e0e90c7f5ff742a92a8e6@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): Phab:D4796 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:7 simonpj]: > > We should (I believe) rewrite > > Yes -- this is a variant of the case binder-swap in `OccurAnal`. See `Note [Binder swap]` in `OccurAnal`. This is the place to do it. I eventually found that, but I'm not at all sure how to deal with coercions in that context. We could, for example, have something like {{{#!hs case seq# x a `cast` ... of (# s', x' #) -> ... }}} in which case we have to work out how to rejigger all the coercions. I don't know enough about that machinery yet. In the current `OccurAnal` code, the coercion in the scrutinee is always on a variable, but here it's on a pair containing the variable, so I'm not going to be able to code monkey it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 22:14:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 22:14:59 -0000 Subject: [GHC] #15240: GHCi's :doc doesn't find the documentation for some class methods Message-ID: <046.ede54e8388156191497230366321bb0a@haskell.org> #15240: GHCi's :doc doesn't find the documentation for some class methods -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While `:doc` reliably finds the docs for classes like Foldable and Monad, it fails for some methods. {{{ λ :doc return Inject a value into the monadic type. λ :doc foldr λ :doc show }}} So far I haven't been able to see a pattern there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 22:33:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 22:33:30 -0000 Subject: [GHC] #15240: GHCi's :doc doesn't find the documentation for some class methods In-Reply-To: <046.ede54e8388156191497230366321bb0a@haskell.org> References: <046.ede54e8388156191497230366321bb0a@haskell.org> Message-ID: <061.55ddcba76b5d8fa712a8c777b473ca1d@haskell.org> #15240: GHCi's :doc doesn't find the documentation for some class methods -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 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: | -------------------------------------+------------------------------------- Comment (by sjakobi): `--show-iface` reveals that e.g. `GHC/Show.hi` ''does'' contain docs for `show`: {{{ show: " A specialised variant of 'showsPrec', using precedence context zero, and returning an ordinary 'String'." }}} So either we're loading the wrong iface our `Name` isn't the same as the one in the `DeclDocMap`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 6 22:39:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Jun 2018 22:39:51 -0000 Subject: [GHC] #14229: Contraditions in users_guide/using-warnings.html In-Reply-To: <054.d6f9d16cc1b1fa988ffa9396c0d0581c@haskell.org> References: <054.d6f9d16cc1b1fa988ffa9396c0d0581c@haskell.org> Message-ID: <069.ed807fe29e805075e6a7f3ff40da0ee4@haskell.org> #14229: Contraditions in users_guide/using-warnings.html -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: voanhduy1512 Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4528, Wiki Page: | Phab:D4562 -------------------------------------+------------------------------------- Comment (by MikolajKonarski): There is a new comment Phab (I know there were problems with notification emails recently): https://phabricator.haskell.org/D4562#128940 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 02:27:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 02:27:00 -0000 Subject: [GHC] #13573: Add Foldable1 to base In-Reply-To: <051.5343934480dda921b1b6981f18b39763@haskell.org> References: <051.5343934480dda921b1b6981f18b39763@haskell.org> Message-ID: <066.64bd0bc0d549f1f917e93bdd74f5f7e0@haskell.org> #13573: Add Foldable1 to base -------------------------------------+------------------------------------- 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: #10365 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by recursion-ninja): A related discussion: https://github.com/ekmett/semigroupoids/issues/26 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 02:54:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 02:54:00 -0000 Subject: [GHC] #13573: Add Foldable1 to base In-Reply-To: <051.5343934480dda921b1b6981f18b39763@haskell.org> References: <051.5343934480dda921b1b6981f18b39763@haskell.org> Message-ID: <066.3e993fd9b781394a6f92b38b393af6f0@haskell.org> #13573: Add Foldable1 to base -------------------------------------+------------------------------------- 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: #10365 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chshersh): Alternative naming option would be `NonEmptyFoldable` or `FoldableNE` or something similar. But this is either long or non-uniform. `Foldable1` is good enough. And we probably won't need type classes like `Eq1` and `Show1` in future since we have `QuantifiedConstraints` landed in GHC. In some moment of time they can be deprecated and removed. So we only need to prepare for StackOverflow and Reddit questions like ''Why `Eq1` and `Show1` are different from `Eq` and `Show` in not the same way as `Foldable1` from `Foldable`?''. But I guess this is manageable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 04:30:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 04:30:11 -0000 Subject: [GHC] #15241: T2783 fails a sanity test Message-ID: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> #15241: T2783 fails a sanity test -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime | Version: 8.4.3 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: -------------------------------------+------------------------------------- {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.2 $ ghc test.hs -fforce-recomp -debug -rtsopts [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... $ ./test +RTS -DS test: internal error: ASSERTION FAILED: file rts/ThreadPaused.c, line 314 Stack trace: test: Failed to get stack frames of current process: no matching address range: Success 0x4a3fbd set_initial_registers (rts/Libdw.c:288.0) 0x7f9d70fd7a18 dwfl_thread_getframes (/usr/lib/x86_64 -linux-gnu/libdw-0.170.so) 0x7f9d70fd7efc dwfl_getthread_frames (/usr/lib/x86_64 -linux-gnu/libdw-0.170.so) 0x4a3eb6 libdwGetBacktrace (rts/Libdw.c:257.0) 0x474de3 rtsFatalInternalErrorFn (rts/RtsMessages.c:171.0) 0x474ad0 barf (rts/RtsMessages.c:48.0) 0x474b02 errorBelch (rts/RtsMessages.c:67.0) 0x479273 threadPaused (rts/ThreadPaused.c:318.0) 0x48ccdb stg_returnToSched (rts/StgStartup.cmm:117.1) 0x48f428 stg_enter_info (rts/HeapStackCheck.cmm:166.1) 0x45fd18 integerzmgmp_GHCziIntegerziType_minusInteger_info (/home/omer/haskell/test) (GHC version 8.4.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./test +RTS -DS }}} Note tested with HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 04:30:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 04:30:24 -0000 Subject: [GHC] #15241: T2783 fails a sanity test In-Reply-To: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> References: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> Message-ID: <058.798e9fd5fece5f60ffa67933c0a443b0@haskell.org> #15241: T2783 fails a sanity test -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.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 osa1: Old description: > {{{ > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 8.4.2 > > $ ghc test.hs -fforce-recomp -debug -rtsopts > [1 of 1] Compiling Main ( test.hs, test.o ) > Linking test ... > > $ ./test +RTS -DS > test: internal error: ASSERTION FAILED: file rts/ThreadPaused.c, line 314 > > Stack trace: > test: Failed to get stack frames of current process: no matching address > range: Success > 0x4a3fbd set_initial_registers (rts/Libdw.c:288.0) > 0x7f9d70fd7a18 dwfl_thread_getframes (/usr/lib/x86_64 > -linux-gnu/libdw-0.170.so) > 0x7f9d70fd7efc dwfl_getthread_frames (/usr/lib/x86_64 > -linux-gnu/libdw-0.170.so) > 0x4a3eb6 libdwGetBacktrace (rts/Libdw.c:257.0) > 0x474de3 rtsFatalInternalErrorFn > (rts/RtsMessages.c:171.0) > 0x474ad0 barf (rts/RtsMessages.c:48.0) > 0x474b02 errorBelch (rts/RtsMessages.c:67.0) > 0x479273 threadPaused (rts/ThreadPaused.c:318.0) > 0x48ccdb stg_returnToSched > (rts/StgStartup.cmm:117.1) > 0x48f428 stg_enter_info > (rts/HeapStackCheck.cmm:166.1) > 0x45fd18 > integerzmgmp_GHCziIntegerziType_minusInteger_info > (/home/omer/haskell/test) > > (GHC version 8.4.2 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > zsh: abort (core dumped) ./test +RTS -DS > }}} > > Note tested with HEAD. New description: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.2 $ ghc test.hs -fforce-recomp -debug -rtsopts [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... $ ./test +RTS -DS test: internal error: ASSERTION FAILED: file rts/ThreadPaused.c, line 314 Stack trace: test: Failed to get stack frames of current process: no matching address range: Success 0x4a3fbd set_initial_registers (rts/Libdw.c:288.0) 0x7f9d70fd7a18 dwfl_thread_getframes (/usr/lib/x86_64 -linux-gnu/libdw-0.170.so) 0x7f9d70fd7efc dwfl_getthread_frames (/usr/lib/x86_64 -linux-gnu/libdw-0.170.so) 0x4a3eb6 libdwGetBacktrace (rts/Libdw.c:257.0) 0x474de3 rtsFatalInternalErrorFn (rts/RtsMessages.c:171.0) 0x474ad0 barf (rts/RtsMessages.c:48.0) 0x474b02 errorBelch (rts/RtsMessages.c:67.0) 0x479273 threadPaused (rts/ThreadPaused.c:318.0) 0x48ccdb stg_returnToSched (rts/StgStartup.cmm:117.1) 0x48f428 stg_enter_info (rts/HeapStackCheck.cmm:166.1) 0x45fd18 integerzmgmp_GHCziIntegerziType_minusInteger_info (/home/omer/haskell/test) (GHC version 8.4.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./test +RTS -DS }}} Not tested with HEAD. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 04:33:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 04:33:46 -0000 Subject: [GHC] #15241: T2783 fails a sanity test In-Reply-To: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> References: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> Message-ID: <058.5ce2be326616fe9e75773d0afdcb3d5c@haskell.org> #15241: T2783 fails a sanity test -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.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 osa1: Old description: > {{{ > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 8.4.2 > > $ ghc test.hs -fforce-recomp -debug -rtsopts > [1 of 1] Compiling Main ( test.hs, test.o ) > Linking test ... > > $ ./test +RTS -DS > test: internal error: ASSERTION FAILED: file rts/ThreadPaused.c, line 314 > > Stack trace: > test: Failed to get stack frames of current process: no matching address > range: Success > 0x4a3fbd set_initial_registers (rts/Libdw.c:288.0) > 0x7f9d70fd7a18 dwfl_thread_getframes (/usr/lib/x86_64 > -linux-gnu/libdw-0.170.so) > 0x7f9d70fd7efc dwfl_getthread_frames (/usr/lib/x86_64 > -linux-gnu/libdw-0.170.so) > 0x4a3eb6 libdwGetBacktrace (rts/Libdw.c:257.0) > 0x474de3 rtsFatalInternalErrorFn > (rts/RtsMessages.c:171.0) > 0x474ad0 barf (rts/RtsMessages.c:48.0) > 0x474b02 errorBelch (rts/RtsMessages.c:67.0) > 0x479273 threadPaused (rts/ThreadPaused.c:318.0) > 0x48ccdb stg_returnToSched > (rts/StgStartup.cmm:117.1) > 0x48f428 stg_enter_info > (rts/HeapStackCheck.cmm:166.1) > 0x45fd18 > integerzmgmp_GHCziIntegerziType_minusInteger_info > (/home/omer/haskell/test) > > (GHC version 8.4.2 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > zsh: abort (core dumped) ./test +RTS -DS > }}} > > Not tested with HEAD. New description: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.2 $ cat test.hs main = print $ do x <- [ 0 .. 5 ] let { y = 5 - y } return y $ ghc test.hs -fforce-recomp -debug -rtsopts [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... $ ./test +RTS -DS test: internal error: ASSERTION FAILED: file rts/ThreadPaused.c, line 314 Stack trace: test: Failed to get stack frames of current process: no matching address range: Success 0x4a3fbd set_initial_registers (rts/Libdw.c:288.0) 0x7f9d70fd7a18 dwfl_thread_getframes (/usr/lib/x86_64 -linux-gnu/libdw-0.170.so) 0x7f9d70fd7efc dwfl_getthread_frames (/usr/lib/x86_64 -linux-gnu/libdw-0.170.so) 0x4a3eb6 libdwGetBacktrace (rts/Libdw.c:257.0) 0x474de3 rtsFatalInternalErrorFn (rts/RtsMessages.c:171.0) 0x474ad0 barf (rts/RtsMessages.c:48.0) 0x474b02 errorBelch (rts/RtsMessages.c:67.0) 0x479273 threadPaused (rts/ThreadPaused.c:318.0) 0x48ccdb stg_returnToSched (rts/StgStartup.cmm:117.1) 0x48f428 stg_enter_info (rts/HeapStackCheck.cmm:166.1) 0x45fd18 integerzmgmp_GHCziIntegerziType_minusInteger_info (/home/omer/haskell/test) (GHC version 8.4.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./test +RTS -DS }}} `test.hs` above is the test `testsuite/tests/rts/T2783.hs`. Not tested with HEAD. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 05:06:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 05:06:10 -0000 Subject: [GHC] #15241: T2783 fails a sanity test In-Reply-To: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> References: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> Message-ID: <058.bb0ffd5938396170f36df3541e99edb5@haskell.org> #15241: T2783 fails a sanity test -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.5 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 osa1): * version: 8.4.3 => 8.5 Old description: > {{{ > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 8.4.2 > > $ cat test.hs > main = print $ do > x <- [ 0 .. 5 ] > let { y = 5 - y } > return y > > $ ghc test.hs -fforce-recomp -debug -rtsopts > [1 of 1] Compiling Main ( test.hs, test.o ) > Linking test ... > > $ ./test +RTS -DS > test: internal error: ASSERTION FAILED: file rts/ThreadPaused.c, line 314 > > Stack trace: > test: Failed to get stack frames of current process: no matching address > range: Success > 0x4a3fbd set_initial_registers (rts/Libdw.c:288.0) > 0x7f9d70fd7a18 dwfl_thread_getframes (/usr/lib/x86_64 > -linux-gnu/libdw-0.170.so) > 0x7f9d70fd7efc dwfl_getthread_frames (/usr/lib/x86_64 > -linux-gnu/libdw-0.170.so) > 0x4a3eb6 libdwGetBacktrace (rts/Libdw.c:257.0) > 0x474de3 rtsFatalInternalErrorFn > (rts/RtsMessages.c:171.0) > 0x474ad0 barf (rts/RtsMessages.c:48.0) > 0x474b02 errorBelch (rts/RtsMessages.c:67.0) > 0x479273 threadPaused (rts/ThreadPaused.c:318.0) > 0x48ccdb stg_returnToSched > (rts/StgStartup.cmm:117.1) > 0x48f428 stg_enter_info > (rts/HeapStackCheck.cmm:166.1) > 0x45fd18 > integerzmgmp_GHCziIntegerziType_minusInteger_info > (/home/omer/haskell/test) > > (GHC version 8.4.2 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > zsh: abort (core dumped) ./test +RTS -DS > }}} > > `test.hs` above is the test `testsuite/tests/rts/T2783.hs`. > > Not tested with HEAD. New description: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.2 $ cat test.hs main = print $ do x <- [ 0 .. 5 ] let { y = 5 - y } return y $ ghc test.hs -fforce-recomp -debug -rtsopts [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... $ ./test +RTS -DS test: internal error: ASSERTION FAILED: file rts/ThreadPaused.c, line 314 Stack trace: test: Failed to get stack frames of current process: no matching address range: Success 0x4a3fbd set_initial_registers (rts/Libdw.c:288.0) 0x7f9d70fd7a18 dwfl_thread_getframes (/usr/lib/x86_64 -linux-gnu/libdw-0.170.so) 0x7f9d70fd7efc dwfl_getthread_frames (/usr/lib/x86_64 -linux-gnu/libdw-0.170.so) 0x4a3eb6 libdwGetBacktrace (rts/Libdw.c:257.0) 0x474de3 rtsFatalInternalErrorFn (rts/RtsMessages.c:171.0) 0x474ad0 barf (rts/RtsMessages.c:48.0) 0x474b02 errorBelch (rts/RtsMessages.c:67.0) 0x479273 threadPaused (rts/ThreadPaused.c:318.0) 0x48ccdb stg_returnToSched (rts/StgStartup.cmm:117.1) 0x48f428 stg_enter_info (rts/HeapStackCheck.cmm:166.1) 0x45fd18 integerzmgmp_GHCziIntegerziType_minusInteger_info (/home/omer/haskell/test) (GHC version 8.4.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./test +RTS -DS }}} `test.hs` above is the test `testsuite/tests/rts/T2783.hs`. Tested with HEAD and 8.4.2. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 08:01:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 08:01:49 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF In-Reply-To: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> References: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> Message-ID: <060.430d691f00d2d84ccf93a09d3c41afd7@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): Phab:D4796 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Good point. A cast would complicate. I suppose that in {{{ case seq# x s |> g of (# s', x' #) -> ... }}} we'd have to have {{{ g :: (# State# t1, t2 #) ~ (# s1, s2 #) }}} where `x :: t2` and `x' :: s2`. So you'd want to transform to {{{ case seq# x s |> g of (# s', x' #) -> let x = x' |> sym (Nth 2 g) }}} because `Nth 2 g :: t2 ~ s2`. (I might not have this exactly right.) This all seems a bit ad-hoc for `seq#` but I don't really see an alternative, sadly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 10:08:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 10:08:28 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.0be822589769bef151f01f4d1c5e8632@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.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 oerjan): * cc: oerjan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 10:37:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 10:37:14 -0000 Subject: [GHC] #15242: Typechecker sometimes doesn't preserve HsPar in original source. Message-ID: <045.8e7aac9da580012b12f85623927a4ba7@haskell.org> #15242: Typechecker sometimes doesn't preserve HsPar in original source. -------------------------------------+------------------------------------- Reporter: wz1000 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The typechecker doesn't preserve parenthesis that occur at the head of applications. This results in some weird SrcSpans in the TypecheckedSource For example, given code {{{#!hs foo a b c = (bar a) b c }}} The typechecker will emit an HsApp with head spanning over `bar a) b` and tail spanning over `c`. Notice that the opening parenthesis is not included. On the other hand, the renamer will generate the expected SrcSpans that always include both parenthesis, or neither. This becomes an issue when you want to associate RenamedSource with its corresponding TypecheckedSource, as the SrcSpans no longer match and overlap partially. This occurs due to this line in TcExpr.hs {{{#!hs tcApp m_herald (L _ (HsPar _ fun)) args res_ty = tcApp m_herald fun args res_ty }}} I have a work in progress fix here: https://github.com/wz1000/ghc/commit/3b6db5a35dc8677a7187e349a85ffd51f452452a -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 11:05:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 11:05:39 -0000 Subject: [GHC] #14487: Can't Hide Field When DuplicateRecordFields Is Enabled In-Reply-To: <052.55fcb5f24afe31abafd77e2adcf88ad5@haskell.org> References: <052.55fcb5f24afe31abafd77e2adcf88ad5@haskell.org> Message-ID: <067.5a59b91817e64517f126d2a5afc53c7e@haskell.org> #14487: Can't Hide Field When DuplicateRecordFields Is Enabled -------------------------------------+------------------------------------- Reporter: iansullivan88 | Owner: (none) Type: bug | Status: patch Priority: lowest | Milestone: 8.6.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | DuplicateRecordFields ORF Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T14487 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4805 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * testcase: => rename/should_compile/T14487 * status: new => patch * differential: => Phab:D4805 * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 11:06:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 11:06:54 -0000 Subject: [GHC] #13438: ghci :browse does not work with DuplicateRecordFields In-Reply-To: <042.11a55998df45140f6a656eacb5763ba3@haskell.org> References: <042.11a55998df45140f6a656eacb5763ba3@haskell.org> Message-ID: <057.b093503f2a782f48ee9e7722377e1e50@haskell.org> #13438: ghci :browse does not work with DuplicateRecordFields -------------------------------------+------------------------------------- Reporter: rik | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: | duplicaterecordfields ghci orf Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): I've taken an initial look at this. FWIW it seems I need `:browse!` to observe the difference. The problem is that `browseModule` uses `modInfoExports` or `modInfoTopLevelScope`, both of which omit record fields defined with `DuplicateRecordFields`. To change this `browseModule` needs to be modified to work with a mixture of `Name`s and `FieldLabel`s, which is a bit of pain. I'm thinking about how to redesign things to make this easier... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 13:52:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 13:52:52 -0000 Subject: [GHC] #15218: HEAD doesn't build without sphinx-build In-Reply-To: <042.48e52db875cf86898104c8cf24945fa7@haskell.org> References: <042.48e52db875cf86898104c8cf24945fa7@haskell.org> Message-ID: <057.a37a6f8e532d00e6a9802b9b7ea15bbf@haskell.org> #15218: HEAD doesn't build without sphinx-build -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: Build System | Version: 8.4.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by bgamari): Is it possible that you pulled without running `git submodule update`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 14:57:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 14:57:47 -0000 Subject: [GHC] #15243: -ddump-splices shenanigans: promoted tycons aren't ticked Message-ID: <050.2f5ba7e519bdc8794c9c5f84999a9562@haskell.org> #15243: -ddump-splices shenanigans: promoted tycons aren't ticked -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Consider the following program with a type family that contains four different promoted (i.e., ticked) type constructors: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where data Unit = Unit $([d| type family F (a :: k) :: k where F 'Unit = 'Unit F '(,) = '(,) F '[] = '[] F '(:) = '(:) |]) }}} {{{ $ /opt/ghc/8.4.3/bin/ghci Bug3.hs GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug3.hs, interpreted ) Bug3.hs:(10,3)-(15,6): Splicing declarations [d| type family F_a1xJ (a_a1xL :: k_a1xK) :: k_a1xK where F_a1xJ 'Unit = 'Unit F_a1xJ '(,) = '(,) F_a1xJ '[] = '[] F_a1xJ '(:) = '(:) |] ======> type family F_a49g (a_a49i :: k_a49h) :: k_a49h where F_a49g Unit = Unit F_a49g GHC.Tuple.(,) = GHC.Tuple.(,) F_a49g '[] = '[] F_a49g (GHC.Types.:) = (GHC.Types.:) Ok, one module loaded. }}} The `-ddump-splices` output is quite strange: `'[]` is ticked, but the other three are not! This seems off. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 15:25:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 15:25:25 -0000 Subject: [GHC] #15243: -ddump-splices shenanigans: promoted tycons aren't ticked In-Reply-To: <050.2f5ba7e519bdc8794c9c5f84999a9562@haskell.org> References: <050.2f5ba7e519bdc8794c9c5f84999a9562@haskell.org> Message-ID: <065.7a2d2ae8dda42a2ab00fee72280cc44a@haskell.org> #15243: -ddump-splices shenanigans: promoted tycons aren't ticked -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4809 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4809 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 16:00:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 16:00:57 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF In-Reply-To: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> References: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> Message-ID: <060.682ee63221be955cdd5e2af32aae392a@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): Phab:D4796 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): The key `OccAnal` functions involved seem to be `mkAltEnv` (not sure what this does, but it seems to look for `Var`s when I want to look also for applications of `seq#`) and `wrapAltRHS` (which seems to actually install the `Let` when appropriate), but I don't see how it all fits together. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 17:14:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 17:14:15 -0000 Subject: [GHC] #15134: enumFrom... aren't really documented. In-Reply-To: <045.101e34e5570fe8f6e2839dfe4e91d13c@haskell.org> References: <045.101e34e5570fe8f6e2839dfe4e91d13c@haskell.org> Message-ID: <060.dd9f5cf52c3d26b41a9723410b3ed50f@haskell.org> #15134: enumFrom... aren't really documented. -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Azel Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4737 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Azel): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 17:15:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 17:15:41 -0000 Subject: [GHC] #15221: failure to build pandoc on Debian armhf In-Reply-To: <044.c95e2449a6d05724dcf3491a30d3f9d3@haskell.org> References: <044.c95e2449a6d05724dcf3491a30d3f9d3@haskell.org> Message-ID: <059.3e1c914d05af6a7f429342be05cc4d7c@haskell.org> #15221: failure to build pandoc on Debian armhf ---------------------------------+------------------------------ Reporter: clint | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: 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): Hmm, this really only happens on ARM? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 17:48:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 17:48:47 -0000 Subject: [GHC] #15244: Ambiguity checks in QuantifiedConstraints Message-ID: <055.959d04c99ecee584bd91e5ef9b6544de@haskell.org> #15244: Ambiguity checks in QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: | Owner: (none) bitwiseshiftleft | Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Great work on QuantifiedConstraints! I'm giving it a whirl. With GHCI 8.5.20180605, I see somewhat annoying behavior around multiple instances. When two copies of the same (or equivalent) quantified constraint are in scope, they produce an error. I think this is about some kind of ambiguity check. {{{ {-# LANGUAGE QuantifiedConstraints, TypeFamilies #-} class (forall t . Eq (c t)) => Blah c -- Unquantified works foo :: (Eq (a t), Eq (b t), a ~ b) => a t -> b t -> Bool foo a b = a == b -- Works -- Two quantified instances fail with double ambiguity check errors bar :: (forall t . Eq (a t), forall t . Eq (b t), a ~ b) => a t -> b t -> Bool bar a b = a == b -- Minimal.hs:11:8: error: -- • Could not deduce (Eq (b t1)) -- from the context: (forall t1. Eq (a t1), forall t1. Eq (b t1), -- a ~ b) -- bound by the type signature for: -- bar :: forall (a :: * -> *) (b :: * -> *) t. -- (forall t1. Eq (a t1), forall t1. Eq (b t1), a ~ b) => -- a t -> b t -> Bool -- at Minimal.hs:11:8-78 -- • In the ambiguity check for ‘bar’ -- To defer the ambiguity check to use sites, enable AllowAmbiguousTypes -- In the type signature: -- bar :: (forall t. Eq (a t), forall t. Eq (b t), a ~ b) => -- a t -> b t -> Bool -- | -- 11 | bar :: (forall t . Eq (a t), forall t . Eq (b t), a ~ b) => a t -> b t -> Bool -- | -- [And then another copy of the same error] -- Two copies from superclass instances fail baz :: (Blah a, Blah b, a ~ b) => a t -> b t -> Bool baz a b = a == b -- Minimal.hs:34:11: error: -- • Could not deduce (Eq (b t)) arising from a use of ‘==’ -- from the context: (Blah a, Blah b, a ~ b) -- bound by the type signature for: -- baz :: forall (a :: * -> *) (b :: * -> *) t. -- (Blah a, Blah b, a ~ b) => -- a t -> b t -> Bool -- at Minimal.hs:33:1-52 -- • In the expression: a == b -- In an equation for ‘baz’: baz a b = a == b -- | -- 34 | baz a b = a == b -- | -- Two copies from superclass from same declaration also fail mugga :: (Blah a, Blah a) => a t -> a t -> Bool mugga a b = a == b -- • Could not deduce (Eq (a t)) arising from a use of ‘==’ -- from the context: (Blah a, Blah a) -- bound by the type signature for: -- mugga :: forall (a :: * -> *) t. -- (Blah a, Blah a) => -- a t -> a t -> Bool -- at Minimal.hs:50:1-47 -- • In the expression: a == b -- In an equation for ‘mugga’: mugga a b = a == b -- | -- 51 | mugga a b = a == b -- | -- One copy works quux :: (Blah a, a ~ b) => a t -> b t -> Bool quux a b = a == b -- Works }}} My program is similar to {{{Baz}}}. The constraints {{{Blah a}}} and {{{Blah b}}} are in scope from a pattern match, and I want to compare values of types {{{a t}}} and {{{b t}}} if they're the same type. So I get {{{a ~ b}}} from Typeable and try to compare them, but this doesn't work. I worked around the issue by writing a helper that only takes {{{(Blah a, Typeable a, Typeable b)}}}, so only one instance is in scope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 17:49:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 17:49:29 -0000 Subject: [GHC] #15244: Ambiguity checks in QuantifiedConstraints In-Reply-To: <055.959d04c99ecee584bd91e5ef9b6544de@haskell.org> References: <055.959d04c99ecee584bd91e5ef9b6544de@haskell.org> Message-ID: <070.846431579be4e8aa7351c5ef233fcfd4@haskell.org> #15244: Ambiguity checks in QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: bitwiseshiftleft | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints 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 bitwiseshiftleft): * version: 8.4.3 => 8.5 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 18:06:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 18:06:10 -0000 Subject: [GHC] #14381: Consider making ghc-pkg fill in abi-depends based on depends In-Reply-To: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> References: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> Message-ID: <060.795e217229930fc537c2d95d8e70ea75@haskell.org> #14381: Consider making ghc-pkg fill in abi-depends based on depends -------------------------------------+------------------------------------- Reporter: ezyang | Owner: tdammers Type: bug | Status: closed Priority: highest | Milestone: 8.4.4 Component: ghc-pkg | Version: 8.2.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:D4159 Wiki Page: | Phab:D4729 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.4.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 18:07:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 18:07:25 -0000 Subject: [GHC] #15212: powerpc64le-unknown-linux is missing from llvm-targets In-Reply-To: <045.5d6d39c8631e163a5e27c5b5cbbf3073@haskell.org> References: <045.5d6d39c8631e163a5e27c5b5cbbf3073@haskell.org> Message-ID: <060.2893d894984c74d651de86cb911629ec@haskell.org> #15212: powerpc64le-unknown-linux is missing from llvm-targets ---------------------------------+---------------------------------- Reporter: admock | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4765 Wiki Page: | ---------------------------------+---------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 18:20:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 18:20:38 -0000 Subject: [GHC] #13573: Add Foldable1 to base In-Reply-To: <051.5343934480dda921b1b6981f18b39763@haskell.org> References: <051.5343934480dda921b1b6981f18b39763@haskell.org> Message-ID: <066.c3994d4459f82043347662b943a15eb5@haskell.org> #13573: Add Foldable1 to base -------------------------------------+------------------------------------- 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: #10365 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chessai): I've committed a differential for this to https://phabricator.haskell.org/D4812 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 18:41:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 18:41:25 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails In-Reply-To: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> References: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> Message-ID: <065.1ba0671234520a5f83e363c72fa161ad@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, CUSKs 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): This goes back to the kind inference debate we had when working on #14066. The debate is memorialized [https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference here], toward the top. Suppose we have {{{#!hs data Proxy (k :: Type) (a :: k) = Proxy -- NB: CUSK }}} Do we accept {{{#!hs type ProxySym k a = Proxy k a data ProxyData k a = MkProxyData (Proxy k a) }}} Related are your thoughts on #14847 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 18:45:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 18:45:41 -0000 Subject: [GHC] #13573: Add Foldable1 to base In-Reply-To: <051.5343934480dda921b1b6981f18b39763@haskell.org> References: <051.5343934480dda921b1b6981f18b39763@haskell.org> Message-ID: <066.3e0dbf3b2f561eb28931be038ba43880@haskell.org> #13573: Add Foldable1 to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.8.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: #10365 | Differential Rev(s): Phab:D4812 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4812 * milestone: => 8.8.1 Comment: Thanks chessai! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 19:24:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 19:24:02 -0000 Subject: [GHC] #15245: Data family promotion is possible Message-ID: <048.2bfd93318ecc0fe9c70183281e7bf50f@haskell.org> #15245: Data family promotion is possible -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 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: -------------------------------------+------------------------------------- The User's Guide states that data families cannot be promoted, even with `-XTypeInType`: > We promote data types and newtypes; type synonyms and type/data families are not promoted. > > The flag TypeInType (which implies DataKinds) relaxes some of these restrictions, allowing: > > Promotion of type synonyms and type families, but not data families. GHC’s type theory just isn’t up to the task of promoting data families, which requires full dependent types. And yet the following code typechecks and runs: {{{#!hs {-# LANGUAGE TypeFamilies, TypeInType, TypeApplications #-} import Type.Reflection data family K data instance K = MkK main = print (typeRep @'MkK) }}} Is this a GHC bug or a documentation bug? I asked in IRC but I'm still confused: {{{ The user guide states that data families aren't promoted even when -XTypeInType is enabled. Where's the logic that ensures this? I checked with `data family K; data instance K = MkK` and I can use `'MkK` with no errors/warnings. https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#overview "Promotion of type synonyms and type families, but not data families. GHC’s type theory just isn’t up to the task of promoting data families, which requires full dependent types." Is this info outdated? int-index: Is this in GHCi? It certainly fails in GHC But I think I understand why the former works RyanGlScott, yes, I'm checking this in GHCi int-index: So here's my understanding of how this works GHC kind-checks top-level declarations using a rather primitive SCC analysis In particular, it's primitive in the sense that data family instances give it a lot of trouble If you tried taking your code and putting it into a standalone .hs file and compiling that, then it would definitely complain about a promoted use of MkT As luck would have it, though, you were trying things out in GHCi Which essentially checks each line of input as its own strongly connected group of declarations So you can define MkT on one line and promote it in subsequent lines, since they're separate in the sense *that sense this sounds related to Trac #12088, and then I could work around it in GHC by using `$(return [])`, so data families are actually promoted anyway and this has nothing to do with GHC needing more powerful type theory Well, it does need more powerful type theory in the sense that that's a prerequisite for making the SCC analysis for kind-checking sophisticated enough to handle this But yes, it's quite simple to work around by using Template Haskell to explicitly split up groups. https://gist.github.com/int- index/c6cc1e20c4b9b5c99af40ee4e23ecb61 this works and no template haskell involved The reason I'm asking is that I'm touching this part of the User's Guide and I don't know what to write there. Huh, now that's interesting RyanGlScott, the only check I could find that controls what's promoted and what's not is 'isLegacyPromotableDataCon' - and enabling -XTypeInType disables this check. int-index: Right, that's baffling me Since that's supposed to be checked every time you promote a data constructor (I think) int-index: File a bug about that, I suppose Richard (who's sitting next to me right now) seems to think that that shouldn't be possible RyanGlScott, the thing is, I happily removed this check completely in D4748. Does this mean I have to restore a weaker version of it that only checks for data families? Why? Is it bad that -XDataKinds promotes data family constructors? Looks like I can just remove the "restrictions" part of the user guide and be done with it int-index: In theory, that shouldn't be possible OK, then what the check should be? No data families, any other restrictions? I might qualify that with "no data family instances defined in the same module" (Or to be precise, in the same SCC, but that's probably too technical for the users' guide) Well, this sounds hard to check. I was thinking along the lines of keeping the 'not (isFamInstTyCon (dataConTyCon dc))' part of the check... Oh, I thought you were only changing the users' guide :) Well, at this point I'm confused if I should change only the user guide or the check as well. If data families shouldn't be promoted ever, then I'll change GHC. If the limitation is about the current SCC group, I can just mention Trac #12088 as a known infelicity in the User's Guide }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 19:25:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 19:25:36 -0000 Subject: [GHC] #15218: HEAD doesn't build without sphinx-build In-Reply-To: <042.48e52db875cf86898104c8cf24945fa7@haskell.org> References: <042.48e52db875cf86898104c8cf24945fa7@haskell.org> Message-ID: <057.6ee950564439190ec1ae32627a6d48ab@haskell.org> #15218: HEAD doesn't build without sphinx-build -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: Build System | Version: 8.4.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by jrp): Thanks. Yes. That was it. I don't think that that was mentioned in the build instructions. Now I just get: {{{ Unexpected failures: /tmp/ghctest-0sj8fd43/test spaces/./dependent/should_compile/dynamic- paper.run dynamic-paper [stderr mismatch] (normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 20:40:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 20:40:27 -0000 Subject: [GHC] #15246: -fghci-leak-cheak causes many testsuite failures with the quick build flavour Message-ID: <050.c93ffe426b77b4e3ab4a606d2f8a144f@haskell.org> #15246: -fghci-leak-cheak causes many testsuite failures with the quick build flavour -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 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 [https://mail.haskell.org/pipermail/ghc-devs/2018-May/015812.html originally reported] on the ghc-devs mailing list, the `-fghci-leak-check` flag is causing several tests to fail when GHC is built with the quick build flavour. On my machine, here are all the tests that fail: {{{ Unexpected failures: ghci/prog001/prog001.run prog001 [bad stdout] (ghci) ghci/prog002/prog002.run prog002 [bad stdout] (ghci) ghci/prog003/prog003.run prog003 [bad stdout] (ghci) ghci/prog010/ghci.prog010.run ghci.prog010 [bad stdout] (ghci) ghci/prog013/prog013.run prog013 [bad stdout] (ghci) ghci/prog012/prog012.run prog012 [bad stdout] (ghci) ghci/prog009/ghci.prog009.run ghci.prog009 [bad stdout] (ghci) ghci/scripts/ghci025.run ghci025 [bad stdout] (ghci) ghci/scripts/ghci038.run ghci038 [bad stdout] (ghci) ghci/scripts/ghci057.run ghci057 [bad stdout] (ghci) ghci/scripts/T2182ghci.run T2182ghci [bad stdout] (ghci) ghci/scripts/ghci058.run ghci058 [bad stdout] (ghci) ghci/scripts/T6106.run T6106 [bad stdout] (ghci) ghci/scripts/T8353.run T8353 [bad stdout] (ghci) ghci/scripts/T9293.run T9293 [bad stdout] (ghci) ghci/scripts/T10989.run T10989 [bad stdout] (ghci) ghci/should_run/T13825-ghci.run T13825-ghci [bad stdout] (ghci) ghci.debugger/scripts/print007.run print007 [bad stdout] (ghci) ghci.debugger/scripts/break009.run break009 [bad stdout] (ghci) ghci.debugger/scripts/break008.run break008 [bad stdout] (ghci) ghci.debugger/scripts/break026.run break026 [bad stdout] (ghci) perf/space_leaks/T4029.run T4029 [bad stdout] (ghci) }}} [https://gist.githubusercontent.com/RyanGlScott/f920737287049b82947e1c47cdbc2b94/raw/4fe68d47cc78675424e09cf451be556c6f430d08/gistfile1.txt Here] is the full test output. Generally, the test output discrepancies are all of the form of extra lines of: {{{ +-fghci-leak-check: HomeModInfo for D is still alive! +-fghci-leak-check: ModIface is still alive! +-fghci-leak-check: ModDetails is still alive! +-fghci-leak-check: Linkable is still alive! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 21:07:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 21:07:24 -0000 Subject: [GHC] #15221: failure to build pandoc on Debian armhf In-Reply-To: <044.c95e2449a6d05724dcf3491a30d3f9d3@haskell.org> References: <044.c95e2449a6d05724dcf3491a30d3f9d3@haskell.org> Message-ID: <059.a1b5f4bc11c5c84436b87ae0836691bd@haskell.org> #15221: failure to build pandoc on Debian armhf ---------------------------------+------------------------------ Reporter: clint | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Comment (by clint): This only happens on armhf, not armel or arm64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 22:00:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 22:00:17 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF In-Reply-To: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> References: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> Message-ID: <060.3d1ab9f6bcfa32ffc9091ac8b90ad230@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): Phab:D4796 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): If you want to pursue, this I can advise. Whether it's worth the trouble I'm less sure. Do you have an example where it's causing trouble? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 22:14:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 22:14:32 -0000 Subject: [GHC] #15229: Run typeCheckResultAction and renamedResultAction in TcM rather than Hsc In-Reply-To: <049.f951fbb4e9a6863ea169dbe4282670d0@haskell.org> References: <049.f951fbb4e9a6863ea169dbe4282670d0@haskell.org> Message-ID: <064.16218915d32ac6b8faacb4d2576a6082@haskell.org> #15229: Run typeCheckResultAction and renamedResultAction in TcM rather than Hsc -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4792 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: It has been done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 22:25:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 22:25:31 -0000 Subject: [GHC] #15244: Ambiguity checks in QuantifiedConstraints In-Reply-To: <055.959d04c99ecee584bd91e5ef9b6544de@haskell.org> References: <055.959d04c99ecee584bd91e5ef9b6544de@haskell.org> Message-ID: <070.108eb6e4ce0fd199a22386fcd6b3eac4@haskell.org> #15244: Ambiguity checks in QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: bitwiseshiftleft | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints 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): {{{ bar :: (forall t . Eq (a t), forall t . Eq (b t), a ~ b) => a t -> b t -> Bool }}} You'd never write this, correct? Because if `a~b` then the two quantified constraints are identical. But your point is that in {{{ class (forall t . Eq (c t)) => Blah c baz :: (Blah a, Blah b, a ~ b) => a t -> b t -> Bool }}} you can't avoid having two identical superclass constraints. In general if we have two quantified constraints {{{ forall a. Q1 => t a forall a. Q2 => t a }}} and we have to solve `t Int`, say, GHC doesn't know which to pick. (Solving Q1 might be easier than Q2; we don't know.) So it picks neither. And that is what is happening here. But in this case the quantified constraints are ''identical''; but GHC doesn't currently spot that. It would not be hard to combine identical quantified constraints, which would solve this problem. Is this an application that matters to you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 7 22:37:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Jun 2018 22:37:46 -0000 Subject: [GHC] #15244: Ambiguity checks in QuantifiedConstraints In-Reply-To: <055.959d04c99ecee584bd91e5ef9b6544de@haskell.org> References: <055.959d04c99ecee584bd91e5ef9b6544de@haskell.org> Message-ID: <070.5bef1a3fdcf8e88e9ec18faa855d9847@haskell.org> #15244: Ambiguity checks in QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: bitwiseshiftleft | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints 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 bitwiseshiftleft): Thanks for the quick response Simon. Right, {{{bar}}} is only to help track down the cause. It's the Blah case that's more likely, in particular when the Blah instance comes into scope from a pattern match. Something like (and I didn't test this example): {{{ data GenericBlah t where GB :: (Typeable a, Blah a) => a t -> GenericBlah t instance Eq (GenericBlah t) where (GB (a::ca t)) == (GB (b::cb t)) = case eqT @ca @cb of Nothing -> False Just Refl -> a==b }}} The constraint inside the {{{Eq}}} instance is equivalent to {{{baz}}}. I'm exploring QuantifiedConstraints, and might eventually use them at my job. However, QuantifiedConstraints would only be used in a few places. This pattern would be used rare and the bug isn't difficult to work around, so it's not urgent. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 00:07:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 00:07:04 -0000 Subject: [GHC] #14343: bad pretty-printing of types with promoted data types In-Reply-To: <048.9dafa4d8103f25346932aca07d111b88@haskell.org> References: <048.9dafa4d8103f25346932aca07d111b88@haskell.org> Message-ID: <063.ee507b3528f3883fdd7d11b114e013bc@haskell.org> #14343: bad pretty-printing of types with promoted data types -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: andreash Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.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:D4746 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"767536ccf95d8352d146b6544857b28d9c42937e/ghc" 767536c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="767536ccf95d8352d146b6544857b28d9c42937e" Fix unparseable pretty-printing of promoted data cons Previously we would print code which would not round-trip: ``` > :set -XDataKinds > :set -XPolyKinds > data Proxy k = Proxy > _ :: Proxy '[ 'True ] error: Found hole: _ :: Proxy '['True] > _ :: Proxy '['True] error: Invalid type signature: _ :: ... Should be of form :: ``` Test Plan: Validate with T14343 Reviewers: RyanGlScott, goldfire, bgamari, tdammers Reviewed By: RyanGlScott, bgamari Subscribers: tdammers, rwbarton, thomie, carter GHC Trac Issues: #14343 Differential Revision: https://phabricator.haskell.org/D4746 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 00:07:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 00:07:21 -0000 Subject: [GHC] #15188: Catch cases where both branches of an if jump to the same block. In-Reply-To: <047.a29b3685be75fc9bbb2d148660ee8c8a@haskell.org> References: <047.a29b3685be75fc9bbb2d148660ee8c8a@haskell.org> Message-ID: <062.6fec950c07ba4bd3001e7eafcb938841@haskell.org> #15188: Catch cases where both branches of an if jump to the same block. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (CodeGen) | Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4740 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"efea32cf2c41d35f2ba5a79bf70cc7768b7b0fd5/ghc" efea32cf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="efea32cf2c41d35f2ba5a79bf70cc7768b7b0fd5" Check if both branches of an Cmm if have the same target. This for some reason or the other and makes it into the final binary. I've added the check to ContFlowOpt as that seems like a logical place for this. In a regular nofib run there were 30 occurences of this pattern. Test Plan: ci Reviewers: bgamari, simonmar, dfeuer, jrtc27, tdammers Reviewed By: bgamari, simonmar Subscribers: tdammers, dfeuer, rwbarton, thomie, carter GHC Trac Issues: #15188 Differential Revision: https://phabricator.haskell.org/D4740 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 00:07:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 00:07:53 -0000 Subject: [GHC] #15232: TypeError is reported as "redundant constraint" starting with GHC 8.2 In-Reply-To: <046.58a062782fd94acef2d8a01d6d6ea4fb@haskell.org> References: <046.58a062782fd94acef2d8a01d6d6ea4fb@haskell.org> Message-ID: <061.ae76be2299ce0026449ac6e4ade464f8@haskell.org> #15232: TypeError is reported as "redundant constraint" starting with GHC 8.2 -------------------------------------+------------------------------------- Reporter: fsoikin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | CustomTypeErrors 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 Ben Gamari ): In [changeset:"5026840fddc86c3bc10693eed676fbf6a74f4227/ghc" 5026840f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5026840fddc86c3bc10693eed676fbf6a74f4227" testsuite: Add test for #15232 Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15232 Differential Revision: https://phabricator.haskell.org/D4807 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 00:08:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 00:08:09 -0000 Subject: [GHC] #15243: -ddump-splices shenanigans: promoted tycons aren't ticked In-Reply-To: <050.2f5ba7e519bdc8794c9c5f84999a9562@haskell.org> References: <050.2f5ba7e519bdc8794c9c5f84999a9562@haskell.org> Message-ID: <065.340e4be3367eafc2ca40177058b55344@haskell.org> #15243: -ddump-splices shenanigans: promoted tycons aren't ticked -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4809 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"569c16a76ead8f9012fafe7a7e97c72fabe0bb94/ghc" 569c16a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="569c16a76ead8f9012fafe7a7e97c72fabe0bb94" Fix #15243 by fixing incorrect uses of NotPromoted In `Convert`, we were incorrectly using `NotPromoted` to denote type constructors that were actually intended to be promoted, resulting in poor `-ddump-splices` output (as seen in #15243). Easily fixed. Test Plan: make test TEST=T15243 Reviewers: bgamari, goldfire Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15243 Differential Revision: https://phabricator.haskell.org/D4809 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 00:08:24 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 00:08:24 -0000 Subject: [GHC] #15079: GHC HEAD regression: cannot instantiate higher-rank kind In-Reply-To: <050.d29ab0a2c8c230faa38439fac305fb8f@haskell.org> References: <050.d29ab0a2c8c230faa38439fac305fb8f@haskell.org> Message-ID: <065.793160b312781d7b7f5efdae7a439316@haskell.org> #15079: GHC HEAD regression: cannot instantiate higher-rank kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType 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:D4803 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"bc9a838a27f40a6008e127d9105981713abe774b/ghc" bc9a838/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bc9a838a27f40a6008e127d9105981713abe774b" Document #15079 in the users' guide Trac #15079 revealed an interesting limitation in the interaction between variable visibility and higher-rank kinds. We (Richard and I) came to the conclusion that this is an acceptable (albeit surprising) limitation, so this documents in the users' guide to hopefully eliminate some confusion for others in the future. Test Plan: Read it Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15079 Differential Revision: https://phabricator.haskell.org/D4803 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 00:08:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 00:08:39 -0000 Subject: [GHC] #15238: T13838 fails in ghci way In-Reply-To: <046.a757024938d0b3ba3bb6900057f32c31@haskell.org> References: <046.a757024938d0b3ba3bb6900057f32c31@haskell.org> Message-ID: <061.990423ad1764b0309a2adfbd418454e0@haskell.org> #15238: T13838 fails in ghci way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 Ben Gamari ): In [changeset:"04e29fc63e1f1d975c73449b27471cf59c9ffca2/ghc" 04e29fc6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="04e29fc63e1f1d975c73449b27471cf59c9ffca2" testsuite: Skip T13838 in ghci way Test Plan: `make slowtest TEST=T13838` Reviewers: alpmestan, dfeuer Reviewed By: dfeuer Subscribers: dfeuer, rwbarton, thomie, carter GHC Trac Issues: #15238 Differential Revision: https://phabricator.haskell.org/D4802 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 00:08:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 00:08:53 -0000 Subject: [GHC] #15209: ~# is always in scope with TypeOperators In-Reply-To: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> References: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> Message-ID: <060.87cbe1255f38118820190e6691f8778a@haskell.org> #15209: ~# is always in scope with TypeOperators -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4763, Wiki Page: | Phab:D4801 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5926b6ed0dcc86f8fd6038fdcc5e2ba2856f40ce/ghc" 5926b6ed/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5926b6ed0dcc86f8fd6038fdcc5e2ba2856f40ce" Don't expose (~#), (~R#), (~P#) from GHC.Prim Currently, the primitive `(~#)`, `(~R#)`, and `(~P#)` type constructors are wired in to be exported from `GHC.Prim`. This has some unfortunate consequences, however. It turns out that `(~#)` is actually a legal infix identifier, so users can make use of unboxed equalities in strange ways in user code (see #15209). The other two, `(~R#)` and `(~P#)`, can't be used in source code, but they can be observed with GHCi's `:browse` command, which is somewhat unnerving. The fix for both of these problems is simple: just don't wire them to be exported from `GHC.Prim`. Test Plan: make test TEST="T12023 T15209" Reviewers: bgamari, dfeuer Reviewed By: bgamari, dfeuer Subscribers: rwbarton, thomie, carter, dfeuer GHC Trac Issues: #12023, #15209 Differential Revision: https://phabricator.haskell.org/D4801 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 00:08:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 00:08:53 -0000 Subject: [GHC] #12023: Problems getting information and kind from GHC.Prim ~#, ~R#, ... In-Reply-To: <051.e18556256e79a3a1dab6064a1d75c6d2@haskell.org> References: <051.e18556256e79a3a1dab6064a1d75c6d2@haskell.org> Message-ID: <066.cdc27d3dbfb6e10e4db1f2318af60c46@haskell.org> #12023: Problems getting information and kind from GHC.Prim ~#, ~R#, ... -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | 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: #10059, #15209 | Differential Rev(s): Phab:D4801 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5926b6ed0dcc86f8fd6038fdcc5e2ba2856f40ce/ghc" 5926b6ed/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5926b6ed0dcc86f8fd6038fdcc5e2ba2856f40ce" Don't expose (~#), (~R#), (~P#) from GHC.Prim Currently, the primitive `(~#)`, `(~R#)`, and `(~P#)` type constructors are wired in to be exported from `GHC.Prim`. This has some unfortunate consequences, however. It turns out that `(~#)` is actually a legal infix identifier, so users can make use of unboxed equalities in strange ways in user code (see #15209). The other two, `(~R#)` and `(~P#)`, can't be used in source code, but they can be observed with GHCi's `:browse` command, which is somewhat unnerving. The fix for both of these problems is simple: just don't wire them to be exported from `GHC.Prim`. Test Plan: make test TEST="T12023 T15209" Reviewers: bgamari, dfeuer Reviewed By: bgamari, dfeuer Subscribers: rwbarton, thomie, carter, dfeuer GHC Trac Issues: #12023, #15209 Differential Revision: https://phabricator.haskell.org/D4801 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 00:09:08 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 00:09:08 -0000 Subject: [GHC] #15236: GHCi pretty-prints (->)'s fixity poorly In-Reply-To: <050.434b168bbf33573a386a6904db5f1ad2@haskell.org> References: <050.434b168bbf33573a386a6904db5f1ad2@haskell.org> Message-ID: <065.136f0f4a61ca3035f74ddbf518ff86e5@haskell.org> #15236: GHCi pretty-prints (->)'s fixity poorly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4799 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3397396a385ef9f493cf1e20894e88d21dfec48d/ghc" 3397396/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3397396a385ef9f493cf1e20894e88d21dfec48d" Fix #15236 by removing parentheses from funTyConName Currently, `funTyConName` is defined as: ```lang=haskell funTyConName = mkPrimTyConName (fsLit "(->)") funTyConKey funTyCon ``` What's strange about this definition is that there are extraneous parentheses around `->`, which is quite unlike every other infix `Name`. As a result, the `:info (->)` output is totally garbled (see Trac #15236). It's quite straightforward to fix that particular bug by removing the extraneous parentheses. However, it turns out that this makes some test output involving `Show` instances for `TypeRep` look less appealing, since `->` is no longer surrounded with parentheses when applied prefix. But neither were any /other/ infix type constructors! The right fix there was to change `showTypeable` to put parentheses around prefix applications of infix tycons. Test Plan: ./validate Reviewers: bgamari, hvr Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15236 Differential Revision: https://phabricator.haskell.org/D4799 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 00:09:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 00:09:52 -0000 Subject: [GHC] #15229: Run typeCheckResultAction and renamedResultAction in TcM rather than Hsc In-Reply-To: <049.f951fbb4e9a6863ea169dbe4282670d0@haskell.org> References: <049.f951fbb4e9a6863ea169dbe4282670d0@haskell.org> Message-ID: <064.bbbaaa597e4043a361731568abbd4fac@haskell.org> #15229: Run typeCheckResultAction and renamedResultAction in TcM rather than Hsc -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4792 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"dc8c03b2a5c70d3169e88d407f3ef28e0cb26af5/ghc" dc8c03b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dc8c03b2a5c70d3169e88d407f3ef28e0cb26af5" Run typeCheckResultAction and renamedResultAction in TcM rather than Hsc The primary motivation for this is that this allows users to access the warnings and error machinery present in TcM. However, it also allows users to use TcM actions which means they can typecheck GhcPs which could be significantly easier than constructing GhcTc. Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15229 Differential Revision: https://phabricator.haskell.org/D4792 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 00:12:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 00:12:14 -0000 Subject: [GHC] #15232: TypeError is reported as "redundant constraint" starting with GHC 8.2 In-Reply-To: <046.58a062782fd94acef2d8a01d6d6ea4fb@haskell.org> References: <046.58a062782fd94acef2d8a01d6d6ea4fb@haskell.org> Message-ID: <061.7452338ac8896e05c767f780aa1ba591@haskell.org> #15232: TypeError is reported as "redundant constraint" starting with GHC 8.2 -------------------------------------+------------------------------------- Reporter: fsoikin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | CustomTypeErrors 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 Ben Gamari ): In [changeset:"d66ca0111cefcda6620a4c82a932456b3e48874c/ghc" d66ca011/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d66ca0111cefcda6620a4c82a932456b3e48874c" typecheck: Don't warn about "redundant" TypeError constraints Summary: This fixes #15232, where we would warn about `TypeError` constraints being redundant. Test Plan: Validate Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15232 Differential Revision: https://phabricator.haskell.org/D4808 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 00:15:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 00:15:27 -0000 Subject: [GHC] #15232: TypeError is reported as "redundant constraint" starting with GHC 8.2 In-Reply-To: <046.58a062782fd94acef2d8a01d6d6ea4fb@haskell.org> References: <046.58a062782fd94acef2d8a01d6d6ea4fb@haskell.org> Message-ID: <061.2fd975cede038fb96e2f424777e245f4@haskell.org> #15232: TypeError is reported as "redundant constraint" starting with GHC 8.2 -------------------------------------+------------------------------------- Reporter: fsoikin | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: | CustomTypeErrors 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 bgamari): * status: new => closed * resolution: => fixed * milestone: 8.2.3 => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 00:16:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 00:16:28 -0000 Subject: [GHC] #15236: GHCi pretty-prints (->)'s fixity poorly In-Reply-To: <050.434b168bbf33573a386a6904db5f1ad2@haskell.org> References: <050.434b168bbf33573a386a6904db5f1ad2@haskell.org> Message-ID: <065.947d264c281c4dec213500dc8e19b612@haskell.org> #15236: GHCi pretty-prints (->)'s fixity poorly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4799 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 00:16:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 00:16:56 -0000 Subject: [GHC] #12023: Problems getting information and kind from GHC.Prim ~#, ~R#, ... In-Reply-To: <051.e18556256e79a3a1dab6064a1d75c6d2@haskell.org> References: <051.e18556256e79a3a1dab6064a1d75c6d2@haskell.org> Message-ID: <066.b4eb8f7ba4e0c2ad49132d8782807972@haskell.org> #12023: Problems getting information and kind from GHC.Prim ~#, ~R#, ... -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10059, #15209 | Differential Rev(s): Phab:D4801 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 00:17:18 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 00:17:18 -0000 Subject: [GHC] #15238: T13838 fails in ghci way In-Reply-To: <046.a757024938d0b3ba3bb6900057f32c31@haskell.org> References: <046.a757024938d0b3ba3bb6900057f32c31@haskell.org> Message-ID: <061.57d55dd0ea4f036a216b3f188502bad2@haskell.org> #15238: T13838 fails in ghci way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 00:17:37 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 00:17:37 -0000 Subject: [GHC] #15243: -ddump-splices shenanigans: promoted tycons aren't ticked In-Reply-To: <050.2f5ba7e519bdc8794c9c5f84999a9562@haskell.org> References: <050.2f5ba7e519bdc8794c9c5f84999a9562@haskell.org> Message-ID: <065.8d6f873fc58c9538f8726efff60f37fc@haskell.org> #15243: -ddump-splices shenanigans: promoted tycons aren't ticked -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4809 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 00:19:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 00:19:40 -0000 Subject: [GHC] #15188: Catch cases where both branches of an if jump to the same block. In-Reply-To: <047.a29b3685be75fc9bbb2d148660ee8c8a@haskell.org> References: <047.a29b3685be75fc9bbb2d148660ee8c8a@haskell.org> Message-ID: <062.9aa1f2112f1498cb60a2fdf9a3b8fe40@haskell.org> #15188: Catch cases where both branches of an if jump to the same block. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (CodeGen) | Resolution: fixed | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4740 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 00:20:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 00:20:45 -0000 Subject: [GHC] #14343: bad pretty-printing of types with promoted data types In-Reply-To: <048.9dafa4d8103f25346932aca07d111b88@haskell.org> References: <048.9dafa4d8103f25346932aca07d111b88@haskell.org> Message-ID: <063.82f1804b66319d33949bb92333c53d16@haskell.org> #14343: bad pretty-printing of types with promoted data types -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: andreash Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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:D4746 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 01:14:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 01:14:36 -0000 Subject: [GHC] #15209: ~# is always in scope with TypeOperators In-Reply-To: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> References: <045.a34fe11ee89db0cfed0ea681a1b61885@haskell.org> Message-ID: <060.a45e3406128c1660743bcde1cece4a38@haskell.org> #15209: ~# is always in scope with TypeOperators -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4763, Wiki Page: | Phab:D4801 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 01:34:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 01:34:07 -0000 Subject: [GHC] #15079: GHC HEAD regression: cannot instantiate higher-rank kind In-Reply-To: <050.d29ab0a2c8c230faa38439fac305fb8f@haskell.org> References: <050.d29ab0a2c8c230faa38439fac305fb8f@haskell.org> Message-ID: <065.5be62132820c92ae7d939a3d6d13a77c@haskell.org> #15079: GHC HEAD regression: cannot instantiate higher-rank kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: fixed | Keywords: TypeInType 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:D4803 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 08:03:31 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 08:03:31 -0000 Subject: [GHC] #15149: Identical distinct type family fields miscompiled In-Reply-To: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> References: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> Message-ID: <066.e31924a948384bd9941715984a2ab2e8@haskell.org> #15149: Identical distinct type family fields miscompiled -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14747 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * owner: (none) => adamgundry * related: => #14747 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 08:04:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 08:04:55 -0000 Subject: [GHC] #14747: DisambiguateRecordFields fails for PatternSynonyms In-Reply-To: <049.f08f8caee266cae142af76acb98feb02@haskell.org> References: <049.f08f8caee266cae142af76acb98feb02@haskell.org> Message-ID: <064.0867b038ca4ef6707219509543af23c0@haskell.org> #14747: DisambiguateRecordFields fails for PatternSynonyms -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11283, #15149 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * owner: (none) => adamgundry * related: #11283 => #11283, #15149 Comment: #15149 outlines a plan that should allow fixing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 09:33:24 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 09:33:24 -0000 Subject: [GHC] #14783: Initializing record with similarly named field from a different record results in warning rather than error In-Reply-To: <053.5b725cc1d4e4c8f45180bb4a879fba30@haskell.org> References: <053.5b725cc1d4e4c8f45180bb4a879fba30@haskell.org> Message-ID: <068.f5cd773d3deea2552326e33846544c15@haskell.org> #14783: Initializing record with similarly named field from a different record results in warning rather than error -------------------------------------+------------------------------------- Reporter: ulrikrasmussen | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.3 Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: records | DuplicateRecordFields ORF Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #13847 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * status: new => closed * failure: None/Unknown => GHC accepts invalid program * resolution: => duplicate * related: => #13847 * milestone: => 8.2.3 Comment: Thanks for the report! This bug exists in 8.0.x and 8.2.x but is fixed in the 8.4.x series. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 10:21:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 10:21:14 -0000 Subject: [GHC] #15228: Remove use of showSDocUnsafe in extending_ghc.rst In-Reply-To: <049.650bd7ca58a3da7c4bb024d6426a0cdd@haskell.org> References: <049.650bd7ca58a3da7c4bb024d6426a0cdd@haskell.org> Message-ID: <064.18563bceb381f2aa7c2340a029e34e2d@haskell.org> #15228: Remove use of showSDocUnsafe in extending_ghc.rst -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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:D4815 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * status: new => patch * differential: => Phab:D4815 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 10:55:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 10:55:57 -0000 Subject: [GHC] #15240: GHCi's :doc doesn't find the documentation for some class methods In-Reply-To: <046.ede54e8388156191497230366321bb0a@haskell.org> References: <046.ede54e8388156191497230366321bb0a@haskell.org> Message-ID: <061.100ec5116606a37468971f77362a389f@haskell.org> #15240: GHCi's :doc doesn't find the documentation for some class methods -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: sjakobi Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 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 sjakobi): * owner: (none) => sjakobi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 12:41:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 12:41:32 -0000 Subject: [GHC] #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications In-Reply-To: <050.1e1b033722e186882d08840a201168c5@haskell.org> References: <050.1e1b033722e186882d08840a201168c5@haskell.org> Message-ID: <065.9adfb9d17a173e4ddcd5702e821e80a8@haskell.org> #11376: Inconsistent specified type variables among functions and datatypes/classes when using -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: fixed | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"40db277f1dedd4df7e75cc0eb35aa7e1e1ded02a/ghc" 40db277f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="40db277f1dedd4df7e75cc0eb35aa7e1e1ded02a" Fix `print-explicit-runtime-reps` (#11786). By fixing splitting of IfaceTypes in splitIfaceSigmaTy. Test Plan: make test TEST="T11549 T11376 T11786" Reviewers: goldfire, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #11786, #11376 Differential Revision: https://phabricator.haskell.org/D4733 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 12:41:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 12:41:32 -0000 Subject: [GHC] #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks In-Reply-To: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> References: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> Message-ID: <061.069780ad6d0069718da114adcdfa11f3@haskell.org> #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sighingnow Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13275, #15181 | Differential Rev(s): Phab:D4733 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"40db277f1dedd4df7e75cc0eb35aa7e1e1ded02a/ghc" 40db277f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="40db277f1dedd4df7e75cc0eb35aa7e1e1ded02a" Fix `print-explicit-runtime-reps` (#11786). By fixing splitting of IfaceTypes in splitIfaceSigmaTy. Test Plan: make test TEST="T11549 T11376 T11786" Reviewers: goldfire, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #11786, #11376 Differential Revision: https://phabricator.haskell.org/D4733 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 12:48:30 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 12:48:30 -0000 Subject: [GHC] #14890: Make Linux slow validate green In-Reply-To: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> References: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> Message-ID: <061.a057f4b45df6ce09324b4ccb861fa170@haskell.org> #14890: Make Linux slow validate green -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.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): D4546, D4636, Wiki Page: | D4712 -------------------------------------+------------------------------------- Comment (by alpmestan): The commit has hit the master branch on github ([https://github.com/ghc/ghc/commit/838aeb9b254efb3df7ed0cedeb945ec7c7789c90 link]), so we should get slow validate reports for master starting tomorrow morning. If we have new failures, I'll address them ASAP and then close this ticket (wooh. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 12:50:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 12:50:36 -0000 Subject: [GHC] #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks In-Reply-To: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> References: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> Message-ID: <061.2ef369ec383ebccbfc291a3bbceadbdc@haskell.org> #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sighingnow Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13275, #15181 | Differential Rev(s): Phab:D4733 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 13:03:30 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 13:03:30 -0000 Subject: [GHC] #13573: Add Foldable1 to base In-Reply-To: <051.5343934480dda921b1b6981f18b39763@haskell.org> References: <051.5343934480dda921b1b6981f18b39763@haskell.org> Message-ID: <066.7ce2bdb41ed23b6fcaffa21a41f48264@haskell.org> #13573: Add Foldable1 to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.8.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: #10365 | Differential Rev(s): Phab:D4812 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Thank you chessai -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 13:16:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 13:16:38 -0000 Subject: [GHC] #14904: Compiler panic (piResultTy) In-Reply-To: <047.da803a71fb92b792256c7a85e0a6a6bc@haskell.org> References: <047.da803a71fb92b792256c7a85e0a6a6bc@haskell.org> Message-ID: <062.ee096f2f8365a0fdf494e4367e92bb95@haskell.org> #14904: Compiler panic (piResultTy) -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T14904a, | typecheck/should_fail/T14904b Blocked By: | Blocking: Related Tickets: #14873 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): For `ASSERT`-enabled ghc-stage2, the testcase T14904b still raises an "ASSERT failed!" panic. Not sure if it's worth further fix. T14904b.hs: {{{#!hs import Data.Kind type family F f :: Type where F ((f :: forall a. g a) :: forall a. g a) = Int }}} The panic error message: {{{ λ ginplace\bin\ghc-stage2.exe--make T.hs [1 of 1] Compiling T14904b ( T.hs, T.o ) ghc-stage2.exe: panic! (the 'impossible' happened) (GHC version 8.5.20180608 for x86_64-unknown-mingw32): ASSERT failed! 1 0 k_aWM[tau:0] (g_aWI[sig:0] |> {co_aWV}) a_aX4[tau:0] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler\utils\Outputable.hs:1161:37 in ghc:Outputable pprPanic, called at compiler\utils\Outputable.hs:1220:5 in ghc:Outputable assertPprPanic, called at compiler\\typecheck\\TcMType.hs:745:54 in ghc:TcMType CallStack (from -prof): TcRnDriver.tc_rn_src_decls (compiler\typecheck\TcRnDriver.hs:(496,4)-(560,7)) TcRnDriver.tcRnSrcDecls (compiler\typecheck\TcRnDriver.hs:259:25-65) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 13:32:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 13:32:22 -0000 Subject: [GHC] #15240: GHCi's :doc doesn't find the documentation for some class methods In-Reply-To: <046.ede54e8388156191497230366321bb0a@haskell.org> References: <046.ede54e8388156191497230366321bb0a@haskell.org> Message-ID: <061.9e95ff03e25d0469647613d1e59fcab9@haskell.org> #15240: GHCi's :doc doesn't find the documentation for some class methods -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: sjakobi Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4816 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * status: new => patch * differential: => Phab:D4816 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 13:38:18 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 13:38:18 -0000 Subject: [GHC] #15247: Use empty types for TTG extension constructors Message-ID: <049.3f476ec77558935c405635633053b4a4@haskell.org> #15247: Use empty types for TTG extension constructors -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: TTG | 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 happened to be looking at `AmbiguousFieldOcc` and noticed that it has gained an `XAmbiguousFieldOcc` extension constructor for Trees That Grow, but lots of the destructor functions in `HsTypes` panic if they see this constructor (which is understandable, because they aren't expecting extensions). In general, perhaps it should be the case that for concrete phase descriptors (e.g. `GhcRn`) where extension constructors are not expected, the extension constructor argument type should be empty? It would then be clear that they should not be expected (barring abuse of laziness) and pattern matching on them could eliminate the empty type. That is, instead of the existing {{{#!hs data NoExt = NoExt type instance XXAmbiguousFieldOcc (GhcPass _) = NoExt }}} we would define {{{#!hs data NoExtConstructor -- empty data type noExtConstructor :: NoExtConstructor -> a noExtConstructor x = case x of {} type instance XXAmbiguousFieldOcc (GhcPass _) = NoExtConstructor }}} and similarly for other `XX...` type families. Alan, Shayan, is there any reason this couldn't work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 13:45:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 13:45:52 -0000 Subject: [GHC] #14928: TH eats 50 GB memory when creating ADT with multiple constructors In-Reply-To: <047.b13a12d7e6e4b7703250170f5b54bd52@haskell.org> References: <047.b13a12d7e6e4b7703250170f5b54bd52@haskell.org> Message-ID: <062.d2fbd6ea411e2a23b3990932f28d96bc@haskell.org> #14928: TH eats 50 GB memory when creating ADT with multiple constructors -------------------------------------+------------------------------------- Reporter: YitzGale | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.2.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: | -------------------------------------+------------------------------------- Comment (by bgamari): While I don't doubt that we could (and should!) do a better job of compiling code like this, I would suggest that regular structures like this should really be encoded as a data structure, not code as is done here. Not only does compiling all of these large cases produce a great deal of work for the compiler but it's also inefficient. For instance, the Core produced by the `snoyberg-master` essentially implements an linear search over languages, doing a string comparison for every language for which localizations are available: {{{#!hs case ds_doaz of { MsgTestLocalizationMessage001 -> case == @ I18N.Lang Data.Text.$fEqText lang_a53E (Data.Text.pack (GHC.CString.unpackCString# "da"#)) of { False -> case == @ I18N.Lang Data.Text.$fEqText lang_a53E (Data.Text.pack (GHC.CString.unpackCString# "da- DK"#)) of { False -> ... True -> Data.Text.pack (GHC.CString.unpackCString# "This is test localization message number 1 in da-DK."#) }; True -> Data.Text.pack (GHC.CString.unpackCString# "This is test localization message number 1 in da."#) }; }}} Surely this would be better implemented as a hash-map or some other structure with sublinear lookup. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 13:54:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 13:54:09 -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.5cf65bf9447d5670eddb37788cf269a1@haskell.org> #14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: SantiM Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.0.1 (Linker) | 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 SantiM): * owner: (none) => SantiM Comment: I'm working with a friend on this bug as part of ZuriHac, we'll be sending changes for different files affected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 14:05:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 14:05:58 -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.026ffdde6e1837315005177e4e7a206d@haskell.org> #14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: SantiM Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.0.1 (Linker) | 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:D4817 Wiki Page: | -------------------------------------+------------------------------------- Changes (by SantiM): * differential: => Phab:D4817 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 14:07:51 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 14:07:51 -0000 Subject: [GHC] #15248: Coercions from plugins cannot be stopped from floating out Message-ID: <047.b9c19d01ecac3fcb10e89f9f106d5010@haskell.org> #15248: Coercions from plugins cannot be stopped from floating out -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Suppose we have {{{#!hs type family (a :: Nat) GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 15:42:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 15:42:10 -0000 Subject: [GHC] #15248: Coercions from plugins cannot be stopped from floating out In-Reply-To: <047.b9c19d01ecac3fcb10e89f9f106d5010@haskell.org> References: <047.b9c19d01ecac3fcb10e89f9f106d5010@haskell.org> Message-ID: <062.869751c389dd7df6c26c507a27398cc8@haskell.org> #15248: Coercions from plugins cannot be stopped from floating out -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 adamgundry): * cc: adamgundry (added) Comment: In this case, in principle, shouldn't the evidence produced for the plugin directly depend on the evidence for the assumptions? That is, rather than "proving" `(a a True) }}} by `UnivCo` and then instantiate it with your evidence for `(a GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 15:42:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 15:42:50 -0000 Subject: [GHC] #15248: Coercions from plugins cannot be stopped from floating out In-Reply-To: <047.b9c19d01ecac3fcb10e89f9f106d5010@haskell.org> References: <047.b9c19d01ecac3fcb10e89f9f106d5010@haskell.org> Message-ID: <062.e1b321b486c1952c59d74c49df17006e@haskell.org> #15248: Coercions from plugins cannot be stopped from floating out -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeCheckerPlugins 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 adamgundry): * keywords: => TypeCheckerPlugins -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 15:48:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 15:48:55 -0000 Subject: [GHC] #15248: Coercions from plugins cannot be stopped from floating out In-Reply-To: <047.b9c19d01ecac3fcb10e89f9f106d5010@haskell.org> References: <047.b9c19d01ecac3fcb10e89f9f106d5010@haskell.org> Message-ID: <062.950c87c50c274893a189f6a1f2f16673@haskell.org> #15248: Coercions from plugins cannot be stopped from floating out -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeCheckerPlugins 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): But comment:1 seems to require a constrained type in the `~` relation, which is generally not allowed. I suppose nothing stops a plugin from producing such things (and GHC might even consume them correctly), but I don't think that's explicitly a supported feature. (You can't say that in source Haskell, for example. Even with quantified constraints.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 15:56:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 15:56:26 -0000 Subject: [GHC] #15180: Make Control.Exception.throw levity polymorphic In-Reply-To: <049.93e817224f99000e45e381c766dae62b@haskell.org> References: <049.93e817224f99000e45e381c766dae62b@haskell.org> Message-ID: <064.ccf5d040e7e4f0c83f455e71eec8a2af@haskell.org> #15180: Make Control.Exception.throw levity polymorphic -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | LevityPolymorphism, 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 Ninjatrappeur): I'm going to give a try to this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 16:14:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 16:14:26 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.b0b85c905f60a8972f46386a5ec8baff@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 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, #13386 | Phab:D4766 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * differential: Phab:D3752 => Phab:D3752, Phab:D4766 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 16:17:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 16:17:05 -0000 Subject: [GHC] #15248: Coercions from plugins cannot be stopped from floating out In-Reply-To: <047.b9c19d01ecac3fcb10e89f9f106d5010@haskell.org> References: <047.b9c19d01ecac3fcb10e89f9f106d5010@haskell.org> Message-ID: <062.0294f0fc4e5448d0fe74f46a2412f087@haskell.org> #15248: Coercions from plugins cannot be stopped from floating out -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeCheckerPlugins 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: see comment:15 on #8095, and the discussion on Phab:D4766. `PlugInProv` should have a `TyCoVarSet` just as the (upcoming) `ZappedProv` does, and for the same reasons. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 16:20:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 16:20:15 -0000 Subject: [GHC] #15247: Use empty types for TTG extension constructors In-Reply-To: <049.3f476ec77558935c405635633053b4a4@haskell.org> References: <049.3f476ec77558935c405635633053b4a4@haskell.org> Message-ID: <064.04d9219bbf77e25bdaafa7bee1ee05bc@haskell.org> #15247: Use empty types for TTG extension constructors -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: TTG 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): Whatever is decided, the answers should go in [wiki:ImplementingTreesThatGrow/TreesThatGrowGuidance] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 16:47:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 16:47:55 -0000 Subject: [GHC] #15149: Identical distinct type family fields miscompiled In-Reply-To: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> References: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> Message-ID: <066.346cc569a6d78124fcccd4cae2e2da6a@haskell.org> #15149: Identical distinct type family fields miscompiled -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14747 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I'm concerned that it might impact TH users though, as they will have only an OccName where previously they had a Name Well comment:4 suggests leaving it as `TH.Name`; as subsequent bullets point out, we need correspondingly need `RdrName` not `OccName` in `HsSyn.` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 19:20:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 19:20:19 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.b760fcfcaec06a41bc1ea40760fcddca@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | 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): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Old description: > This patch aims at defining the new coercion rule > > {{{#!hs > | EraseEqCo Role Type Type KindCoercion > -- "e" -> _ -> _ -> N -> e > }}} > > which corresponds to the typing rule > > {{{ > t1 : k1 t2 : k2 |t1| = |t2| g : k1 ~ k2 > ------------------------------------ > EraseEqCo r t1 t2 g : t1 ~r t2 > }}} > > Namely, if two types after erasure of casts and coercions are equivalent, > then they can be casted from and to each other. This new coercion rule is > designed to replace the current coherence rule > > {{{#!hs > -- Coherence applies a coercion to the left-hand type of another > coercion > -- See Note [Coherence] > | CoherenceCo Coercion KindCoercion > -- :: e -> N -> e > }}} > > The new rule is useful in several places. For example, now it is easier > to define coercion {{{t |> k ~ t}}} without resorting to reflexivity > coercion, and {{{t ~ t |> k}}} without resorting to symmetric rule. New description: This patch aims at generalizing the reflexive coercion to {{{#!hs | GRefl Role Type MCoercion }}} which corresponds to the typing rule {{{ t1 : k1 ------------------------------------ GRefl r t1 MRefl: t1 ~r t1 t1 : k1 co :: k1 ~ k2 ------------------------------------ GRefl r t1 (MCo co) : t1 ~r t1 |> co }}} {{{MCoercion}}} wraps a coercion, which might be reflexive (MRefl) or not (MCo co). To know more about MCoercion see [https://ghc.haskell.org/trac/ghc/ticket/14975 #14975]. This new coercion rule will replace the current coherence rule {{{#!hs -- Coherence applies a coercion to the left-hand type of another coercion -- See Note [Coherence] | CoherenceCo Coercion KindCoercion -- :: e -> N -> e }}} -- Comment (by ningning): Update the ticket from {{{EraseEqCo}}} to {{{GRefl}}} according to the discussion with Richard and Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 19:34:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 19:34:52 -0000 Subject: [GHC] #15231: UndecidableInstances validity checking is wrong in the presence of QuantifiedConstraints In-Reply-To: <050.e69160ac4e3631edefda13f39672a247@haskell.org> References: <050.e69160ac4e3631edefda13f39672a247@haskell.org> Message-ID: <065.fa5d423041853a2345db63d200519531@haskell.org> #15231: UndecidableInstances validity checking is wrong in the presence of QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints 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:D4819 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * status: new => patch * differential: => Phab:D4819 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 19:38:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 19:38:38 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF In-Reply-To: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> References: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> Message-ID: <060.f5a07ca13a0040b082c9e0086ea8aebd@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): Phab:D4796 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I'm also not sure it's worth the trouble, although the current state of affairs seems a bit tricky to document in the Haddocks for `evaluate`. But considering `Control. Parallel.Strategies.rdeepseq`, I realized that even this binder swap, in combination with what I've already done, isn't really quite enough. Suppose we have {{{#!hs let e = x + 3 :: Int in case seq# e s of (# s', e' #) -> E }}} We'd actually like to know that not only `e` and `e'`, but also `x`, are evaluated in `E`, because `e` is strict in `x`. So if we do a binder swap, we should do it for all the variables the scrutinee is strict in that are not already known to be evaluated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 19:46:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 19:46:06 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF In-Reply-To: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> References: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> Message-ID: <060.3a4a7c4142a49b8b4a22b9f4354789ca@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): Phab:D4796 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Is there anything to document? It doesn't affect the semantics of `evaluate`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 20:11:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 20:11:02 -0000 Subject: [GHC] #15247: Use empty types for TTG extension constructors In-Reply-To: <049.3f476ec77558935c405635633053b4a4@haskell.org> References: <049.3f476ec77558935c405635633053b4a4@haskell.org> Message-ID: <064.79f7c3dfa332692eff286d758ee73ae0@haskell.org> #15247: Use empty types for TTG extension constructors -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: TTG 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 alanz): I just tried this, and it seems the additional match is still required. I end up with {{{#!hs compiler/hsSyn/HsTypes.hs:1286:1: error: [-Wincomplete-patterns, -Werror =incomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘unambiguousFieldOcc’: Patterns not matched: (XAmbiguousFieldOcc _) | 1286 | unambiguousFieldOcc (Unambiguous rdr sel) = FieldOcc rdr sel }}} having removed the last line of {{{#!hs unambiguousFieldOcc :: AmbiguousFieldOcc GhcTc -> FieldOcc GhcTc unambiguousFieldOcc (Unambiguous rdr sel) = FieldOcc rdr sel unambiguousFieldOcc (Ambiguous rdr sel) = FieldOcc rdr sel unambiguousFieldOcc (XAmbiguousFieldOcc _) = panic "unambiguousFieldOcc" }}} Perhaps I misunderstand how this is intended to work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 21:04:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 21:04:32 -0000 Subject: [GHC] #15247: Use empty types for TTG extension constructors In-Reply-To: <049.3f476ec77558935c405635633053b4a4@haskell.org> References: <049.3f476ec77558935c405635633053b4a4@haskell.org> Message-ID: <064.630860a636286d79a201091e5c131b0a@haskell.org> #15247: Use empty types for TTG extension constructors -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: TTG 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 Shayan-Najd): Hi Adam, Take a look at [wiki:ImplementingTreesThatGrow/TreesThatGrowGuidance], there we use the "standard" empty type `Void` and its eliminator `absurd` from `Data.Void`. Currently, TTG does not fully follow the guidelines as the extension constructors are barely used. I will soon have a pass over the current TTG implementation and fix it to match the guidelines. As we used `NoExt` instead of `()`, we can possibly use a GHC-Specific empty datatype instead of `Void`. Is there anything else that I may be missing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 21:39:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 21:39:58 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.fa7860d25ce7fd25aa4b87392b283e30@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | 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): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > This patch aims at generalizing the reflexive coercion to > {{{#!hs > | GRefl Role Type MCoercion > }}} > > which corresponds to the typing rule > > {{{ > t1 : k1 > ------------------------------------ > GRefl r t1 MRefl: t1 ~r t1 > > t1 : k1 co :: k1 ~ k2 > ------------------------------------ > GRefl r t1 (MCo co) : t1 ~r t1 |> co > }}} > > {{{MCoercion}}} wraps a coercion, which might be reflexive (MRefl) or not > (MCo co). To know more about MCoercion see > [https://ghc.haskell.org/trac/ghc/ticket/14975 #14975]. > > This new coercion rule will replace the current coherence rule > > {{{#!hs > -- Coherence applies a coercion to the left-hand type of another > coercion > -- See Note [Coherence] > | CoherenceCo Coercion KindCoercion > -- :: e -> N -> e > }}} New description: This patch aims at generalizing the reflexive coercion to {{{#!hs | GRefl Role Type MCoercion }}} As its name suggests, and as its typing rule makes precise, `GRefl` is generalised version of `Refl`: {{{ t1 : k1 ------------------------------------ GRefl r t1 MRefl: t1 ~r t1 t1 : k1 co :: k1 ~ k2 ------------------------------------ GRefl r t1 (MCo co) : t1 ~r t1 |> co }}} {{{MCoercion}}} wraps a coercion, which might be reflexive (MRefl) or not (MCo co). To know more about MCoercion see [https://ghc.haskell.org/trac/ghc/ticket/14975 #14975]. This new coercion form will replace both `Refl` and the current `CoherenceCo`: {{{#!hs | Refl Role Type -- Coherence applies a coercion to the left-hand type of another coercion -- See Note [Coherence] | CoherenceCo Coercion KindCoercion -- :: e -> N -> e }}} When the `MCoercion` is `MRefl`, `GRefl` is just the same as `Refl`. It is easy to express `CoherenceCo` using `GRefl`. If `g1 :: s ~r t`, then {{{ CoherenceCo g1 g2 :: (s |> g2) ~r t Sym (GRefl r s g2) ; g1 :: (s |> g1) ~r t }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 21:57:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 21:57:22 -0000 Subject: [GHC] #13833: Instances with GHC.TypeLits.Nat/Symbol should be possible without FlexibleInstances. In-Reply-To: <045.899fdc291fee22417bd4b56eb02e56da@haskell.org> References: <045.899fdc291fee22417bd4b56eb02e56da@haskell.org> Message-ID: <060.a105e49315caa35d5217ffebd0e6c134@haskell.org> #13833: Instances with GHC.TypeLits.Nat/Symbol should be possible without FlexibleInstances. -------------------------------------+------------------------------------- Reporter: Hjulle | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.2 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 qrilka): I'd like to try solving this one -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 22:10:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 22:10:23 -0000 Subject: [GHC] #13833: Instances with GHC.TypeLits.Nat/Symbol should be possible without FlexibleInstances. In-Reply-To: <045.899fdc291fee22417bd4b56eb02e56da@haskell.org> References: <045.899fdc291fee22417bd4b56eb02e56da@haskell.org> Message-ID: <060.b8edd2428ec8e908ff7f62fdab0f82b0@haskell.org> #13833: Instances with GHC.TypeLits.Nat/Symbol should be possible without FlexibleInstances. -------------------------------------+------------------------------------- Reporter: Hjulle | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.2 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 bgamari): Do let us know if you get stuck, qrilka. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 22:20:31 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 22:20:31 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF In-Reply-To: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> References: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> Message-ID: <060.2779d2e201a7464257fcd7acc831010d@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): Phab:D4796 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > So if we do a binder swap, we should do it for all the variables the scrutinee is strict This is a bridge too far! Strictness analysis will work this out, I think. Eg that `let e` will turn into a case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 8 23:27:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Jun 2018 23:27:57 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF In-Reply-To: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> References: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> Message-ID: <060.b3373c0c658404078cdf96c044bbeb72@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): Phab:D4796 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:14 simonpj]: > > So if we do a binder swap, we should do it for all the variables the scrutinee is strict > > This is a bridge too far! Strictness analysis will work this out, I think. Eg that `let e` will turn into a case. I don't think so. `seq#` is intentionally lazy in its argument, to allow explicit ordering in an `IO` context. This seems pretty important in combination with `spark#`, for example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 9 07:40:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jun 2018 07:40:54 -0000 Subject: [GHC] #15149: Identical distinct type family fields miscompiled In-Reply-To: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> References: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> Message-ID: <066.07a02720d5443e84f8938a2754a3f994@haskell.org> #15149: Identical distinct type family fields miscompiled -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14747 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): I think I've come across a simpler way to fix this and #14747. At the moment, `rnHsRecFields` goes to some trouble to figure out the parent type constructor of the data constructor (in `find_tycon`) and then does field name lookup using the parent type constructor. But we already have `lookupConstructorFields` which lets us directly find out the `FieldLabel`s of a data constructor! (This is used for expanding dot-dot patterns.) So why don't we just use `lookupConstructorFields` and search amongst them for the right one? We'd need to be a bit careful to still check the name is in scope (with the right module qualifier, if any), but that should be simple if we know the unambiguous selector name already. Moving field label resolution to the typechecker still might be worth doing, because it should get rid of quite a bit of duplication. But it's not a small task (e.g. because of dot-dot patterns) so I think it's worth pursuing the small fix first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 9 07:47:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jun 2018 07:47:18 -0000 Subject: [GHC] #15185: Enum instance for IntX / WordX are inefficient In-Reply-To: <045.8d849a48d67b73f64eaab8f541972e7c@haskell.org> References: <045.8d849a48d67b73f64eaab8f541972e7c@haskell.org> Message-ID: <060.71d2262fdea1b8de662664f6cb702783@haskell.org> #15185: Enum instance for IntX / WordX are inefficient -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.2 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:D4820 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * status: new => patch * differential: => Phab:D4820 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 9 07:49:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jun 2018 07:49:37 -0000 Subject: [GHC] #15247: Use empty types for TTG extension constructors In-Reply-To: <049.3f476ec77558935c405635633053b4a4@haskell.org> References: <049.3f476ec77558935c405635633053b4a4@haskell.org> Message-ID: <064.a92ab637fc75168eafc4fd386c872afa@haskell.org> #15247: Use empty types for TTG extension constructors -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: TTG 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 adamgundry): Replying to [comment:2 alanz]: > I just tried this, and it seems the additional match is still required. I end up with > > {{{#!hs > compiler/hsSyn/HsTypes.hs:1286:1: error: [-Wincomplete-patterns, -Werror =incomplete-patterns] > Pattern match(es) are non-exhaustive > In an equation for ‘unambiguousFieldOcc’: > Patterns not matched: (XAmbiguousFieldOcc _) > | > 1286 | unambiguousFieldOcc (Unambiguous rdr sel) = FieldOcc rdr sel > }}} > > having removed the last line of > > {{{#!hs > unambiguousFieldOcc :: AmbiguousFieldOcc GhcTc -> FieldOcc GhcTc > unambiguousFieldOcc (Unambiguous rdr sel) = FieldOcc rdr sel > unambiguousFieldOcc (Ambiguous rdr sel) = FieldOcc rdr sel > unambiguousFieldOcc (XAmbiguousFieldOcc _) = panic "unambiguousFieldOcc" > }}} > > Perhaps I misunderstand how this is intended to work? You can't remove the last line entirely because it can still potentially match (if called with `XAmbiguousFieldOcc undefined`). But you can eliminate the empty data type with an empty case analysis (or calling my `noExtConstructor`). Replying to [comment:3 Shayan-Najd]: > Take a look at ImplementingTreesThatGrow/TreesThatGrowGuidance, there we use the "standard" empty type Void and its eliminator absurd from Data.Void. > > Currently, TTG does not fully follow the guidelines as the extension constructors are barely used. I will soon have a pass over the current TTG implementation and fix it to match the guidelines. Okay, it sounds like we are in agreement. That page could be a bit more explicit about the use of the empty type (the only mention I can see is one line of an example using `Void`). Moreover, it doesn't seem to mention `NoExt`. > As we used NoExt instead of (), we can possibly use a GHC-Specific empty datatype instead of Void. Yes, I think this would be a good idea. It's clearer for documentation purposes to use a custom empty datatype, and given that the only duplication consists of precisely one type constructor and one function, reusing `Data.Void` doesn't buy much. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 9 09:23:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jun 2018 09:23:37 -0000 Subject: [GHC] #15149: Identical distinct type family fields miscompiled In-Reply-To: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> References: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> Message-ID: <066.639c50505500b53933219fa9ca12e29b@haskell.org> #15149: Identical distinct type family fields miscompiled -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: adamgundry Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T15149 Blocked By: | Blocking: Related Tickets: #14747 | Differential Rev(s): Phab:D4821 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * testcase: => rename/should_compile/T15149 * status: new => patch * differential: => Phab:D4821 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 9 09:24:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jun 2018 09:24:17 -0000 Subject: [GHC] #14747: DisambiguateRecordFields fails for PatternSynonyms In-Reply-To: <049.f08f8caee266cae142af76acb98feb02@haskell.org> References: <049.f08f8caee266cae142af76acb98feb02@haskell.org> Message-ID: <064.9879c2aba2245031f0026b63f5bf9d88@haskell.org> #14747: DisambiguateRecordFields fails for PatternSynonyms -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T14747 Blocked By: | Blocking: Related Tickets: #11283, #15149 | Differential Rev(s): Phab:D4821 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * status: new => patch * testcase: => rename/should_compile/T14747 * differential: => Phab:D4821 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 9 09:50:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jun 2018 09:50:37 -0000 Subject: [GHC] #14502: Build Alpine Linux binary distributions In-Reply-To: <046.7faa39537281abdbe7789c4ce9416be8@haskell.org> References: <046.7faa39537281abdbe7789c4ce9416be8@haskell.org> Message-ID: <061.619e90579c624dbc4deeb207f8b41b9b@haskell.org> #14502: Build Alpine Linux binary distributions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Continuous | Version: 8.2.1 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14057 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by terrorjack): Here's a script to build ghc-8.4.3 bindist for x64 Alpine Linux on Circle CI: https://gist.github.com/TerrorJack/c0b847fff0e9f221144c5b61f69f9988. A pre-built bindist is available at https://felis.sapiens.moe/ghc-8.4.3-x86_64-alpine-linux.tar.xz. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 9 10:41:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jun 2018 10:41:50 -0000 Subject: [GHC] #15249: Add support for cmpeq and cmpgt MMX intrinsics Message-ID: <047.176ece8eb8a34d6eb4b3724ae61ef561@haskell.org> #15249: Add support for cmpeq and cmpgt MMX intrinsics -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: primops | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Add primop support for the following MMX intrinsics: {{{#!c __m64 _mm_cmpeq_pi16 (__m64 a, __m64 b) __m64 _mm_cmpeq_pi32 (__m64 a, __m64 b) __m64 _mm_cmpeq_pi8 (__m64 a, __m64 b) __m64 _mm_cmpeq_pi8 (__m64 a, __m64 b) __m64 _mm_cmpgt_pi16 (__m64 a, __m64 b) __m64 _mm_cmpgt_pi32 (__m64 a, __m64 b) __m64 _mm_cmpgt_pi8 (__m64 a, __m64 b) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 9 10:56:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jun 2018 10:56:20 -0000 Subject: [GHC] #15249: Add support for cmpeq and cmpgt MMX intrinsics In-Reply-To: <047.176ece8eb8a34d6eb4b3724ae61ef561@haskell.org> References: <047.176ece8eb8a34d6eb4b3724ae61ef561@haskell.org> Message-ID: <062.d31160368e13f3e5c512b7cb762d6ac1@haskell.org> #15249: Add support for cmpeq and cmpgt MMX intrinsics -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: primops 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 newhoggy): More information about these intrinsics here: https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=cmp&expand=765,767,802&cats=Compare&techs=MMX -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 9 11:11:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jun 2018 11:11:49 -0000 Subject: [GHC] #15250: Add support for _mm512_shuffle_epi8 intrinsic Message-ID: <047.fda88db89169ce07c0e87baa9a0daf82@haskell.org> #15250: Add support for _mm512_shuffle_epi8 intrinsic -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- {{{#!c __m512i _mm512_shuffle_epi8 (__m512i a, __m512i b) }}} See: https://software.intel.com/sites/landingpage/IntrinsicsGuide/#expand=765,3914,2929,4754,4757&text=_mm512_shuffle_epi8 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 9 11:23:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jun 2018 11:23:30 -0000 Subject: [GHC] #15251: Add support for _mm_shuffle_pi8 intrinsic Message-ID: <047.1baf9e94fd919e2c09fc46e1dd45b87b@haskell.org> #15251: Add support for _mm_shuffle_pi8 intrinsic -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- {{{!#c __m64 _mm_shuffle_pi8 (__m64 a, __m64 b) }}} See: https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm_shuffle_pi8 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 9 13:12:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jun 2018 13:12:02 -0000 Subject: [GHC] #14928: TH eats 50 GB memory when creating ADT with multiple constructors In-Reply-To: <047.b13a12d7e6e4b7703250170f5b54bd52@haskell.org> References: <047.b13a12d7e6e4b7703250170f5b54bd52@haskell.org> Message-ID: <062.f63174889a9ce926a2f643d843973d00@haskell.org> #14928: TH eats 50 GB memory when creating ADT with multiple constructors -------------------------------------+------------------------------------- Reporter: YitzGale | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.2.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: | -------------------------------------+------------------------------------- Comment (by bgamari): The biggest allocator while compiling this program with `-O0` appears to be CodeGen: {{{ !!! Renamer/typechecker [Foundation]: finished in 22503.88 milliseconds, allocated 2682.425 megabytes !!! Desugar [Foundation]: finished in 396.31 milliseconds, allocated 647.120 megabytes !!! Simplifier [Foundation]: finished in 485.76 milliseconds, allocated 675.006 megabytes !!! CoreTidy [Foundation]: finished in 45.90 milliseconds, allocated 88.678 megabytes !!! CorePrep [Foundation]: finished in 168.78 milliseconds, allocated 252.445 megabytes !!! CodeGen [Foundation]: finished in 17228.95 milliseconds, allocated 24917.560 megabytes }}} In particular, we spend a significant amount of time in register allocation and producing assembler. {{{ COST CENTRE MODULE SRC %time %alloc hscCompileCoreExpr' HscMain compiler/main/HscMain.hs:(1805,1)-(1827,24) 63.6 0.1 pprNativeCode AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(529,37)-(530,65) 5.5 18.5 RegAlloc-linear AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(658,27)-(660,55) 4.2 12.5 regLiveness AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(591,17)-(593,52) 3.5 10.1 tc_rn_src_decls TcRnDriver compiler/typecheck/TcRnDriver.hs:(491,4)-(555,7) 2.8 8.0 StgCmm HscMain compiler/main/HscMain.hs:(1463,13)-(1464,62) 2.7 7.8 genMachCode AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(580,17)-(582,62) 2.4 6.6 NativeCodeGen CodeOutput compiler/main/CodeOutput.hs:166:18-78 1.8 4.0 layoutStack CmmPipeline compiler/cmm/CmmPipeline.hs:(98,13)-(100,40) 1.6 4.3 fixStgRegisters AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:566:17-42 1.3 1.2 cmmToCmm AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:571:17-50 1.0 2.4 sequenceBlocks AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:699:17-49 0.8 1.7 doSRTs CmmPipeline compiler/cmm/CmmPipeline.hs:47:46-71 0.6 1.1 Digraph.scc Digraph compiler/utils/Digraph.hs:277:44-67 0.5 2.2 cmmCfgOpts(1) CmmPipeline compiler/cmm/CmmPipeline.hs:64:13-62 0.5 1.6 revPostorder CmmUtils compiler/cmm/CmmUtils.hs:561:5-47 0.5 1.0 deSugar HscMain compiler/main/HscMain.hs:544:7-44 0.4 1.4 simplExprF1-App Simplify compiler/simplCore/Simplify.hs:(866,34)-(883,62) 0.3 1.3 occAnalBind.assoc OccurAnal compiler/simplCore/OccurAnal.hs:819:13-60 0.3 1.1 }}} Compiling with `-O1` tells a very similar story; each simplifier pass only allocates a gigabyte or two, with codegen allocating several tens of GB. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 9 13:20:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jun 2018 13:20:06 -0000 Subject: [GHC] #15249: Add support for cmpeq and cmpgt MMX intrinsics In-Reply-To: <047.176ece8eb8a34d6eb4b3724ae61ef561@haskell.org> References: <047.176ece8eb8a34d6eb4b3724ae61ef561@haskell.org> Message-ID: <062.62eae02fb03de82aeac0637956f6d366@haskell.org> #15249: Add support for cmpeq and cmpgt MMX intrinsics -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: primops 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 newhoggy): I need this instruction to optimise my succinct data structure based CSV parser. If this instruction was available to me, I would be able to replace code that generates six instructions with code that generates one. https://github.com/haskell-works/hw-dsv/pull/12/files -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 9 14:28:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jun 2018 14:28:12 -0000 Subject: [GHC] #15252: syn_arg_wraps and syn_res_wrap are only populated after typechecking Message-ID: <049.1a5ef24fb5e35afe5e2b66465a8d0d89@haskell.org> #15252: syn_arg_wraps and syn_res_wrap are only populated after typechecking -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- The definition for `SyntaxExpr` has two fields which are only populated after type checking. `SyntaxExpr` should have an extension point which contains these two fields. {{{ data SyntaxExpr p = SyntaxExpr { syn_expr :: HsExpr p , syn_arg_wraps :: [HsWrapper] , syn_res_wrap :: HsWrapper } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 9 14:46:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jun 2018 14:46:52 -0000 Subject: [GHC] #14928: TH eats 50 GB memory when creating ADT with multiple constructors In-Reply-To: <047.b13a12d7e6e4b7703250170f5b54bd52@haskell.org> References: <047.b13a12d7e6e4b7703250170f5b54bd52@haskell.org> Message-ID: <062.2377d5decb0f8be652257af1a24e2258@haskell.org> #14928: TH eats 50 GB memory when creating ADT with multiple constructors -------------------------------------+------------------------------------- Reporter: YitzGale | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Template Haskell | Version: 8.2.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: 8.6.1 => 8.4.1 Comment: I can reproduce the high residency when building `snoyman-master` with GHC 8.2.1 (or GHC 8.4.1) and optimisation enabled, but have been unable to do so with GHC `master`. I believe the memory leak present in 8.2/8.4 has since been fixed. For what it's worth, I was also able to reproduce the issue using a Nix `ghcHEAD` snapshot from 20180118, so it was fixed relatively recently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 9 16:15:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jun 2018 16:15:40 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.26825b9bf2d62ef4c687322093f152f0@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | 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): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Old description: > This patch aims at generalizing the reflexive coercion to > {{{#!hs > | GRefl Role Type MCoercion > }}} > As its name suggests, and as its typing rule makes precise, `GRefl` is > generalised version of `Refl`: > > {{{ > t1 : k1 > ------------------------------------ > GRefl r t1 MRefl: t1 ~r t1 > > t1 : k1 co :: k1 ~ k2 > ------------------------------------ > GRefl r t1 (MCo co) : t1 ~r t1 |> co > }}} > > {{{MCoercion}}} wraps a coercion, which might be reflexive (MRefl) or not > (MCo co). To know more about MCoercion see > [https://ghc.haskell.org/trac/ghc/ticket/14975 #14975]. > > This new coercion form will replace both `Refl` and the current > `CoherenceCo`: > > {{{#!hs > | Refl Role Type > > -- Coherence applies a coercion to the left-hand type of another > coercion > -- See Note [Coherence] > | CoherenceCo Coercion KindCoercion > -- :: e -> N -> e > }}} > > When the `MCoercion` is `MRefl`, `GRefl` is just the same as `Refl`. > > It is easy to express `CoherenceCo` using `GRefl`. If `g1 :: s ~r t`, > then > {{{ > CoherenceCo g1 g2 :: (s |> g2) ~r t > Sym (GRefl r s g2) ; g1 :: (s |> g1) ~r t > }}} New description: This patch aims at generalizing the reflexive coercion to {{{#!hs | GRefl Role Type MCoercion }}} As its name suggests, and as its typing rule makes precise, `GRefl` is generalised version of `Refl`: {{{ t1 : k1 ------------------------------------ GRefl r t1 MRefl: t1 ~r t1 t1 : k1 co :: k1 ~ k2 ------------------------------------ GRefl r t1 (MCo co) : t1 ~r t1 |> co }}} {{{MCoercion}}} wraps a coercion, which might be reflexive (MRefl) or any coercion (MCo co). To know more about MCoercion see [https://ghc.haskell.org/trac/ghc/ticket/14975 #14975]. This new coercion form will replace both `Refl` and the current `CoherenceCo`: {{{#!hs | Refl Role Type -- Coherence applies a coercion to the left-hand type of another coercion -- See Note [Coherence] | CoherenceCo Coercion KindCoercion -- :: e -> N -> e }}} When the `MCoercion` is `MRefl`, `GRefl` is just the same as `Refl`. It is easy to express `CoherenceCo` using `GRefl`. If `g1 :: s ~r t`, then {{{ CoherenceCo g1 g2 :: (s |> g2) ~r t Sym (GRefl r s g2) ; g1 :: (s |> g1) ~r t }}} -- Comment (by ningning): We don't know coercion {{{co}}} in {{{MCo co}}} is reflexive or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 9 17:31:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jun 2018 17:31:18 -0000 Subject: [GHC] #14475: Upload documentation dumps In-Reply-To: <046.875271090aacfb7d8f31943e1b69bd4b@haskell.org> References: <046.875271090aacfb7d8f31943e1b69bd4b@haskell.org> Message-ID: <061.23c151c9692c750d51782f175263588c@haskell.org> #14475: Upload documentation dumps -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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 gander): I would like to work on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 9 17:32:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jun 2018 17:32:39 -0000 Subject: [GHC] #14804: hGetLine does not document whether newline is returned. In-Reply-To: <043.13eb04d8889a6c408bc2d51c04fcc7a1@haskell.org> References: <043.13eb04d8889a6c408bc2d51c04fcc7a1@haskell.org> Message-ID: <058.f11caabc3eea912e054dff96adc3f34c@haskell.org> #14804: hGetLine does not document whether newline is returned. -------------------------------------+------------------------------------- Reporter: akfp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: 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 gander): I would like to work on this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 9 20:32:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Jun 2018 20:32:31 -0000 Subject: [GHC] #13833: Instances with GHC.TypeLits.Nat/Symbol should be possible without FlexibleInstances. In-Reply-To: <045.899fdc291fee22417bd4b56eb02e56da@haskell.org> References: <045.899fdc291fee22417bd4b56eb02e56da@haskell.org> Message-ID: <060.3515b047b9a154eb1d8e06d7bb2a6d35@haskell.org> #13833: Instances with GHC.TypeLits.Nat/Symbol should be possible without FlexibleInstances. -------------------------------------+------------------------------------- Reporter: Hjulle | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.0.2 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:D4823 Wiki Page: | -------------------------------------+------------------------------------- Changes (by qrilka): * status: new => patch * cc: qrilka@… (added) * differential: => Phab:D4823 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 10 06:54:26 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jun 2018 06:54:26 -0000 Subject: [GHC] #14475: Upload documentation dumps In-Reply-To: <046.875271090aacfb7d8f31943e1b69bd4b@haskell.org> References: <046.875271090aacfb7d8f31943e1b69bd4b@haskell.org> Message-ID: <061.9a3080ca3c0866fd2753a96cb9355e71@haskell.org> #14475: Upload documentation dumps -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gander Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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 gander): * owner: bgamari => gander -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 10 06:55:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jun 2018 06:55:37 -0000 Subject: [GHC] #14804: hGetLine does not document whether newline is returned. In-Reply-To: <043.13eb04d8889a6c408bc2d51c04fcc7a1@haskell.org> References: <043.13eb04d8889a6c408bc2d51c04fcc7a1@haskell.org> Message-ID: <058.b6b58517a4a7ec9a911ca24ce1aa0d0a@haskell.org> #14804: hGetLine does not document whether newline is returned. -------------------------------------+------------------------------------- Reporter: akfp | Owner: gander Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gander): * owner: (none) => gander -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 10 08:03:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jun 2018 08:03:58 -0000 Subject: [GHC] #15249: Add support for cmpeq and cmpgt MMX intrinsics In-Reply-To: <047.176ece8eb8a34d6eb4b3724ae61ef561@haskell.org> References: <047.176ece8eb8a34d6eb4b3724ae61ef561@haskell.org> Message-ID: <062.21ca454135797ef0ce39a8822d3314e4@haskell.org> #15249: Add support for cmpeq and cmpgt MMX intrinsics -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: newhoggy Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: primops 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 newhoggy): * owner: (none) => newhoggy -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 10 10:12:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jun 2018 10:12:23 -0000 Subject: [GHC] #13452: Lock .tix file In-Reply-To: <045.e111ce23004cdc0b4740a146d49d8624@haskell.org> References: <045.e111ce23004cdc0b4740a146d49d8624@haskell.org> Message-ID: <060.d1a444f6a3b4ca750cc5e2a1d1317aab@haskell.org> #13452: Lock .tix file -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | 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 qrilka): Hi, any advice how this one could be attacked? As I understand file locking isn't a trivial thing to do in a cross-platform way -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 10 11:30:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jun 2018 11:30:51 -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.fc9d388273ef0c05e373286af3eeb811@haskell.org> #7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: abhir00p Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3557 | Differential Rev(s): Wiki Page: wiki:SIMD | -------------------------------------+------------------------------------- Changes (by abhir00p): * owner: (none) => abhir00p -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 10 11:47:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jun 2018 11:47:57 -0000 Subject: [GHC] #15180: Make Control.Exception.throw levity polymorphic In-Reply-To: <049.93e817224f99000e45e381c766dae62b@haskell.org> References: <049.93e817224f99000e45e381c766dae62b@haskell.org> Message-ID: <064.b95d1ec9bdeb2e72fafdc46cb9ead4e5@haskell.org> #15180: Make Control.Exception.throw levity polymorphic -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | LevityPolymorphism, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/typecheck/should_compile/T15180.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Ninjatrappeur): * testcase: => testsuite/tests/typecheck/should_compile/T15180.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 10 16:39:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jun 2018 16:39:27 -0000 Subject: [GHC] #14928: TH eats 50 GB memory when creating ADT with multiple constructors In-Reply-To: <047.b13a12d7e6e4b7703250170f5b54bd52@haskell.org> References: <047.b13a12d7e6e4b7703250170f5b54bd52@haskell.org> Message-ID: <062.41961a511280f7b02378ca8488c59813@haskell.org> #14928: TH eats 50 GB memory when creating ADT with multiple constructors -------------------------------------+------------------------------------- Reporter: YitzGale | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.2.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 Comment: Whoops, wrong milestone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 10 17:05:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jun 2018 17:05:56 -0000 Subject: [GHC] #15253: Add support for type-level integers Message-ID: <046.6a3a75cf7a5d8c09e1200183f66e2d14@haskell.org> #15253: Add support for type-level integers -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: compiler, | Operating System: Unknown/Multiple base | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Similar to GHC.TypeNats, it would be nice to see something like the following: {{{#!hs newtype TypeInt (n :: Nat) = TypeInt Integer class KnownInt (n :: k) where intSing :: TypeInt n intVal :: forall n proxy. KnownInt n => proxy n -> Integer intVal _ = case intSing :: TypeInt n of TypeInt x -> x intVal' :: forall n. KnownInt n => Proxy# n -> Integer intVal' _ = case intSing :: TypeInt n of TypeInt x -> x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 10 17:34:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jun 2018 17:34:54 -0000 Subject: [GHC] #15254: Cabal submodule bump is needed Message-ID: <057.64ddccb021aeada402151ae76dd6872d@haskell.org> #15254: Cabal submodule bump is needed -------------------------------------+------------------------------------- Reporter: | Owner: (none) quasicomputational | Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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 HEAD has recently been somewhat broken (https://github.com/haskell/cabal/issues/5318) and the current submodule is pointing to a buggy commit. This only manifests when installing `build- type: Custom` packages, because that uses the bad code from the bootstrap Cabal; `build-type: Simple` will use good code from the external `cabal- install` process. Please bump the Cabal submodule to fix this. I've verified that the observed problem (`happy` breaking) goes away when this is done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 10 20:40:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jun 2018 20:40:19 -0000 Subject: [GHC] #13452: Lock .tix file In-Reply-To: <045.e111ce23004cdc0b4740a146d49d8624@haskell.org> References: <045.e111ce23004cdc0b4740a146d49d8624@haskell.org> Message-ID: <060.2060ded875ce626f020b312528b9ae30@haskell.org> #13452: Lock .tix file -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | 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 bgamari): Indeed file locking is non-trivial, as our experiences with #13194 has taught us. If HPC records were written by Haskell code then we could simply piggy-back on the file locking interfaces in `base`. However, this isn't the case; `tix` files are written by the RTS. One option would be to change this, implementing the tix I/O bits in Haskell. Another would be to introduce file locking logic into the RTS. Regardless of how the locking itself will be implemented, the real question is how contention will be dealt with without either losing samples from one of the processes or causing one of the processes to block. It seems to me like this will likely require some refactoring of how TIX samples are read/accumulated/written; IIRC they are currently read by the RTS during startup, accumulated as the program runs, and written during shutdown. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 10 20:48:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jun 2018 20:48:21 -0000 Subject: [GHC] #15254: Cabal submodule bump is needed In-Reply-To: <057.64ddccb021aeada402151ae76dd6872d@haskell.org> References: <057.64ddccb021aeada402151ae76dd6872d@haskell.org> Message-ID: <072.ffabbad7725fbd3314988ef4102bbb19@haskell.org> #15254: Cabal submodule bump is needed -------------------------------------+------------------------------------- Reporter: | Owner: (none) quasicomputational | Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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 have also observed this error with HEAD. Related https://github.com/snowleopard/hadrian/issues/609#issuecomment-396080601 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 10 22:11:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jun 2018 22:11:19 -0000 Subject: [GHC] #15254: Cabal submodule bump is needed In-Reply-To: <057.64ddccb021aeada402151ae76dd6872d@haskell.org> References: <057.64ddccb021aeada402151ae76dd6872d@haskell.org> Message-ID: <072.1870ca0174b8791b24a9af8188c4062c@haskell.org> #15254: Cabal submodule bump is needed -------------------------------------+------------------------------------- Reporter: | Owner: (none) quasicomputational | Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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:"14f4347c28a2d8d45e795fd01bc0e547fe8738e6/ghc" 14f4347/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="14f4347c28a2d8d45e795fd01bc0e547fe8738e6" Bump Cabal submodule Fixes #15254. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 10 22:48:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jun 2018 22:48:42 -0000 Subject: [GHC] #15243: -ddump-splices shenanigans: promoted tycons aren't ticked In-Reply-To: <050.2f5ba7e519bdc8794c9c5f84999a9562@haskell.org> References: <050.2f5ba7e519bdc8794c9c5f84999a9562@haskell.org> Message-ID: <065.2b594e9fedf21cda081a754dc29630dd@haskell.org> #15243: -ddump-splices shenanigans: promoted tycons aren't ticked -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4809 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"96ddfa410e8b1294cf9e04cc05593fd981fa3014/ghc" 96ddfa4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="96ddfa410e8b1294cf9e04cc05593fd981fa3014" testsuite: Suppress uniques in T15243 output Fixes test for #15243. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 10 22:53:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jun 2018 22:53:05 -0000 Subject: [GHC] #15255: overflow1 breaks on i386 Message-ID: <046.ee165761a653c328cf797e94579d9139@haskell.org> #15255: overflow1 breaks on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 Integration | 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 i386 CircleCI target is showing a mysterious failure of the `overflow1` test: {{{ =====> overflow1(normal) 4082 of 6414 [0, 3, 0] Wrong exit code for overflow1(normal)(expected 251 , actual 0 ) *** unexpected failure for overflow1(normal) }}} Need to work out what is going on here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 10 22:55:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jun 2018 22:55:21 -0000 Subject: [GHC] #15230: unix tests fail under CircleCI's fedora environment In-Reply-To: <046.e75284c38f9e2e606bbb1d369702bf83@haskell.org> References: <046.e75284c38f9e2e606bbb1d369702bf83@haskell.org> Message-ID: <061.b1434c149fabc5abc700bba5fa6dfe04@haskell.org> #15230: unix tests fail under CircleCI's fedora environment -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 Integration | 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): We also have, {{{ --- ../../libraries/unix/tests/getGroupEntryForName.run/getGroupEntryForName.stderr.normalised 2018-06-10 17:08:41.871345982 +0000 +++ ../../libraries/unix/tests/getGroupEntryForName.run/getGroupEntryForName.run.stderr.normalised 2018-06-10 17:08:41.871345982 +0000 @@ -1 +1 @@ -getGroupEntryForName: getGroupEntryForName: does not exist (no such group) +getGroupEntryForName: getGroupEntryForName: does not exist (No such file or directory) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 10 23:12:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jun 2018 23:12:35 -0000 Subject: [GHC] #15115: `Numeric.showEFloat` does not honor precision with 0 digits In-Reply-To: <045.cd71602cfa60bbc0128fc78c2d018224@haskell.org> References: <045.cd71602cfa60bbc0128fc78c2d018224@haskell.org> Message-ID: <060.294cdf4068c9eddd907dcb68becc9cd3@haskell.org> #15115: `Numeric.showEFloat` does not honor precision with 0 digits -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: libraries/base | Version: 8.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | libraries/base/tests/Numeric/num008 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4665 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 10 23:14:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jun 2018 23:14:16 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.5b0b1b0a7597e369716efe236e61bfed@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | Phab:D4568 -------------------------------------+------------------------------------- Comment (by bgamari): What is the status of this, tdammers? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 10 23:17:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jun 2018 23:17:12 -0000 Subject: [GHC] #14815: -XStrict prevents code inlining. In-Reply-To: <046.08bab70ba7e4277e77ed3f217479b09d@haskell.org> References: <046.08bab70ba7e4277e77ed3f217479b09d@haskell.org> Message-ID: <061.7ec9efcf6e52352e00e68e640a99f56d@haskell.org> #14815: -XStrict prevents code inlining. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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:D4531 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 10 23:17:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jun 2018 23:17:22 -0000 Subject: [GHC] #14815: -XStrict prevents code inlining. In-Reply-To: <046.08bab70ba7e4277e77ed3f217479b09d@haskell.org> References: <046.08bab70ba7e4277e77ed3f217479b09d@haskell.org> Message-ID: <061.d22bab61682ae98e01bf76cb90c129f1@haskell.org> #14815: -XStrict prevents code inlining. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 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:D4531 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 10 23:19:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jun 2018 23:19:38 -0000 Subject: [GHC] #11798: Explicit recompilation required to change compilation options In-Reply-To: <047.6f8de8b3c85c4fc187e00a7d709c917e@haskell.org> References: <047.6f8de8b3c85c4fc187e00a7d709c917e@haskell.org> Message-ID: <062.af9221d7e02ac4b553a7dd44f53b4b67@haskell.org> #11798: Explicit recompilation required to change compilation options -------------------------------------+------------------------------------- Reporter: drathier | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.10.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:D3368 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: I believe this is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 10 23:22:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jun 2018 23:22:49 -0000 Subject: [GHC] #13896: Use response file to invoke hsc2hs In-Reply-To: <046.8d005e1593e32147d596c190fbabb716@haskell.org> References: <046.8d005e1593e32147d596c190fbabb716@haskell.org> Message-ID: <061.b749dfe2d06628b35c45cb17b8cd7f41@haskell.org> #13896: Use response file to invoke hsc2hs ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4612 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * owner: ckoparkar => (none) * status: patch => new Comment: It looks like all of the relevant PRs were merged. I think we still need to do the final step of using all of this new response file support in our invocation logic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 10 23:23:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jun 2018 23:23:24 -0000 Subject: [GHC] #13154: Standalone-derived anyclass instances aren't as permissive as empty instances In-Reply-To: <050.313c7572181a73220f1b076de5274da4@haskell.org> References: <050.313c7572181a73220f1b076de5274da4@haskell.org> Message-ID: <065.b1f67fb1845ba6e4d1971b9404d2fd47@haskell.org> #13154: Standalone-derived anyclass instances aren't as permissive as empty instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: deriving 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:D4337, Wiki Page: | Phab:D4370 -------------------------------------+------------------------------------- Changes (by bgamari): * owner: RyanGlScott => (none) * status: patch => new Comment: Is this now fixed, RyanGlScott? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 10 23:24:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Jun 2018 23:24:36 -0000 Subject: [GHC] #14945: Compiling error related to rts/Stats.c In-Reply-To: <049.d47fc57be745a9a5acfcc0d120241a39@haskell.org> References: <049.d47fc57be745a9a5acfcc0d120241a39@haskell.org> Message-ID: <064.8d3e8404f6c8c9c1873406d5831a5be9@haskell.org> #14945: Compiling error related to rts/Stats.c -------------------------------------+------------------------------------- Reporter: terrorjack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.5 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4536 Wiki Page: | Phab:D4529 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: I believe this is now fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 00:08:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 00:08:32 -0000 Subject: [GHC] #15253: Add support for type-level integers In-Reply-To: <046.6a3a75cf7a5d8c09e1200183f66e2d14@haskell.org> References: <046.6a3a75cf7a5d8c09e1200183f66e2d14@haskell.org> Message-ID: <061.8d9f35e4bbe94e40ef1e87f15589d57c@haskell.org> #15253: Add support for type-level integers -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: compiler, | base 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): We already have type-level `Nat`. Then you can emulate `Integer` by pairing a `Nat` with type-level `Bool` to hold the sign. Do you have a stronger use case than "it would be nice to see"? Ryan's comment to your previous request ticket:14922#comment:3 applies here as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 00:40:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 00:40:18 -0000 Subject: [GHC] #14994: ghc api: `load LoadAllTargets` is not idempotent In-Reply-To: <044.059168af26f269e453b3c36e5b5a0115@haskell.org> References: <044.059168af26f269e453b3c36e5b5a0115@haskell.org> Message-ID: <059.b11a7f53dfd70f6495cc67a830e7d541@haskell.org> #14994: ghc api: `load LoadAllTargets` is not idempotent -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: GHC API | Version: 8.4.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 int-index): I tried to tackle this and couldn't reproduce — I've run the compiled binary and it prints `42`. Also, I've had to add `import GHC` to compile. With a freshly built compiler, here are the steps I took. Installed `ghc-paths`: {{{ [nix-shell:~/Projects/ghc2]$ cabal install --with- compiler=`pwd`/inplace/bin/ghc-stage2 --package- db=`pwd`/inplace/lib/package.conf.d ghc-paths --allow-newer Resolving dependencies... Configuring ghc-paths-0.1.0.9... Building ghc-paths-0.1.0.9... Installed ghc-paths-0.1.0.9 }}} Tried to build: {{{ [nix-shell:~/Projects/ghc2]$ inplace/bin/ghc-stage2 T14994.hs [1 of 1] Compiling Main ( T14994.hs, T14994.o ) T14994.hs:19:13: error: Not in scope: ‘ghcMode’ | 19 | ghcMode = CompManager, | ^^^^^^^ T14994.hs:20:13: error: Not in scope: ‘hscTarget’ | 20 | hscTarget = HscInterpreted, | ^^^^^^^^^ T14994.hs:21:13: error: Not in scope: ‘ghcLink’ | 21 | ghcLink = LinkInMemory, | ^^^^^^^ T14994.hs:22:13: error: Not in scope: ‘verbosity’ | 22 | verbosity = 0 | ^^^^^^^^^ }}} Added `import GHC`, tried to build: {{{ [nix-shell:~/Projects/ghc2]$ inplace/bin/ghc-stage2 T14994.hs [1 of 1] Compiling Main ( T14994.hs, T14994.o ) T14994.hs:6:1: error: Could not find module ‘GHC’ It is a member of the hidden package ‘ghc-8.5’. You can run ‘:set -package ghc’ to expose it. (Note: this unloads all the modules in the current scope.) Use -v to see a list of the files searched for. }}} Modified the build command by adding `-package ghc`: {{{ [nix-shell:~/Projects/ghc2]$ inplace/bin/ghc-stage2 T14994.hs -package ghc [1 of 1] Compiling Main ( T14994.hs, T14994.o ) Linking T14994 ... }}} Running: {{{ [nix-shell:~/Projects/ghc2]$ ./T14994 42 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 01:18:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 01:18:20 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.3ce8b82f1d8bf7ca3aaa94ad125788f1@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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:D4783 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgillespie): Replying to [comment:27 Phyx-]: > I would change the first part to be more precise > > `Could not find module ‘Control.Monad.Random’` into something like `Could not load module ‘Control.Monad.Random’` since the message is a bit contradictory saying it couldn't find it yet it's part of a package it knows about. I toyed with this a bit, using "Could not load module" for hidden and unusable packages. It broke hundreds of tests, and I'm a bit uncomfortable with that. For that reason, I think it's best not to mess with that for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 02:39:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 02:39:01 -0000 Subject: [GHC] #15256: GHCi check .ghci permission on WSL(Linux on Windows) Message-ID: <047.f4695e8a690311dea2fc9d61f1dd8980@haskell.org> #15256: GHCi check .ghci permission on WSL(Linux on Windows) --------------------------------+------------------------------------- Reporter: yongjoon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: Other | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------- GHCi permission checking for .ghci conflicts with WSL(Linux on Windows) filesystem management. You can reproduce this problem from 8.2.2.~8.4.3 of GHC- WSL(https://launchpad.net/~hvr/+archive/ubuntu/ghc-wsl). I think GHCi of WSL would skip .ghci permission check. I used GHCi(WSL) on some Haskell project synced by cloud storage which is placed on Windows filesystem. However, when I try to load GHCi with .ghci config file, GHCI says it can't pass .ghci permission check. As you know, chmod on WSL may ignore your command about many of file on NTFS filesystem in WSL. WSL shows permission of some files on Windows filesystems like 777. Therefore, I think GHCi(WSL) may have an exceptional code not to check .ghci file as like as ghci warning message for MinTTY console. P.S. Is there any bug-report place only for GHC-WSL? I couldn't find it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 02:39:40 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 02:39:40 -0000 Subject: [GHC] #15256: GHCi check .ghci permission on WSL(Linux on Windows) In-Reply-To: <047.f4695e8a690311dea2fc9d61f1dd8980@haskell.org> References: <047.f4695e8a690311dea2fc9d61f1dd8980@haskell.org> Message-ID: <062.7fab499eef163364902eb4d6c5075d67@haskell.org> #15256: GHCi check .ghci permission on WSL(Linux on Windows) -------------------------------------+------------------------------ Reporter: yongjoon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.4 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Other Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Changes (by yongjoon): * milestone: 8.6.1 => 8.4.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 02:50:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 02:50:56 -0000 Subject: [GHC] #13896: Use response file to invoke hsc2hs In-Reply-To: <046.8d005e1593e32147d596c190fbabb716@haskell.org> References: <046.8d005e1593e32147d596c190fbabb716@haskell.org> Message-ID: <061.15e6bf065cdfea5947c1ff80d21070a9@haskell.org> #13896: Use response file to invoke hsc2hs ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4612 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by ckoparkar): Yes! I'll do that in the next couple days. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 04:58:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 04:58:58 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.6dbf90d5d36b9ae385cdb8ffa95c9bc9@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | Phab:D4568 -------------------------------------+------------------------------------- Comment (by tdammers): AFAICT, 2a5bdd9 fixes the original problem, and d92c755 fixes the regressions we caused. So I think we're done here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 08:30:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 08:30:42 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF In-Reply-To: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> References: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> Message-ID: <060.1fa56930389ce2c731dccf595cd2bc15@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): Phab:D4796 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > seq# is intentionally lazy in its argument, to allow explicit ordering in an IO context Hmnm. Can you give an example? Nothing in `seq#`'s documentation says that. It jolly well should! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 08:30:44 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 08:30:44 -0000 Subject: [GHC] #15257: Broken symlinks in lndir build tree Message-ID: <049.f0b63926608607176eb8bb749ef67790@haskell.org> #15257: Broken symlinks in lndir build tree -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.5 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: -------------------------------------+------------------------------------- I routinely create separate build trees using lndir (per wiki:WorkingConventions/Git#Creatingabuildtreewithlndir). However it seems this is currently broken by the code to copy `fs.{c,h}` to various places in `./configure` (see Phab:D4416): {{{ $ mkdir ghc-validate $ cd ghc-validate $ lndir ../ghc $ ln -s ../ghc/.git $ ./boot [...] $ ./configure [...] $ find . -name "fs.*" | xargs file ./rts/fs.c: broken symbolic link to ../../../ghc/utils/fs/fs.c ./rts/fs.h: broken symbolic link to ../../../ghc/utils/fs/fs.h ./utils/fs/fs.c: symbolic link to ../../../ghc/utils/fs/fs.c ./utils/fs/fs.h: symbolic link to ../../../ghc/utils/fs/fs.h ./utils/unlit/fs.c: symbolic link to ../../../ghc/utils/fs/fs.c ./utils/unlit/fs.h: symbolic link to ../../../ghc/utils/fs/fs.h ./utils/lndir/fs.c: symbolic link to ../../../ghc/utils/fs/fs.c ./utils/lndir/fs.h: symbolic link to ../../../ghc/utils/fs/fs.h ./libraries/base/include/fs.h: broken symbolic link to ../../../ghc/utils/fs/fs.h ./libraries/base/cbits/fs.c: broken symbolic link to ../../../ghc/utils/fs/fs.c }}} This can be fixed by manually correcting the symlinks, but it is a bit of pain, especially for `./validate`. {{{ ln -fs ../../ghc/utils/fs/fs.c rts/fs.c ln -fs ../../ghc/utils/fs/fs.h rts/fs.h ln -fs ../../../../ghc/utils/fs/fs.c libraries/base/include/fs.c ln -fs ../../../../ghc/utils/fs/fs.h libraries/base/include/fs.h ln -fs ../../../../ghc/utils/fs/fs.c libraries/base/cbits/fs.c }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 08:58:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 08:58:12 -0000 Subject: [GHC] #15254: Cabal submodule bump is needed In-Reply-To: <057.64ddccb021aeada402151ae76dd6872d@haskell.org> References: <057.64ddccb021aeada402151ae76dd6872d@haskell.org> Message-ID: <072.efa0fc3163502e2662a0f08cbe4a8594@haskell.org> #15254: Cabal submodule bump is needed -------------------------------------+------------------------------------- Reporter: | Owner: (none) quasicomputational | Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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 quasicomputational): * status: new => closed * resolution: => fixed Comment: Thanks! Sorry for the breakage. The random `getDirectoryContents` errors should all be cleaned up now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 09:04:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 09:04:59 -0000 Subject: [GHC] #10789: Notify user when a kind mismatch holds up a type family reduction In-Reply-To: <047.282dd8bb976bc76373d556a5e980ac6e@haskell.org> References: <047.282dd8bb976bc76373d556a5e980ac6e@haskell.org> Message-ID: <062.650823fd378acb4b93c0b36569d625c7@haskell.org> #10789: Notify user when a kind mismatch holds up a type family reduction -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomer, | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13192 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by v0d1ch): Hey @ckoparkar do you still work on this ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 09:17:23 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 09:17:23 -0000 Subject: [GHC] #15252: syn_arg_wraps and syn_res_wrap are only populated after typechecking In-Reply-To: <049.1a5ef24fb5e35afe5e2b66465a8d0d89@haskell.org> References: <049.1a5ef24fb5e35afe5e2b66465a8d0d89@haskell.org> Message-ID: <064.c2dc324bee6f2a06ed10d51486e3d52c@haskell.org> #15252: syn_arg_wraps and syn_res_wrap are only populated after typechecking -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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 simonpj): * cc: sh.najd@…, alan.zimm@… (added) Comment: Yes indeed. Cc'ing Alan and Shayan -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 09:25:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 09:25:37 -0000 Subject: [GHC] #15252: syn_arg_wraps and syn_res_wrap are only populated after typechecking In-Reply-To: <049.1a5ef24fb5e35afe5e2b66465a8d0d89@haskell.org> References: <049.1a5ef24fb5e35afe5e2b66465a8d0d89@haskell.org> Message-ID: <064.d1879fb7e12d1c29ab1b851738256795@haskell.org> #15252: syn_arg_wraps and syn_res_wrap are only populated after typechecking -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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 alanz): I am pretty sure I tried to do this on two different occasions without success, then left it as an after the fact cleanup. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 10:27:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 10:27:42 -0000 Subject: [GHC] #15149: Identical distinct type family fields miscompiled In-Reply-To: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> References: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> Message-ID: <066.6378aba6926d8a0ef045ad1e898d3d9c@haskell.org> #15149: Identical distinct type family fields miscompiled -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: adamgundry Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T15149 Blocked By: | Blocking: Related Tickets: #14747 | Differential Rev(s): Phab:D4821 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Moving field label resolution to the typechecker still might be worth doing, because it should get rid of quite a bit of duplication. But it's not a small task (e.g. because of dot-dot patterns) so I think it's worth pursuing the small fix first. I agree with this point, but we should still do it! Then we could get rid of `tcg_field_env` altogether, which would be very worthwhile. Maybe open a fresh ticket for it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 11:33:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 11:33:26 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.96a660f67bf6229e0483496b8545efa1@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.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 tdammers): I've done some more dumping. The situation can be traced back to the desugar phase at least. In all 4 test cases, I did the same thing: - start up `ghci` on the `Foo.hs` module, with `-fforce-recomp -ddump-ds -dsuppress-all`; adding `-fdefer-type-errors` or not depending on the test case. - depending on the test case, `:set -fno-defer-type-errors` or `-fdefer- type-errors` to override the command-line setting - evaluate `test` in `ghci` It turns out that the desugared output is almost entirely identical (save for mismatching Uniques), except for the final GHCI invocation of `test`. The desugared output for that is identical between the three cases that involve deferred type errors anywhere, but different for the case that doesn't defer type errors anywhere. To wit: With deferred type errors in either or both module compilation and interactive session: {{{ ==================== Desugared ==================== bindIO (let { $dShow_a1Rt $dShow_a1Rt = $fShowInt } in (\ @ a_a1Dg -> let { $dGHCiSandboxIO_a1Di $dGHCiSandboxIO_a1Di = $fGHCiSandboxIOIO } in ghciStepIO $dGHCiSandboxIO_a1Di) test) (\ it_a1CU -> thenIO (print $dShow_a1Rt it_a1CU) (returnIO (: (unsafeCoerce# it_a1CU) []))) }}} Without deferred type errors: {{{ ==================== Desugared ==================== let { $dShow_a1Rq $dShow_a1Rq = $fShowInt } in bindIO ((\ @ a_a1De -> let { $dGHCiSandboxIO_a1Dg $dGHCiSandboxIO_a1Dg = $fGHCiSandboxIOIO } in ghciStepIO $dGHCiSandboxIO_a1Dg) test) (\ it_a1CT -> thenIO (print $dShow_a1Rq it_a1CT) (returnIO (: (unsafeCoerce# it_a1CT) []))) }}} Ignoring uniques entirely, the only real difference is whether or not the `dShow...` binding is floated out. So the questions are: why does it get floated out when type errors are deferred; and how does that lead to GHC calling `nameModule` on the `dShow...` part. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 11:40:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 11:40:34 -0000 Subject: [GHC] #15258: Implement CMOV support. Message-ID: <047.e9fd16ce925ccd3a92fb9b02db12d4ac@haskell.org> #15258: Implement CMOV support. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: CodeGen | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | 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 Mon Jun 11 11:41:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 11:41:04 -0000 Subject: [GHC] #15258: Implement CMOV support. In-Reply-To: <047.e9fd16ce925ccd3a92fb9b02db12d4ac@haskell.org> References: <047.e9fd16ce925ccd3a92fb9b02db12d4ac@haskell.org> Message-ID: <062.4b3f1451533aaf3e015ed4976fefd36b@haskell.org> #15258: Implement CMOV support. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: CodeGen 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 AndreasK): * owner: (none) => AndreasK -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 12:15:10 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 12:15:10 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.cac82cdd528361e8ac5d339dee355a37@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.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 tdammers): But wait! The version with `-fdefer-type-errors` is actually horribly wrong, because `dShow_...` is used outside of the `let` binding that defines it! This cannot possibly work, can it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 13:48:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 13:48:12 -0000 Subject: [GHC] #13154: Standalone-derived anyclass instances aren't as permissive as empty instances In-Reply-To: <050.313c7572181a73220f1b076de5274da4@haskell.org> References: <050.313c7572181a73220f1b076de5274da4@haskell.org> Message-ID: <065.4f6f6502631b3b0ffc99b49140550123@haskell.org> #13154: Standalone-derived anyclass instances aren't as permissive as empty instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: deriving 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:D4337, Wiki Page: | Phab:D4370 -------------------------------------+------------------------------------- Comment (by RyanGlScott): No. There is a smattering of things that still aren't supported, which include (but may not be limited to): * Instances for bare type variables: {{{#!hs instance Foo a -- Works deriving anyclass instance Foo a -- Doesn't work }}} * Instances for type-level literals: {{{#!hs instance Bar 1 -- Works deriving anyclass instance Bar 2 -- Doesn't work }}} * Empty instances: {{{#!hs instance Baz -- Works deriving instance Baz -- Doesn't work }}} I have an idea of how to fix these, but haven't had the time to try it out yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 14:09:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 14:09:38 -0000 Subject: [GHC] #15136: High CPU when asynchronous exception and unblocking retry on TVar raced In-Reply-To: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> References: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> Message-ID: <062.bd86023bef39613042ca63b66953b41b@haskell.org> #15136: High CPU when asynchronous exception and unblocking retry on TVar raced -------------------------------------+------------------------------------- Reporter: nshimaza | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.2 Resolution: | Keywords: 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 carlostome): After some investigation I found that indeed there is a deadlock between the mutexes of a TSO and a TVar. An excerpt of the debugging log is the follwing: {{{ Task 2: cap 1: running thread 7012 (ThreadRunGHC) Task 2: STM: 0xad6d08 : stmStartTransaction with 316 tokens Task 2: STM: 0xad6d08 : stmStartTransaction()=0x4200224000 Task 2: STM: 0x4200224000 : stmWriteTVar(0x4200225c68, 0xad5e72) Task 2: STM: 0x4200224000 : get_entry_for TVar 0x4200225c68 Task 2: STM: 0x4200224000 : FOR_EACH_ENTRY, current_chunk=0x420027e4d0 limit=0 Task 2: STM: 0x4200224000 : read_current_value(0x4200225c68)=0xad5e69 Task 2: STM: 0x4200224000 : stmWriteTVar done Task 2: STM: 0x4200224000 : stmCommitTransaction() Task 2: STM: 0x4200224000 : lock_stm() Task 2: STM: 0x4200224000 : FOR_EACH_ENTRY, current_chunk=0x420027e4d0 limit=1 Task 2: STM: 0x4200224000 : trying to acquire 0x4200225c68 Task 2: STM: 0x4200224000 : cond_lock_tvar(0x4200225c68, 0xad5e69) -- (1) Task 2: STM: 0x4200224000 : success Task 2: STM: 0x4200224000 : doing read check Task 2: STM: 0x4200224000 : FOR_EACH_ENTRY, current_chunk=0x420027e4d0 limit=1 Task 2: STM: 0x4200224000 : read-check succeeded Task 2: STM: 0x4200224000 : FOR_EACH_ENTRY, current_chunk=0x420027e4d0 limit=1 Task 2: STM: 0x4200224000 : writing 0xad5e72 to 0x4200225c68, waking waiters -- (2) Task 2: STM: unpark_waiters_on tvar=0x4200225c68 Task 2: STM: unpark_waiters_on tvar=0x4200225c68, status=0x4200223b80 Task 2: STM: cap 1: unpark_waiters_on tvar=0x4200225c68, status2=0x4200223b80 -- (3) Task 2: STM: cap 1: unpark_tso id 6866 -- (4) Task 1: BlockedOnSTM: lockTSO id 6866 Task 1: cap 0 BlockedOnSTM: raiseAsync id 6866 Task 1: cap 0: raising exception in thread 6866. Task 1: cap 0: raiseAsync: freezing atomically frame -- (5) Task 1: STM: 0x4200225f58 : stmAbortTransaction -- (6) Task 1: STM: 0x4200225f58 : lock_stm() Task 1: STM: 0x4200225f58 : aborting top-level transaction cap 0 Task 1: STM: 0x4200225f58 : aborting top-level transaction Task 1: STM: 0x4200225f58 : stmAbortTransaction aborting waiting transaction Task 1: STM: 0x4200225f58 : remove_watch_queue_entries_for_trec() -- (7) Task 1: STM: 0x4200225f58 : FOR_EACH_ENTRY, current_chunk=0x4200223cc8 limit=1 Task 1: STM: 0x4200225f58 : lock_tvar (0x4200225c68) -- (8) }}} What is happening here has to do with how async exceptions are implemented. The thread 6866 is waiting on the TVar 0x4200225c68. In the meantime the thread 7012 is able to change the value of such TVar to True. To do so, first it has to acquire the lock for the TVar (1), then actually change its value (2), and finally wake any thread that was waiting on this TVar (3). To wake up a concrete waiter it needs to hold its mutex through lock_tso() (4). The problem is that when an async exception is thrown to a thread whose status is BlockedOnSTM, the first thing the thread throwing the exception does is to grab the mutex of the target thread with lock_tso() (https://github.com/ghc/ghc/blob/93220d46fceabf3afeae36f1fda94e1698c3639a/rts/RaiseAsync.c#L419), then because the target thread was in the middle of an STM transaction (5) that dependes on the same TVar, it has to abort it (6) for what it has to be removed from the TVar watch queue (7) needing the mutex on the TVar to do so (8). Basically the thread completing the STM grabs first the TVar lock and then the TSO lock while for the async exception the locks are taken in reverse order. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 14:16:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 14:16:37 -0000 Subject: [GHC] #15259: Out-of-scope-variables error still can be deferred in ghci Message-ID: <049.79f743e34e707788f506b428cc286905@haskell.org> #15259: Out-of-scope-variables error still can be deferred in ghci -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 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: -------------------------------------+------------------------------------- Deferring type errors is unhelpful in ghci, since the expression is evaluated immediately. In #11130, we disabled typed holes in ghci as well. The `-fdefer-out-of-scope-variables` should also be disabled in ghci. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 14:20:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 14:20:39 -0000 Subject: [GHC] #15199: Build fails on Debian armhf (armv7l-unknown-linux-gnueabihf) In-Reply-To: <044.81af1940b7343631708d21b21be1c899@haskell.org> References: <044.81af1940b7343631708d21b21be1c899@haskell.org> Message-ID: <059.d26d9214de9ae379284907e3c5dda68d@haskell.org> #15199: Build fails on Debian armhf (armv7l-unknown-linux-gnueabihf) ----------------------------------------+---------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.4.4 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+---------------------------------- Changes (by clint): * failure: None/Unknown => Building GHC failed * os: Unknown/Multiple => Linux * architecture: Unknown/Multiple => arm Comment: Related: https://ghc.haskell.org/trac/ghc/ticket/14261 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 14:21:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 14:21:11 -0000 Subject: [GHC] #14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: In-Reply-To: <045.3936f21bdd3848870db3bf9280c23e0a@haskell.org> References: <045.3936f21bdd3848870db3bf9280c23e0a@haskell.org> Message-ID: <060.90201d2ad404d7e644ae81fd9b8c02cb@haskell.org> #14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: -------------------------------------+------------------------------------- Reporter: slyfox | Owner: angerman Type: bug | Status: new Priority: normal | Milestone: 8.6.1 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 clint): Related: https://ghc.haskell.org/trac/ghc/ticket/15199 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 14:27:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 14:27:09 -0000 Subject: [GHC] #15259: Out-of-scope-variables error still can be deferred in ghci In-Reply-To: <049.79f743e34e707788f506b428cc286905@haskell.org> References: <049.79f743e34e707788f506b428cc286905@haskell.org> Message-ID: <064.fa36fc9951c12d79a19b370f12d3e596@haskell.org> #15259: Out-of-scope-variables error still can be deferred in ghci -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 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:D4830 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * status: new => patch * differential: => Phab:D4830 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 14:31:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 14:31:05 -0000 Subject: [GHC] #15136: High CPU when asynchronous exception and unblocking retry on TVar raced In-Reply-To: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> References: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> Message-ID: <062.255206d347c25cc80a6b252d0c120880@haskell.org> #15136: High CPU when asynchronous exception and unblocking retry on TVar raced -------------------------------------+------------------------------------- Reporter: nshimaza | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.2 Resolution: | Keywords: 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 carlostome): * cc: carlostome (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 15:29:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 15:29:20 -0000 Subject: [GHC] #15244: Ambiguity checks in QuantifiedConstraints In-Reply-To: <055.959d04c99ecee584bd91e5ef9b6544de@haskell.org> References: <055.959d04c99ecee584bd91e5ef9b6544de@haskell.org> Message-ID: <070.7844b07ecd9726825f595759a29f0753@haskell.org> #15244: Ambiguity checks in QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: bitwiseshiftleft | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints 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:"a169149ce80de3676adb3ece43d5164b6a875b9c/ghc" a169149c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a169149ce80de3676adb3ece43d5164b6a875b9c" Remove duplicate quantified constraints This is an easy fix for Trac #15244: just avoid adding the same quantified Given constraint to the inert set twice. See TcSMonad Note [Do not add duplicate quantified instances]. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 15:37:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 15:37:06 -0000 Subject: [GHC] #15237: New SRT scheme breaks -fvia-C In-Reply-To: <046.e3fad0365f09ac73a9b55199ebd3f969@haskell.org> References: <046.e3fad0365f09ac73a9b55199ebd3f969@haskell.org> Message-ID: <061.4b0a2302f7813a818bb015ae0b64060b@haskell.org> #15237: New SRT scheme breaks -fvia-C -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 15:38:28 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 15:38:28 -0000 Subject: [GHC] #15237: New SRT scheme breaks -fvia-C In-Reply-To: <046.e3fad0365f09ac73a9b55199ebd3f969@haskell.org> References: <046.e3fad0365f09ac73a9b55199ebd3f969@haskell.org> Message-ID: <061.cda2b35a7e9de790a3ab97ecb491d96f@haskell.org> #15237: New SRT scheme breaks -fvia-C -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 simonmar): Maybe we should just disable this optimisation for !TABLES_NEXT_TO_CODE. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 15:38:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 15:38:50 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.b9ea65fa1fbaf428aacd1d3761ef683c@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.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 code in `TcUnify` described in comment:8 is {{{ implicationNeeded skol_tvs given | null skol_tvs , null given = -- Empty skolems and givens do { tc_lvl <- getTcLevel ; if not (isTopTcLevel tc_lvl) -- No implication needed if we are then return False -- already inside an implication else do { dflags <- getDynFlags -- If any deferral can happen, -- we must build an implication ; return (gopt Opt_DeferTypeErrors dflags || gopt Opt_DeferTypedHoles dflags || gopt Opt_DeferOutOfScopeVariables dflags) } } }}} So you have to switch of all three of `Opt_DeferTypeErrors`, `Opt_DeferTypedHoles` and `Opt_DeferOutOfScopeVariables`. But NB that ''the first implies the other two''; so I guess that you need to switch all three of them off in the workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 15:51:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 15:51:45 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.6941214d9bf5728b3098941f4cc42090@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | Phab:D4568 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 15:56:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 15:56:38 -0000 Subject: [GHC] #15136: High CPU when asynchronous exception and unblocking retry on TVar raced In-Reply-To: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> References: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> Message-ID: <062.f3fd479d931d16515e7cd51294440a91@haskell.org> #15136: High CPU when asynchronous exception and unblocking retry on TVar raced -------------------------------------+------------------------------------- Reporter: nshimaza | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.2 Resolution: | Keywords: 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 simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 16:00:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 16:00:27 -0000 Subject: [GHC] #15176: Superclass `Monad m =>` makes program run 100 times slower In-Reply-To: <046.1ae5a16457a25527a576b82200e29a09@haskell.org> References: <046.1ae5a16457a25527a576b82200e29a09@haskell.org> Message-ID: <061.a66491a46aa6992cf7b9eb73bf90b212@haskell.org> #15176: Superclass `Monad m =>` makes program run 100 times slower -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): * owner: (none) => bgamari Comment: I will try to do a bit of characterisation of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 16:01:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 16:01:36 -0000 Subject: [GHC] #15244: Ambiguity checks in QuantifiedConstraints In-Reply-To: <055.959d04c99ecee584bd91e5ef9b6544de@haskell.org> References: <055.959d04c99ecee584bd91e5ef9b6544de@haskell.org> Message-ID: <070.b09aa307b5813e083c55f51a2503fcbd@haskell.org> #15244: Ambiguity checks in QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: bitwiseshiftleft | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/quantified- | constraints/T15244 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => testsuite/tests/quantified-constraints/T15244 * resolution: => fixed Comment: I fixed this! The fix will be in 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 16:10:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 16:10:59 -0000 Subject: [GHC] #15260: Xmobar crashes with segmentation fault Message-ID: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> #15260: Xmobar crashes with segmentation fault --------------------------------------+---------------------------------- Reporter: Voronwe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- OS: Arch Kernel version: 4.16.13-2-ARCH Xmobar version: 0.26 ghc version: 8.4.3 Xmobar crashes after some time (1 sec or 1 day - very different each time). And, as I see, reasons are different to: 1: {{{ voronwe at sul ~> xmobar Fields missing from config defaulted: additionalFonts,wmClass,wmName,border,borderColor,textOffset,iconOffset,iconRoot,alpha xmobar: internal error: evacuate: strange closure type 4689 (GHC version 8.4.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug fish: 'xmobar' terminated by signal SIGABRT (Abort) }}} 2: {{{ voronwe at sul ~> xmobar Fields missing from config defaulted: additionalFonts,wmClass,wmName,border,borderColor,textOffset,iconOffset,iconRoot,alpha fish: 'xmobar' terminated by signal SIGSEGV (Address boundary error) }}} See my issue on xmobar github for details: https://github.com/jaor/xmobar/issues/354 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 16:15:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 16:15:08 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF In-Reply-To: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> References: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> Message-ID: <060.658dc855aaab25e66997a7694374d365@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | perf/should_run/T15226, 15226a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4796 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => perf/should_run/T15226, 15226a Comment: I believe this is a follow-up patch {{{ commit 502026fc0a35460c7f04b26a11320723a7bbfdff Author: David Feuer Date: Mon Jun 11 10:32:23 2018 -0400 Make seq# evaluatedness look through casts In d964b05, I forgot to look through casts to find the `seq#` identifier. Fix that. Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4804 >--------------------------------------------------------------- 502026fc0a35460c7f04b26a11320723a7bbfdff compiler/coreSyn/CoreSyn.hs | 3 ++- testsuite/tests/perf/should_run/{T15226.hs => T15226a.hs} | 5 ++++- testsuite/tests/perf/should_run/all.T | 9 +++++++++ 3 files changed, 15 insertions(+), 2 deletions(-) diff --git a/compiler/coreSyn/CoreSyn.hs b/compiler/coreSyn/CoreSyn.hs index 4dd70b0..50e40d1 100644 --- a/compiler/coreSyn/CoreSyn.hs +++ b/compiler/coreSyn/CoreSyn.hs @@ -2046,10 +2046,11 @@ collectArgs expr go e as = (e, as) -- | Attempt to remove the last N arguments of a function call. --- Strip off any ticks encountered along the way and any ticks +-- Strip off any ticks or coercions encountered along the way and any -- at the end. stripNArgs :: Word -> Expr a -> Maybe (Expr a) stripNArgs !n (Tick _ e) = stripNArgs n e +stripNArgs n (Cast f _) = stripNArgs n f stripNArgs 0 e = Just e stripNArgs n (App f _) = stripNArgs (n - 1) f stripNArgs _ _ = Nothing diff --git a/testsuite/tests/perf/should_run/T15226.hs b/testsuite/tests/perf/should_run/T15226a.hs similarity index 89% copy from testsuite/tests/perf/should_run/T15226.hs copy to testsuite/tests/perf/should_run/T15226a.hs index 4c09114..6e9a1db 100644 --- a/testsuite/tests/perf/should_run/T15226.hs +++ b/testsuite/tests/perf/should_run/T15226a.hs @@ -3,6 +3,7 @@ import Control.Exception (evaluate) -- Just in case Prelude.repeat changes for some reason. import Prelude hiding (repeat) +import Data.Coerce -- We want to be sure that the compiler *doesn't* know that -- all the elements of the list are in WHNF, because if it @@ -12,11 +13,13 @@ repeat a = res where res = a : res {-# NOINLINE repeat #-} -- Belt *and* suspenders +newtype Foo = Foo Int + silly :: [Int] -> IO () silly = foldr go (pure ()) where go x r = do - x' <- evaluate x + x' <- (coerce (evaluate :: Foo -> IO Foo) :: Int -> IO Int) x evaluate (x' + 3) -- GHC should know that x' has been evaluated, -- so this calculation will be erased entirely. -- Otherwise, we'll create a thunk to pass to diff --git a/testsuite/tests/perf/should_run/all.T b/testsuite/tests/perf/should_run/all.T index b248dd5..0e7996ef 100644 --- a/testsuite/tests/perf/should_run/all.T +++ b/testsuite/tests/perf/should_run/all.T @@ -584,3 +584,12 @@ test('T15226', only_ways(['normal'])], compile_and_run, ['-O']) + +test('T15226a', + [stats_num_field('bytes allocated', + [ (wordsize(64), 41040, 5) ]), + # 2018-06-06 41040 Look through casts for seq# + # initial 400041040 + only_ways(['normal'])], + compile_and_run, + ['-O']) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 16:39:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 16:39:36 -0000 Subject: [GHC] #15260: Xmobar crashes with segmentation fault In-Reply-To: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> References: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> Message-ID: <061.24cf076f2210b6f9ac2fca5529b91fcf@haskell.org> #15260: Xmobar crashes with segmentation fault ----------------------------------+-------------------------------------- Reporter: Voronwe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by osa1): Thanks for reporting. I tried running `xmobar` with your config but couldn't reproduce this (Ubuntu 18.04, x86_64). Could you try running xmobar using the debug runtime with sanity checks enabled and tell us if you get a different error? Add `-rtsopts -debug` to `ghc-options` in `xmobar.cabal`, and then run `xmobar` as `xmobar +RTS -DS`. To make sure you're running with the expected runtime check `xmobar +RTS --info`, the `RTS way` should be `rts_debug`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 16:53:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 16:53:14 -0000 Subject: [GHC] #15261: Show -with-rtsopts options in runtime's --info Message-ID: <043.f2c7fda7e5ce90f13c2733f909af5e70@haskell.org> #15261: Show -with-rtsopts options in runtime's --info -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 far as I know currently we don't have a way to show `-with-rtsopts` options provided when compiling an executable. It'd be useful if `--info` showed this. Some use cases: - When you have multiple binaries of the same program you can see how each one is compiled. Useful when debugging. - Sometimes we instruct users saying "compile with this and run with that". This steps becomes easier with `-with-rtsopts` because with that the user doesn't have to pass runtime parameters. But currently we don't have an easy way check if the users did it right. If `+RTS --info` showed this information we could say "look at the info, you should see this and that". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 17:03:44 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 17:03:44 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.7017c9508a977219922278c5d159ab68@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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:D4783 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): It's quite common to have to update test outputs when you change user visible messages. I'd be more surprised if you didn't have to. In any case, will change it later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 18:39:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 18:39:25 -0000 Subject: [GHC] #15262: TH splice containing numeric literal 0 causes heap overflow while cross-compiling Message-ID: <050.8f7705015e16ef64b51a5dbaaaac982c@haskell.org> #15262: TH splice containing numeric literal 0 causes heap overflow while cross- compiling -------------------------------------+------------------------------------- Reporter: howtonotwin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Tested off commit `9976bed24dda9449ac2e3e95fb4bf8b379114a28`, running on macOS 10.13.5, trying to compile for iOS. 1. Compile a GHC that cross compiles to `x86_64-apple-ios` (i.e. with `./configure --build=x86_64-apple-darwin --host=x86_64-apple-darwin --target=x86_64-apple-ios; make`). 2. Compile a `ghc-iserv` that can run on the build system (i.e. with `./configure; cd utils/iserv; make`) 3. Try to cross-compile the following file (i.e `x86_64-apple-ios-ghc -fexternal-interpreter -pgmi=path/to/ghc-iserv T.hs`): {{{#!hs {-# LANGUAGE TemplateHaskell #-} module T where $([d| zero = 0 |]) }}} Expected: Compiles fine. Actual: {{{ [1 of 1] Compiling T ( T.hs, T.o ) T.hs:1:1: error: Exception when trying to run compile-time code: heap overflow Code: [d| zero = 0 |] | 1 | {-# LANGUAGE TemplateHaskell #-} | ^ }}} For more fun: * This problem appears to only affect the numeric literal `0`. * `0.0` is not fine. * `1` is fine. * `1 - 1` appears to be a workaround. * `0.1` is fine. * "Burying" the `0` inside another expression is not fine (e.g. `zero = [0]`). * I can even compile most of `singletons`, and it only chokes when the `0` literal first appears (`negate x = 0 - x`). * The `0` has to actually appear in the result. (`$(const [d| |] [d| zero = 0 |])` is fine.) * `0#` is not fine. * This problem only appears when cross-compiling. If I complete the build of the native GHC above and use it instead of the cross-compiler but still use `-fexternal-interpreter`, everything is fine. * Moving the declaration outside of the TH brackets is fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 19:06:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 19:06:03 -0000 Subject: [GHC] #15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7 In-Reply-To: <048.2e4683ede5797175b196c3bdda927d9f@haskell.org> References: <048.2e4683ede5797175b196c3bdda927d9f@haskell.org> Message-ID: <063.13dd62ce673644f0d479c64b03cd9081@haskell.org> #15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7 -------------------------------------+------------------------------------- Reporter: ki11men0w | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Thanks for the report, can you get me a crash dump? using gdb (install-able via pacman -Sy mingw-w64-i686-gdb) {{{ gdb --args ./ghc-pkg.exe --version run gcore }}} and using procdump https://docs.microsoft.com/en- us/sysinternals/downloads/procdump `procdump.exe -t -ma -e 1 -x . ./ghc-pkg.exe --version` Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 19:22:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 19:22:01 -0000 Subject: [GHC] #15260: Xmobar crashes with segmentation fault In-Reply-To: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> References: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> Message-ID: <061.89ad70d2823a9a8c53e852ae2e66b4e4@haskell.org> #15260: Xmobar crashes with segmentation fault ----------------------------------+-------------------------------------- Reporter: Voronwe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by osa1): With the help of other users I managed to get a backtrace. More details are in the [https://github.com/jaor/xmobar/issues/354#issuecomment-396356426 Github thread]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 19:26:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 19:26:01 -0000 Subject: [GHC] #15260: Xmobar crashes with segmentation fault In-Reply-To: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> References: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> Message-ID: <061.9a61852f985d5f15460f6baf1692eadb@haskell.org> #15260: Xmobar crashes with segmentation fault ----------------------------------+-------------------------------------- Reporter: Voronwe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by osa1): * version: 8.4.3 => 8.5 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 19:26:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 19:26:13 -0000 Subject: [GHC] #15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7 In-Reply-To: <048.2e4683ede5797175b196c3bdda927d9f@haskell.org> References: <048.2e4683ede5797175b196c3bdda927d9f@haskell.org> Message-ID: <063.8c7cc101f4a4a397e0ca700e426218fb@haskell.org> #15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7 -------------------------------------+------------------------------------- Reporter: ki11men0w | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: ghc-pkg | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: Phyx- (added) * priority: normal => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 20:45:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 20:45:22 -0000 Subject: [GHC] #15263: Fuse zipWith3 Message-ID: <047.9d2de90ae6f11d155cd01f5a30989bf4@haskell.org> #15263: Fuse zipWith3 -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- I was surprised to discover that `zipWith3` has no `RULES` associated with it to aid fusion. Can we add these? I have no idea what I'm doing, but would this substitution work: {{{ {-# RULES "zipWith3" zipWith3 f a b c = zipWith id (zipWith f a b) c #-} }}} Those who know what they're doing will likely devise a better strategy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 20:54:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 20:54:58 -0000 Subject: [GHC] #15237: New SRT scheme breaks -fvia-C In-Reply-To: <046.e3fad0365f09ac73a9b55199ebd3f969@haskell.org> References: <046.e3fad0365f09ac73a9b55199ebd3f969@haskell.org> Message-ID: <061.89bbbc8cf6d2d756ee338fd09d19a62f@haskell.org> #15237: New SRT scheme breaks -fvia-C -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): Yes, I think that would be the easiest way forward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 21:10:28 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 21:10:28 -0000 Subject: [GHC] #15263: Fuse zipWith3 In-Reply-To: <047.9d2de90ae6f11d155cd01f5a30989bf4@haskell.org> References: <047.9d2de90ae6f11d155cd01f5a30989bf4@haskell.org> Message-ID: <062.ff7f4fd1fed13327adddbc2a779b879c@haskell.org> #15263: Fuse zipWith3 -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 mpickering): If you are going to do that, you might as well define `zipWith3` in that way to begin with? In fact, defining `zipWith3` in this way and adding an `INLINE` pragma causes it to fuse nicely with map. My example program and the resulting core here - https://gist.github.com/mpickering/c190fc25260a3460f4633d0248659192 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 21:12:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 21:12:37 -0000 Subject: [GHC] #15263: Fuse zipWith3 In-Reply-To: <047.9d2de90ae6f11d155cd01f5a30989bf4@haskell.org> References: <047.9d2de90ae6f11d155cd01f5a30989bf4@haskell.org> Message-ID: <062.a0f0dcaabc6a233d73e6c95f8da8cd53@haskell.org> #15263: Fuse zipWith3 -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 goldfire): I noticed that `zipWith` itself has an explicit recursive definition, even though the rule right below it universally applies and zaps it to a `build` expression. I do not know the implications of these different implementation choices. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 11 23:15:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Jun 2018 23:15:47 -0000 Subject: [GHC] #10789: Notify user when a kind mismatch holds up a type family reduction In-Reply-To: <047.282dd8bb976bc76373d556a5e980ac6e@haskell.org> References: <047.282dd8bb976bc76373d556a5e980ac6e@haskell.org> Message-ID: <062.1454b6608dc23f7646f578f3ab246981@haskell.org> #10789: Notify user when a kind mismatch holds up a type family reduction -------------------------------------+------------------------------------- Reporter: goldfire | Owner: v0d1ch Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomer, | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13192 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by v0d1ch): * owner: (none) => v0d1ch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 02:32:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 02:32:08 -0000 Subject: [GHC] #15264: Warn about implicit kind variables with -Wcompat Message-ID: <048.2758c96021df3e03a2c44fb779b75b19@haskell.org> #15264: Warn about implicit kind variables with -Wcompat -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- According to an accepted proposal https://github.com/ghc-proposals/ghc- proposals/blob/master/proposals/0024-no-kind-vars.rst: With `-Wcompat`, warn if a kind variable is brought into scope implicitly in a type with an explicit `forall`. This applies to type signatures and to other contexts that allow a `forall` with the forall-or- nothing rule in effect (for example, class instances). Creating ticket just for the record. Implementation coming soon. Setting priority as high because if the warning doesn't make it into the release, the actual change will have to be delayed by another half a year. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 02:37:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 02:37:36 -0000 Subject: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened In-Reply-To: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> References: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> Message-ID: <061.5b8cf71c26b6ba8deca57814a8b6b64b@haskell.org> #15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | TypeCheckerPlugins 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 nfrisby): That way of saying it clarifies the expectations for me. And doesn't seem too burdensome for the plugin author. Thus I think this ticket could be resolved by updating the documentation. (Though I still would like for a plugin to be able to request the flattened Wanteds. Separate ticket?) In particular this sentence in the User Guide "[The plugin] will be invoked at two points in the constraint solving process: after simplification of given constraints, and after unflattening of wanted constraints." would benefit from some elaboration. Specifically, "unflattening of wanted constraints" is somewhat ambiguous: until you spelled it out, I was thinking that if a constraint is flattened, it doesn't have any flattening variables in it. However, I'm inferring here that the jargon is used to mean that "unflattening a wanted constraint" only eliminates fmvs, possibly leaving fsks behind? That's what I've been confused about (until now, I think). Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 02:51:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 02:51:59 -0000 Subject: [GHC] #15264: Warn about implicit kind variables with -Wcompat In-Reply-To: <048.2758c96021df3e03a2c44fb779b75b19@haskell.org> References: <048.2758c96021df3e03a2c44fb779b75b19@haskell.org> Message-ID: <063.72d7e09604f9b99c29df632409a567f5@haskell.org> #15264: Warn about implicit kind variables with -Wcompat -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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 goldfire): Missing the 8.6 window with this doesn't change the release time for the rest of that patch. By all means try to get this one in, but there's no fire here -- we have no formal contract with users about `-Wcompat`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 02:54:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 02:54:39 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.632211dc3e203686e4d902de2a0f0e12@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | 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): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): As a follow-on to comment:8: even with homogeneous equality, coercions will still be heterogeneous, and thus the need for a coherence coercion (of some form) will remain. The type of `~#` becomes homogeneous, but that affects only what coercions we can quantify over, not what ones we can form. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 02:58:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 02:58:33 -0000 Subject: [GHC] #15245: Data family promotion is possible In-Reply-To: <048.2bfd93318ecc0fe9c70183281e7bf50f@haskell.org> References: <048.2bfd93318ecc0fe9c70183281e7bf50f@haskell.org> Message-ID: <063.19093d1ce136fd8dbfcee04c8d7f2867@haskell.org> #15245: Data family promotion is possible -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 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): According to [https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Internal#User- facingdesignissues these mutterings], we need to abstract over a coercion to promote data family instances properly. I haven't paged it all back in, but this is an implementation error, not a documentation one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 03:01:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 03:01:29 -0000 Subject: [GHC] #15264: Warn about implicit kind variables with -Wcompat In-Reply-To: <048.2758c96021df3e03a2c44fb779b75b19@haskell.org> References: <048.2758c96021df3e03a2c44fb779b75b19@haskell.org> Message-ID: <063.f402589eeac5f4bf68942e51dcd72913@haskell.org> #15264: Warn about implicit kind variables with -Wcompat -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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 int-index): * priority: high => normal Old description: > According to an accepted proposal https://github.com/ghc-proposals/ghc- > proposals/blob/master/proposals/0024-no-kind-vars.rst: > > With `-Wcompat`, warn if a kind variable is brought into scope > implicitly in a type with an explicit `forall`. This applies to type > signatures and to other contexts that allow a `forall` with the forall- > or-nothing rule in effect (for example, class instances). > > Creating ticket just for the record. Implementation coming soon. Setting > priority as high because if the warning doesn't make it into the release, > the actual change will have to be delayed by another half a year. New description: According to an accepted proposal https://github.com/ghc-proposals/ghc- proposals/blob/master/proposals/0024-no-kind-vars.rst: With `-Wcompat`, warn if a kind variable is brought into scope implicitly in a type with an explicit `forall`. This applies to type signatures and to other contexts that allow a `forall` with the forall-or- nothing rule in effect (for example, class instances). Creating ticket just for the record. Implementation coming soon. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 03:44:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 03:44:39 -0000 Subject: [GHC] #15242: Typechecker sometimes doesn't preserve HsPar in original source. In-Reply-To: <045.8e7aac9da580012b12f85623927a4ba7@haskell.org> References: <045.8e7aac9da580012b12f85623927a4ba7@haskell.org> Message-ID: <060.bccbc977a89cf4c66e12374a58a4e689@haskell.org> #15242: Typechecker sometimes doesn't preserve HsPar in original source. -------------------------------------+------------------------------------- Reporter: wz1000 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: T15242 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4822 Wiki Page: | -------------------------------------+------------------------------------- Changes (by wz1000): * status: new => patch * testcase: => T15242 * differential: => D4822 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 03:48:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 03:48:29 -0000 Subject: [GHC] #15235: GHCi's claim of infixr 0 (->) is a lie In-Reply-To: <050.1dea13c2dffcf4fb3726d468418c6455@haskell.org> References: <050.1dea13c2dffcf4fb3726d468418c6455@haskell.org> Message-ID: <065.3fd3ebde35fff49d257f8e9394e2e084@haskell.org> #15235: GHCi's claim of infixr 0 (->) is a lie -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 goldfire): I've been bitten by this before. I'm worried about breakage with option (2), so I favor option (1), even if negative fixities are not available to users. While we're in town, it should be `infixr (-1) ->`, without parentheses/backticks around the arrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 03:52:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 03:52:33 -0000 Subject: [GHC] #15220: ScopedTypeVariables binds a non-existent variable In-Reply-To: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> References: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> Message-ID: <062.6f84b433bff7dffe6a4d1374e1dd13ba@haskell.org> #15220: ScopedTypeVariables binds a non-existent variable -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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, I suppose so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 03:53:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 03:53:09 -0000 Subject: [GHC] #15220: ScopedTypeVariables binds a non-existent variable In-Reply-To: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> References: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> Message-ID: <062.cc92644f90db9323d3cf963cf80f70b1@haskell.org> #15220: ScopedTypeVariables binds a non-existent variable -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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): But I still think it would be very strange if `zonkTcTypeToType` ever zonked a `SigTv` to `Any`. Could that happen another way? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 05:52:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 05:52:13 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation In-Reply-To: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> References: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> Message-ID: <060.70fad9974b31d2532bb15621953744e0@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: stm 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 WrenThornton): While not necessarily a solution to the problems with `TQueue` itself, users running into issues with overactive writers can always use stm- chans's `TBMQueue` which is a bounded (and closable) variant of `TQueue` which has already been vetted by various folks. (Though of course if folks find infelicities with the current implementation, I'm always open to receive patches and bugreports.) On the whole, from my experience in this domain, it's too much to expect a single implementation to satisfy all users' needs. Things like realtime queues certainly have their place, as do bare-bones queues, and explicitly bounded queues, as do queues where popping is forever and the element gets dropped on the floor in the event of transaction rollback, and so on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 07:24:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 07:24:27 -0000 Subject: [GHC] #15220: ScopedTypeVariables binds a non-existent variable In-Reply-To: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> References: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> Message-ID: <062.cc03b6e20264494e371806d0662bd7a5@haskell.org> #15220: ScopedTypeVariables binds a non-existent variable -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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): > But I still think it would be very strange if zonkTcTypeToType ever zonked a SigTv to Any. I don't understand the question. In the example, `b` will not stand for a `SigTv` any more -- it'll stand for a `TauTv`, which can get unified with anything. I suppose we'll have to look at any remaining uses of `SigTv`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 08:16:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 08:16:44 -0000 Subject: [GHC] #15242: Typechecker sometimes doesn't preserve HsPar in original source. In-Reply-To: <045.8e7aac9da580012b12f85623927a4ba7@haskell.org> References: <045.8e7aac9da580012b12f85623927a4ba7@haskell.org> Message-ID: <060.0c32ac2036b49d8b017b34469210583d@haskell.org> #15242: Typechecker sometimes doesn't preserve HsPar in original source. -------------------------------------+------------------------------------- Reporter: wz1000 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: T15242 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4822 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * differential: D4822 => Phab:D4822 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 08:39:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 08:39:26 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.d3ab83e510c2a36816a74b06802b09ac@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.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 tdammers): OK, disabling all three does indeed "fix" it. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 10:18:25 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 10:18:25 -0000 Subject: [GHC] #15235: GHCi's claim of infixr 0 (->) is a lie In-Reply-To: <050.1dea13c2dffcf4fb3726d468418c6455@haskell.org> References: <050.1dea13c2dffcf4fb3726d468418c6455@haskell.org> Message-ID: <065.aad7296d0490431c503241ae67138af1@haskell.org> #15235: GHCi's claim of infixr 0 (->) is a lie -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15236 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15236 Comment: Replying to [comment:1 goldfire]: > I'm worried about breakage with option (2), so I favor option (1), even if negative fixities are not available to users. Sounds good to me. > While we're in town, it should be `infixr (-1) ->`, without parentheses/backticks around the arrow. This was done separately in #15236. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 10:46:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 10:46:28 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.3973767801b097f92bd2a3e8fb36a1cb@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: patch Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/should_run/T14963 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4833 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * testcase: => ghci/should_run/T14963 * status: new => patch * differential: => D4833 Comment: I have put up a patch (https://phabricator.haskell.org/D4833), however it turns out that while disabling these three flags for interactive statements avoids the panic, it also seems to break a number of other tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 11:57:51 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 11:57:51 -0000 Subject: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened In-Reply-To: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> References: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> Message-ID: <061.7d67ab3eb852cb221d9b7784e60bd08f@haskell.org> #15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | TypeCheckerPlugins 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): To me it seems odd that we unflatten the Wanted `CFunEqCans` but not the Given ones. Indeed, it's not entirely clear how you can decide if a type- function call is in which class. '''So perhaps it'd be more consistent to do no un-flattening whatsoever?''' (The alternative, of unflattening everything, is not easy to implement.) Since the plugins have to deal with flattened Givens, it's probably no harder to deal with unflattened Wanteds too. I'd be interested in opinions. Meanwhile, would you like to suggest concrete alternative wording for the user manual? I can fill in the blanks if you have any. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 14:06:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 14:06:57 -0000 Subject: [GHC] #15265: Print result summary in test suite when interrupted Message-ID: <043.f6136d5e515deaf3f2a252d8637b12b1@haskell.org> #15265: Print result summary in test suite when interrupted -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Test Suite | Version: 8.5 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'd be helpful if the test runner showed summary of the tests run so far when it's interrupted. This is useful when working on new features: I sometimes run the test suite only to realize something's broken and I'm getting lots of failures. At this point no need to wait until it completes so I interrupt the process, but this doesn't print the summary of the tests run so far, so I have to use terminal scrollback and manually list failing tests etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 15:04:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 15:04:21 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.1a0704762493c651a26a38b3dba8d8ff@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: patch Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/should_run/T14963 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4833 D4830 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * differential: D4833 => D4833 D4830 Comment: D4830 looks like a cleaner solution than D4833; suggest we run with the former. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 15:08:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 15:08:57 -0000 Subject: [GHC] #15259: Out-of-scope-variables error still can be deferred in ghci In-Reply-To: <049.79f743e34e707788f506b428cc286905@haskell.org> References: <049.79f743e34e707788f506b428cc286905@haskell.org> Message-ID: <064.fc0924e1118eb8596254609eb1b31ec3@haskell.org> #15259: Out-of-scope-variables error still can be deferred in ghci -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14963 | Differential Rev(s): Phab:D4830 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * cc: tdammers (added) * related: => #14963 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 15:09:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 15:09:46 -0000 Subject: [GHC] #15259: Out-of-scope-variables error still can be deferred in ghci In-Reply-To: <049.79f743e34e707788f506b428cc286905@haskell.org> References: <049.79f743e34e707788f506b428cc286905@haskell.org> Message-ID: <064.1aa8dc3544cbcb371d5153693e703668@haskell.org> #15259: Out-of-scope-variables error still can be deferred in ghci -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: tdammers Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14963 | Differential Rev(s): Phab:D4830 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * owner: (none) => tdammers -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 15:11:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 15:11:23 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.f2ddd1e6d144c1f0461bac89d7ab9779@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: patch Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/should_run/T14963 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4833 Wiki Page: | Phab:D4830 -------------------------------------+------------------------------------- Changes (by sighingnow): * differential: D4833 D4830 => Phab:D4833 Phab:D4830 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 16:40:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 16:40:10 -0000 Subject: [GHC] #11350: Allow visible type application in patterns In-Reply-To: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> References: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> Message-ID: <066.ec663d40518dd2281de12d8acb6c611c@haskell.org> #11350: Allow visible type application in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11385, #13159, | Differential Rev(s): #13158 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): = Paper 'Type variables in patterns' references this * [https://arxiv.org/pdf/1806.03476.pdf pdf] * [https://arxiv.org/abs/1806.03476 arXiv.org] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 16:42:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 16:42:41 -0000 Subject: [GHC] #2731: Avoid unnecessary evaluation when unpacking constructors In-Reply-To: <046.faa1da08abfada8ee02e462f3ba3c08c@haskell.org> References: <046.faa1da08abfada8ee02e462f3ba3c08c@haskell.org> Message-ID: <061.5e99f9a8ead726bd109564b1cab83c9c@haskell.org> #2731: Avoid unnecessary evaluation when unpacking constructors -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.5 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 AndreasK): * version: 6.8.3 => 8.5 Comment: If anyone wonders this is still the case in GHC-8.4 / HEAD. Changing the type of `T` to `data T = MkT !(Bool,Bool)` also doesn't change anything. Cmm Code. {{{ {offset c1pY: if ((Sp + -8) < SpLim) (likely: False) goto c1q2; else goto c1q3; c1q2: R2 = R2; R1 = foo_closure; call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8; c1q3: I64[Sp - 8] = c1pV; R1 = R2; Sp = Sp - 8; if (R1 & 7 != 0) goto c1pV; else goto c1pW; c1pW: call (I64[R1])(R1) returns to c1pV, args: 8, res: 8, upd: 8; c1pV: I64[Sp] = c1q1; R1 = P64[R1 + 7]; if (R1 & 7 != 0) goto c1q1; else goto c1q5; c1q5: call (I64[R1])(R1) returns to c1q1, args: 8, res: 8, upd: 8; c1q1: R1 = P64[R1 + 7] & (-8); Sp = Sp + 8; call (I64[R1])(R1) args: 8, res: 0, upd: 8; } }}} To solve this we would need to track the evaluation requirements of binders in STG. Something it seems we currently don't do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 16:43:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 16:43:20 -0000 Subject: [GHC] #15242: Typechecker sometimes doesn't preserve HsPar in original source. In-Reply-To: <045.8e7aac9da580012b12f85623927a4ba7@haskell.org> References: <045.8e7aac9da580012b12f85623927a4ba7@haskell.org> Message-ID: <060.0ca2315e14ea83e0595dd204778d2053@haskell.org> #15242: Typechecker sometimes doesn't preserve HsPar in original source. -------------------------------------+------------------------------------- Reporter: wz1000 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: T15242 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4822 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"aab3c6d18416b3bc8e1378dfc4d485a9307ca5c7/ghc" aab3c6d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aab3c6d18416b3bc8e1378dfc4d485a9307ca5c7" Refactor TcExpr.tcSeq The function TcExpr.tcSeq seemed much longer that is really justifiable; and was set to get worse with the fix to Trac #15242. This patch refactors the special cases for function applications, so that the special case for 'seq' can use the regular tcFunApp, which makes the code both clearer and shorter. And smooths the way for #15242. The special case for 'tagToEnum#' is even more weird and ad-hoc, so I refrained from meddling iwth it for now. I also combined HsUtils.mkHsAppType and mkHsAppTypeOut, so that I could have a single 'wrapHsArgs' function, thereby fixing a ToDo from Alan Zimmerman. That means tha tmkHsAppType now has an equality predicate, but I guess that's fair enough. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 17:02:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 17:02:01 -0000 Subject: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened In-Reply-To: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> References: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> Message-ID: <061.86caffe87286b190f05e7cd1381bf314@haskell.org> #15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | TypeCheckerPlugins 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 diatchki): I agree with Simon here, I think it'd be more consistent if the plugins were always given the flattened constraints, as it seems simpler and more consistent. Also, is it the case that un-flattening only substitutes in the variables that it introduces by flattening, and not all constraints that are in a similar form? More concretely, if I a programmer wrote `x ~ F a, G x ~ G Int`, then would un-flattening rewrite this to `G (F a) ~ G Int` or would it leave it as is? If the latter, then plugins should already be prepared to deal with this case, as it would be quite odd if the one form worked but the other didn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 19:26:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 19:26:45 -0000 Subject: [GHC] #15136: High CPU when asynchronous exception and unblocking retry on TVar raced In-Reply-To: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> References: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> Message-ID: <062.2bdfa4016f7ba4fab90a2a97a821f408@haskell.org> #15136: High CPU when asynchronous exception and unblocking retry on TVar raced -------------------------------------+------------------------------------- Reporter: nshimaza | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.2 Resolution: | Keywords: 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 simonmar): Thanks for the excellent diagnosis @bgamari. I'm not sure what the best fix is yet, but there is something distinctly strange here. `lockTSO` and `unlockTSO` are only used to synchronise for this particular case, between `raiseAsync` and `unpark_tso`. In all other cases, a TSO has a clear owner - in the case of a blocked TSO, the owner is usually the object on which the TSO is blocked, e.g. an MVar. Perhaps we should switch to using an owner semantics for BlockedOnSTM too - that is, if we see `BlockedOnSTM` in `raiseAsync`, we attempt to lock the `TVar` pointed to by `tso->block_info`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 20:25:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 20:25:46 -0000 Subject: [GHC] #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis In-Reply-To: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> References: <046.d99bd58e6ad83ef24f9a7879b45c43ac@haskell.org> Message-ID: <061.9af5f95ce92829752c329074cd46bf74@haskell.org> #15164: Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysis -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T15164 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This is already present in 8.6 and there likely won't be an another 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 20:45:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 20:45:14 -0000 Subject: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened In-Reply-To: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> References: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> Message-ID: <061.676f153aca46fb590d1fd1bead6439ea@haskell.org> #15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | TypeCheckerPlugins 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 agree: never unflatten, for simplicity and consistency. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 20:48:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 20:48:21 -0000 Subject: [GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened In-Reply-To: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> References: <046.7de470c11f4eabed34171ca75a3b8063@haskell.org> Message-ID: <061.4df5b08aa47ce6f7b696e9422905d1d0@haskell.org> #15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.1 checker) | Keywords: Resolution: | TypeCheckerPlugins 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 I a programmer wrote x ~ F a, G x ~ G Int, then would un-flattening rewrite this to G (F a) ~ G Int or would it leave it as is? If these were Wanteds, un-flattening would not rewrite to `G (F a) ~ G Int`. (Wanteds do not rewrite Wanteds.) But if they were Givens, which we don't un-unflatten, we'd end up with {{{ [G] F a ~ fsk1 CFunEqCan [G] G fsk1 ~ fsk2 CFunEqCan [G] G Int ~ fsk3 CFunEqCan [G] fsk2 ~ fsk3 CTyEqCan [G] x ~ fsk1 CTyEqCan }}} If we didn't unflatten Wanteds either, we'd get {{{ [W] F a ~ fuv1 CFunEqCan [W] G x ~ fuv2 CFunEqCan -- NB: not rewritten by [W] x~fuv1 [W] G Int ~ fsk3 CFunEqCan [W] x ~ fuv1 CTyEqCan [W] fuv2 ~ fuv3 CTyEqCan }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 20:50:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 20:50:06 -0000 Subject: [GHC] #2731: Avoid unnecessary evaluation when unpacking constructors In-Reply-To: <046.faa1da08abfada8ee02e462f3ba3c08c@haskell.org> References: <046.faa1da08abfada8ee02e462f3ba3c08c@haskell.org> Message-ID: <061.f38730223b641c5e6413717d4191e48b@haskell.org> #2731: Avoid unnecessary evaluation when unpacking constructors -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.5 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 simonpj): > To solve this we would need to track the evaluation requirements of binders in STG. Correct -- and it really would not be hard to do. A relatively straightforward task for someone interested in GHC's back end. I'd be happy to advise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 12 20:59:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Jun 2018 20:59:56 -0000 Subject: [GHC] #15237: New SRT scheme breaks -fvia-C In-Reply-To: <046.e3fad0365f09ac73a9b55199ebd3f969@haskell.org> References: <046.e3fad0365f09ac73a9b55199ebd3f969@haskell.org> Message-ID: <061.0601efa264ec5ed72aaae78e866bd941@haskell.org> #15237: New SRT scheme breaks -fvia-C -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 slyfox): * cc: slyfox (added) Comment: Does CircleCI still try to run unregisterised GHC? I'd like to peek at failures you are seeing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 00:20:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 00:20:52 -0000 Subject: [GHC] #15136: High CPU when asynchronous exception and unblocking retry on TVar raced In-Reply-To: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> References: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> Message-ID: <062.8a9df408b9e871daac7b1fcde0f778cb@haskell.org> #15136: High CPU when asynchronous exception and unblocking retry on TVar raced -------------------------------------+------------------------------------- Reporter: nshimaza | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.2 Resolution: | Keywords: 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): Just to make sure credit is given where credit is due, carlostome is the one responsible for the diagnosis (which is indeed excellent; great work carlostome!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 00:23:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 00:23:54 -0000 Subject: [GHC] #15237: New SRT scheme breaks -fvia-C In-Reply-To: <046.e3fad0365f09ac73a9b55199ebd3f969@haskell.org> References: <046.e3fad0365f09ac73a9b55199ebd3f969@haskell.org> Message-ID: <061.ba04c62c72482070e5ffc4a08417f42a@haskell.org> #15237: New SRT scheme breaks -fvia-C -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): Indeed I should have included a link: https://circleci.com/gh/ghc/ghc/5735 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 00:43:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 00:43:43 -0000 Subject: [GHC] #15184: T4442 fails on i386 In-Reply-To: <043.2aff333ef7aff4746a063eeba88c2731@haskell.org> References: <043.2aff333ef7aff4746a063eeba88c2731@haskell.org> Message-ID: <058.28dd34b463f444f7b0650d1130210e07@haskell.org> #15184: T4442 fails on i386 -------------------------------------+------------------------------ Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Comment (by bgamari): This is one cause of the CircleCI failures on i386. See https://circleci.com/gh/ghc/ghc/5758. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 01:07:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 01:07:57 -0000 Subject: [GHC] #15184: T4442 fails on i386 In-Reply-To: <043.2aff333ef7aff4746a063eeba88c2731@haskell.org> References: <043.2aff333ef7aff4746a063eeba88c2731@haskell.org> Message-ID: <058.e598c32d489f5d326d55c8ed1fe20107@haskell.org> #15184: T4442 fails on i386 -------------------------------------+---------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4838 Wiki Page: | -------------------------------------+---------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4838 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 01:47:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 01:47:52 -0000 Subject: [GHC] #15266: Add QuantifiedConstraints to release notes Message-ID: <047.7f8a75fae4aa9f1a651d946ac383dd49@haskell.org> #15266: Add QuantifiedConstraints to release notes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems `-XQuantifiedConstraints` never made it into the release notes. We should fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 01:56:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 01:56:52 -0000 Subject: [GHC] #15220: ScopedTypeVariables binds a non-existent variable In-Reply-To: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> References: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> Message-ID: <062.4fcc621a580cebff24c1c081edc22848@haskell.org> #15220: ScopedTypeVariables binds a non-existent variable -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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): Replying to [comment:4 simonpj]: > I suppose we'll have to look at any remaining uses of `SigTv`. Yes, that's what I meant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 02:21:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 02:21:36 -0000 Subject: [GHC] #15266: Add QuantifiedConstraints to release notes In-Reply-To: <047.7f8a75fae4aa9f1a651d946ac383dd49@haskell.org> References: <047.7f8a75fae4aa9f1a651d946ac383dd49@haskell.org> Message-ID: <062.4c53eb585030c189a997b60b5885162f@haskell.org> #15266: Add QuantifiedConstraints to release notes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: 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): I was doing a pass through the release notes earlier today and added some language for `QuantifiedConstraints` but was interrupted. I'll try to commit tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 03:20:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 03:20:38 -0000 Subject: [GHC] #15267: Extend TVar/MVar to N capacity / Add primitive channal type Message-ID: <045.421d1478a12507075d7ed757b0375422@haskell.org> #15267: Extend TVar/MVar to N capacity / Add primitive channal type -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature | Status: new request | Priority: high | Milestone: 8.6.1 Component: Runtime | Version: 8.4.3 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: -------------------------------------+------------------------------------- The current concurrent primitives `TVar` and `MVar` have a fixed single capacity for holding the value to be synchronized. This pose great limitations on implementing many higher level concurrent structures efficiently, e.g. bound channel, semaphore, resource pool, etc. For example current is not ideal due to the extensive usage of multiple `MVar` s. If we have a good `BoundedChan a` type, semaphores can be easily implemented with `BoundedChan ()`. Currently we have various bound channel implementations, but these implementations are often not very efficient or too complex. For example the `BoundedChan` from is based on an array of `MVar` s, thus consumes much more memory than a primitve channel which only have to record parked `StgTSO` s. I'm thinking adding something like: ``` typedef struct { StgHeader header; struct StgMVarTSOQueue_ *head; struct StgMVarTSOQueue_ *tail; StgInt capacity; // the channel's capacity StgInt read_index; // the reading end's index StgInt write_index; // the writing end's index StgClosure *payload[]; // payload array in continuous memory } StgMChan; ``` I still can't work out all the details, but I'm confident something similar to this will work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 03:24:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 03:24:34 -0000 Subject: [GHC] #15267: Extend TVar/MVar to N capacity / Add primitive channal type In-Reply-To: <045.421d1478a12507075d7ed757b0375422@haskell.org> References: <045.421d1478a12507075d7ed757b0375422@haskell.org> Message-ID: <060.f99f62aab91d6eb224cfd88f4b9754a6@haskell.org> #15267: Extend TVar/MVar to N capacity / Add primitive channal type -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.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 winter: Old description: > The current concurrent primitives `TVar` and `MVar` have a fixed single > capacity for holding the value to be synchronized. This pose great > limitations on implementing many higher level concurrent structures > efficiently, e.g. bound channel, semaphore, resource pool, etc. For > example current http://hackage.haskell.org/package/base-4.11.1.0/docs/src/Control.Concurrent.QSem.html#signalQSem> > is not ideal due to the extensive usage of multiple `MVar` s. If we have > a good `BoundedChan a` type, semaphores can be easily implemented with > `BoundedChan ()`. > > Currently we have various bound channel implementations, but these > implementations are often not very efficient or too complex. For example > the `BoundedChan` from http://hackage.haskell.org/package/BoundedChan-1.0.3.0/docs/Control- > Concurrent-BoundedChan.html> is based on an array of `MVar` s, thus > consumes much more memory than a primitve channel which only have to > record parked `StgTSO` s. > > I'm thinking adding something like: > > ``` > typedef struct { > StgHeader header; > struct StgMVarTSOQueue_ *head; > struct StgMVarTSOQueue_ *tail; > StgInt capacity; // the channel's capacity > StgInt read_index; // the reading end's index > StgInt write_index; // the writing end's index > StgClosure *payload[]; // payload array in > continuous memory > } StgMChan; > ``` > > I still can't work out all the details, but I'm confident something > similar to this will work. New description: The current concurrent primitives `TVar` and `MVar` have a fixed single capacity for holding the value to be synchronized. This pose great limitations on implementing many higher level concurrent structures efficiently, e.g. bound channel, semaphore, resource pool, etc. For example current [http://hackage.haskell.org/package/base-4.11.1.0/docs/src/Control.Concurrent.QSem.html#signalQSem semaphore's implementation] is not ideal due to the extensive usage of multiple `MVar` s. If we have a good `BoundedChan a` type, semaphores can be easily implemented with `BoundedChan ()`. Currently we have various bound channel implementations, but these implementations are often not very efficient or too complex. For example the `BoundedChan` from [http://hackage.haskell.org/package/BoundedChan-1.0.3.0/docs/Control- Concurrent-BoundedChan.html BoundedChan] is based on an array of `MVar` s, thus consumes much more memory than a primitve channel which only have to record parked `StgTSO` s. I'm thinking adding something like: {{{ typedef struct { StgHeader header; struct StgMVarTSOQueue_ *head; struct StgMVarTSOQueue_ *tail; StgInt capacity; // the channel's capacity StgInt read_index; // the reading end's index StgInt write_index; // the writing end's index StgClosure *payload[]; // payload array in continuous memory } StgMChan; }}} I still can't work out all the details, but I'm confident something similar to this will work. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 05:10:21 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 05:10:21 -0000 Subject: [GHC] #15267: Extend TVar/MVar to N capacity / Add primitive channel type (was: Extend TVar/MVar to N capacity / Add primitive channal type) In-Reply-To: <045.421d1478a12507075d7ed757b0375422@haskell.org> References: <045.421d1478a12507075d7ed757b0375422@haskell.org> Message-ID: <060.f7798c64ccdb6f231d12dd7dc65e1087@haskell.org> #15267: Extend TVar/MVar to N capacity / Add primitive channel type -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 06:06:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 06:06:57 -0000 Subject: [GHC] #15237: New SRT scheme breaks -fvia-C In-Reply-To: <046.e3fad0365f09ac73a9b55199ebd3f969@haskell.org> References: <046.e3fad0365f09ac73a9b55199ebd3f969@haskell.org> Message-ID: <061.6ba6b4e82e2b077bb163146b046986b8@haskell.org> #15237: New SRT scheme breaks -fvia-C -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4837 Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * differential: => Phab:D4837 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 07:40:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 07:40:28 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.b5856608e13fd67ebc4b3e5d645de2f9@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: patch Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/should_run/T14963 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4833 Wiki Page: | Phab:D4830 -------------------------------------+------------------------------------- Comment (by tdammers): Quick thought on the side: `-fdefer-type-errors` currently implies `-fdefer-type-holes` and `-fdefer-out-of-scope-variables`, which makes sense; however, the way implied flags currently work in GHC leads to unexpected results in GHCi when you turn a flag on and then off again. You'd expect `:set -fdefer-type-errors; :set -fno-defer-type-errors` to be a no-op, but it's not, because it turns `-fdefer-type-holes` and `-fdefer- out-of-scope-variables` on and never off again. So my thought was that maybe it would be better to use two sets of `DynFlags` here: one set to represent what the user explicitly requested, not setting any of the implied flags; and one set of "effective" flags, containing the explicitly requested ones plus all the implied ones. The latter would be calculated on the fly, just before compiling, based on the former. This way, we can trivially tell the difference between flags explicitly requested by the user, and flags that are active because some other flag implies them, and unsetting the explicit flag will take the implicit flags with it unless they were also requested explicitly. If people think this would make sense, I'll file it as a separate ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 08:18:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 08:18:26 -0000 Subject: [GHC] #15180: Make Control.Exception.throw levity polymorphic In-Reply-To: <049.93e817224f99000e45e381c766dae62b@haskell.org> References: <049.93e817224f99000e45e381c766dae62b@haskell.org> Message-ID: <064.ca742471b18a4a7ca92c9c3eafdbab5c@haskell.org> #15180: Make Control.Exception.throw levity polymorphic -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | LevityPolymorphism, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/typecheck/should_compile/T15180.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D4827 -------------------------------------+------------------------------------- Changes (by Ninjatrappeur): * status: new => patch * differential: => https://phabricator.haskell.org/D4827 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 08:44:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 08:44:20 -0000 Subject: [GHC] #15241: Validate failures in sanity way (was: T2783 fails a sanity test) In-Reply-To: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> References: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> Message-ID: <058.49d458886970dd19c8f2efcc7b272ad9@haskell.org> #15241: Validate failures in sanity way -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.5 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 osa1: Old description: > {{{ > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 8.4.2 > > $ cat test.hs > main = print $ do > x <- [ 0 .. 5 ] > let { y = 5 - y } > return y > > $ ghc test.hs -fforce-recomp -debug -rtsopts > [1 of 1] Compiling Main ( test.hs, test.o ) > Linking test ... > > $ ./test +RTS -DS > test: internal error: ASSERTION FAILED: file rts/ThreadPaused.c, line 314 > > Stack trace: > test: Failed to get stack frames of current process: no matching address > range: Success > 0x4a3fbd set_initial_registers (rts/Libdw.c:288.0) > 0x7f9d70fd7a18 dwfl_thread_getframes (/usr/lib/x86_64 > -linux-gnu/libdw-0.170.so) > 0x7f9d70fd7efc dwfl_getthread_frames (/usr/lib/x86_64 > -linux-gnu/libdw-0.170.so) > 0x4a3eb6 libdwGetBacktrace (rts/Libdw.c:257.0) > 0x474de3 rtsFatalInternalErrorFn > (rts/RtsMessages.c:171.0) > 0x474ad0 barf (rts/RtsMessages.c:48.0) > 0x474b02 errorBelch (rts/RtsMessages.c:67.0) > 0x479273 threadPaused (rts/ThreadPaused.c:318.0) > 0x48ccdb stg_returnToSched > (rts/StgStartup.cmm:117.1) > 0x48f428 stg_enter_info > (rts/HeapStackCheck.cmm:166.1) > 0x45fd18 > integerzmgmp_GHCziIntegerziType_minusInteger_info > (/home/omer/haskell/test) > > (GHC version 8.4.2 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > zsh: abort (core dumped) ./test +RTS -DS > }}} > > `test.hs` above is the test `testsuite/tests/rts/T2783.hs`. > > Tested with HEAD and 8.4.2. New description: It seems like some of the sanity checks fail when running the test suite. To reproduce, run the test suite using: {{{ make EXTRA_HC_OPTS='-debug -rtsopts' WAY=sanity THREADS=12 }}} Results: {{{ Unexpected failures: rts/T2783.run T2783 [bad exit code] (sanity) rts/flags/T12870e.run T12870e [bad stdout] (sanity) rts/flags/T12870f.run T12870f [bad stdout] (sanity) ../../libraries/base/tests/length001.run length001 [bad exit code] (sanity) ../../libraries/ghc-heap/tests/heap_all.run heap_all [bad exit code] (sanity) rts/T7919.run T7919 [bad exit code] (sanity) ../../libraries/base/tests/memo001.run memo001 [bad exit code] (sanity) ../../libraries/hpc/tests/raytrace/hpc_raytrace.run hpc_raytrace [bad exit code] (sanity) }}} One example failure: {{{ $ cat test.hs main = print $ do x <- [ 0 .. 5 ] let { y = 5 - y } return y $ ghc test.hs -fforce-recomp -debug -rtsopts [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... $ ./test +RTS -DS test: internal error: ASSERTION FAILED: file rts/ThreadPaused.c, line 314 Stack trace: test: Failed to get stack frames of current process: no matching address range: Success 0x4a3fbd set_initial_registers (rts/Libdw.c:288.0) 0x7f9d70fd7a18 dwfl_thread_getframes (/usr/lib/x86_64 -linux-gnu/libdw-0.170.so) 0x7f9d70fd7efc dwfl_getthread_frames (/usr/lib/x86_64 -linux-gnu/libdw-0.170.so) 0x4a3eb6 libdwGetBacktrace (rts/Libdw.c:257.0) 0x474de3 rtsFatalInternalErrorFn (rts/RtsMessages.c:171.0) 0x474ad0 barf (rts/RtsMessages.c:48.0) 0x474b02 errorBelch (rts/RtsMessages.c:67.0) 0x479273 threadPaused (rts/ThreadPaused.c:318.0) 0x48ccdb stg_returnToSched (rts/StgStartup.cmm:117.1) 0x48f428 stg_enter_info (rts/HeapStackCheck.cmm:166.1) 0x45fd18 integerzmgmp_GHCziIntegerziType_minusInteger_info (/home/omer/haskell/test) (GHC version 8.4.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./test +RTS -DS }}} `test.hs` above is the test `testsuite/tests/rts/T2783.hs`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 08:46:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 08:46:26 -0000 Subject: [GHC] #15241: Validate failures in sanity way In-Reply-To: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> References: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> Message-ID: <058.a30a10f8dfcccef5c5df39accaec6b42@haskell.org> #15241: Validate failures in sanity way -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.5 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:D4839 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * differential: => Phab:D4839 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 09:03:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 09:03:03 -0000 Subject: [GHC] #15268: Clarify and test the interaction of -with-rtsopts and -rtsopts flags Message-ID: <043.5fda2ae4244feef581761e0721041e3e@haskell.org> #15268: Clarify and test the interaction of -with-rtsopts and -rtsopts flags -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- Looking at the user manual it's not clear how do `-with-rtsopts` and `-rtsopts` flags interact. I'd expect `-with-rtsopts` to work even with `-rtsopts=ignoreAll`, but I don't know if this is really the case, and because we don't have a way to print RTS flags (see #15261 for this) it's hard to make sure this works as expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 09:11:17 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 09:11:17 -0000 Subject: [GHC] #15268: Clarify and test the interaction of -with-rtsopts and -rtsopts flags In-Reply-To: <043.5fda2ae4244feef581761e0721041e3e@haskell.org> References: <043.5fda2ae4244feef581761e0721041e3e@haskell.org> Message-ID: <058.5201d87d467a9840d30d060237453857@haskell.org> #15268: Clarify and test the interaction of -with-rtsopts and -rtsopts flags -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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 AndreasK): Replying to [ticket:15268 osa1]: > I'd expect `-with-rtsopts` to work even with `-rtsopts=ignoreAll`, but I don't know if this is really the case. This is how it's intended if not it would be a bug. > and because we don't have a way to print RTS flags (see #15261 for this) it's hard to make sure this works as expected. You can test this works by setting an RTS flags and read it from Haskell. For example set the number of generations and print them from haskell. {{{ import GHC.RTS.Flags (getGCFlags, generations) main :: IO () main = do gcFlags <- getGCFlags putStr . show $ generations gcFlags }}} This is already done in the testsuite by T12870h. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 09:11:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 09:11:51 -0000 Subject: [GHC] #15180: Make Control.Exception.throw levity polymorphic In-Reply-To: <049.93e817224f99000e45e381c766dae62b@haskell.org> References: <049.93e817224f99000e45e381c766dae62b@haskell.org> Message-ID: <064.eddd0f2ef85e4becab687ab3a9cfc7bf@haskell.org> #15180: Make Control.Exception.throw levity polymorphic -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | LevityPolymorphism, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/typecheck/should_compile/T15180.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4827 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Ninjatrappeur): * differential: https://phabricator.haskell.org/D4827 => Phab:D4827 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 09:45:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 09:45:54 -0000 Subject: [GHC] #15268: Clarify and test the interaction of -with-rtsopts and -rtsopts flags In-Reply-To: <043.5fda2ae4244feef581761e0721041e3e@haskell.org> References: <043.5fda2ae4244feef581761e0721041e3e@haskell.org> Message-ID: <058.06d30378ce65f99e8bfee40d9ba694f9@haskell.org> #15268: Clarify and test the interaction of -with-rtsopts and -rtsopts flags -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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:D4840 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D4840 Comment: Thanks for the info. Updated the diff with a few clarifying sentences about this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 11:10:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 11:10:43 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.7cbe7d4432122b90dd2f176974efdcdf@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: patch Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/should_run/T14963 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4833 Wiki Page: | Phab:D4830 -------------------------------------+------------------------------------- Comment (by simonpj): Let's not go overboard on this. At the moment we are just implementing a workaround for a bug that we will fix. Moreover the workaround is a one- line addition to Phab:D4830. DO we need to do more? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 11:33:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 11:33:26 -0000 Subject: [GHC] #15241: Validate failures in sanity way In-Reply-To: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> References: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> Message-ID: <058.70098d0b8dba799297513e3b8030a403@haskell.org> #15241: Validate failures in sanity way -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.5 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:D4839 Wiki Page: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: > It seems like some of the sanity checks fail when running the test suite. > To reproduce, run the test suite using: > > {{{ > make EXTRA_HC_OPTS='-debug -rtsopts' WAY=sanity THREADS=12 > }}} > > Results: > > {{{ > Unexpected failures: > rts/T2783.run T2783 [bad exit > code] (sanity) > rts/flags/T12870e.run T12870e [bad > stdout] (sanity) > rts/flags/T12870f.run T12870f [bad > stdout] (sanity) > ../../libraries/base/tests/length001.run length001 [bad > exit code] (sanity) > ../../libraries/ghc-heap/tests/heap_all.run heap_all [bad > exit code] (sanity) > rts/T7919.run T7919 [bad exit > code] (sanity) > ../../libraries/base/tests/memo001.run memo001 [bad exit > code] (sanity) > ../../libraries/hpc/tests/raytrace/hpc_raytrace.run hpc_raytrace [bad > exit code] (sanity) > }}} > > One example failure: > > {{{ > $ cat test.hs > main = print $ do > x <- [ 0 .. 5 ] > let { y = 5 - y } > return y > > $ ghc test.hs -fforce-recomp -debug -rtsopts > [1 of 1] Compiling Main ( test.hs, test.o ) > Linking test ... > > $ ./test +RTS -DS > test: internal error: ASSERTION FAILED: file rts/ThreadPaused.c, line 314 > > Stack trace: > test: Failed to get stack frames of current process: no matching address > range: Success > 0x4a3fbd set_initial_registers (rts/Libdw.c:288.0) > 0x7f9d70fd7a18 dwfl_thread_getframes (/usr/lib/x86_64 > -linux-gnu/libdw-0.170.so) > 0x7f9d70fd7efc dwfl_getthread_frames (/usr/lib/x86_64 > -linux-gnu/libdw-0.170.so) > 0x4a3eb6 libdwGetBacktrace (rts/Libdw.c:257.0) > 0x474de3 rtsFatalInternalErrorFn > (rts/RtsMessages.c:171.0) > 0x474ad0 barf (rts/RtsMessages.c:48.0) > 0x474b02 errorBelch (rts/RtsMessages.c:67.0) > 0x479273 threadPaused (rts/ThreadPaused.c:318.0) > 0x48ccdb stg_returnToSched > (rts/StgStartup.cmm:117.1) > 0x48f428 stg_enter_info > (rts/HeapStackCheck.cmm:166.1) > 0x45fd18 > integerzmgmp_GHCziIntegerziType_minusInteger_info > (/home/omer/haskell/test) > > (GHC version 8.4.2 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > zsh: abort (core dumped) ./test +RTS -DS > }}} > > `test.hs` above is the test `testsuite/tests/rts/T2783.hs`. New description: It seems like some of the sanity checks fail when running the test suite. To reproduce, run the test suite using: {{{ make EXTRA_HC_OPTS='-debug -rtsopts' WAY=sanity THREADS=12 }}} Results: {{{ Unexpected failures: rts/T2783.run T2783 [bad exit code] (sanity) rts/flags/T12870e.run T12870e [bad stdout] (sanity) rts/flags/T12870f.run T12870f [bad stdout] (sanity) ../../libraries/base/tests/length001.run length001 [bad exit code] (sanity) ../../libraries/ghc-heap/tests/heap_all.run heap_all [bad exit code] (sanity) rts/T7919.run T7919 [bad exit code] (sanity) ../../libraries/base/tests/memo001.run memo001 [bad exit code] (sanity) ../../libraries/hpc/tests/raytrace/hpc_raytrace.run hpc_raytrace [bad exit code] (sanity) }}} T2783: {{{ T2783: internal error: ASSERTION FAILED: file rts/ThreadPaused.c, line 314 Stack trace: test: Failed to get stack frames of current process: no matching address range: Success 0x4a3fbd set_initial_registers (rts/Libdw.c:288.0) 0x7f9d70fd7a18 dwfl_thread_getframes (/usr/lib/x86_64 -linux-gnu/libdw-0.170.so) 0x7f9d70fd7efc dwfl_getthread_frames (/usr/lib/x86_64 -linux-gnu/libdw-0.170.so) 0x4a3eb6 libdwGetBacktrace (rts/Libdw.c:257.0) 0x474de3 rtsFatalInternalErrorFn (rts/RtsMessages.c:171.0) 0x474ad0 barf (rts/RtsMessages.c:48.0) 0x474b02 errorBelch (rts/RtsMessages.c:67.0) 0x479273 threadPaused (rts/ThreadPaused.c:318.0) 0x48ccdb stg_returnToSched (rts/StgStartup.cmm:117.1) 0x48f428 stg_enter_info (rts/HeapStackCheck.cmm:166.1) 0x45fd18 integerzmgmp_GHCziIntegerziType_minusInteger_info (/home/omer/haskell/test) (GHC version 8.4.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./T2783 +RTS -DS }}} memo001: {{{ memo001: internal error: ASSERTION FAILED: file rts/sm/GCAux.c, line 44 (GHC version 8.5.20180612 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./memo001 +RTS -DS -A10k }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 12:14:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 12:14:52 -0000 Subject: [GHC] #15269: Qualified Names in --show-iface output Message-ID: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> #15269: Qualified Names in --show-iface output -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- == Motivation In the Hi Haddock project we use tests based on the `--show-iface` mode. In the `.hi`-files we dump, we list the `Name`s that may correspond to an identifier found in a docstring. In the case of ambiguous identifiers, it would be nice to see the module names of the corresponding `Name`s, so we can tell them apart. == Possible solutions * In Phab:D4806, I proposed to hardcode qualification for `--show-iface`. But this may create unwanted noise in different usecases. * If I could use `-dppr-debug` with `--show-iface` I would do that. Currently I get the following error if try: {{{ Warning: the following files would be used as linker inputs, but linking is not being done: NoExportList.hi -dppr-debug: openBinaryFile: does not exist (No such file or directory) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 12:18:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 12:18:56 -0000 Subject: [GHC] #15265: Print result summary in test suite when interrupted In-Reply-To: <043.f6136d5e515deaf3f2a252d8637b12b1@haskell.org> References: <043.f6136d5e515deaf3f2a252d8637b12b1@haskell.org> Message-ID: <058.768e75880ba2219d1b7323aea23e4519@haskell.org> #15265: Print result summary in test suite when interrupted -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: patch Priority: lowest | Milestone: Component: Test Suite | Version: 8.5 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:D4841 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4841 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 12:29:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 12:29:55 -0000 Subject: [GHC] #15241: Validate failures in sanity way In-Reply-To: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> References: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> Message-ID: <058.f253dd6938a2851d5710f6f40e1292e2@haskell.org> #15241: Validate failures in sanity way -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.5 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:D4839 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"a610c215580c56116b0882d3dce4a3a45993df19/ghc" a610c21/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a610c215580c56116b0882d3dce4a3a45993df19" Fix some of the failures in sanity way Tests for runtime argument parsing should only run in normal way to avoid breakage caused by way-specific RTS arguments. Reviewers: bgamari, AndreasK, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15241 Differential Revision: https://phabricator.haskell.org/D4839 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 12:35:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 12:35:40 -0000 Subject: [GHC] #15241: Validate failures in sanity way In-Reply-To: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> References: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> Message-ID: <058.cba27d4974d595ba2d4e780e4640f0f6@haskell.org> #15241: Validate failures in sanity way -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.5 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:D4839 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): These two {{{ rts/flags/T12870e.run T12870e [bad stdout] (sanity) rts/flags/T12870f.run T12870f [bad stdout] (sanity) }}} are fixed with the commit above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 14:51:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 14:51:11 -0000 Subject: [GHC] #14392: `make binary-dist` is broken In-Reply-To: <047.e12bb26020da23d6c31cd3a9b180d24f@haskell.org> References: <047.e12bb26020da23d6c31cd3a9b180d24f@haskell.org> Message-ID: <062.bf20fcca2e2f0827dc671c9bf74853cd@haskell.org> #14392: `make binary-dist` is broken -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ninjatrappeur): Just ran the same command on a610c215580c56116b0882d3dce4a3a45993df19 and ended up with a different error: {{{ cd bindistprep && "/bin/tar" hcf - -T ../bindist-list.uniq | /bin/xz -c > ../bindistprep/ghc-8.5.20180612-x86_64-unknown-linux.tar.xz /bin/tar: ghc-8.5.20180612/libraries/libiserv/LICENSE : stat impossible: No such file or directory }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 15:52:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 15:52:54 -0000 Subject: [GHC] #14392: `make binary-dist` is broken In-Reply-To: <047.e12bb26020da23d6c31cd3a9b180d24f@haskell.org> References: <047.e12bb26020da23d6c31cd3a9b180d24f@haskell.org> Message-ID: <062.726a62f9a59fab9817616cc6e950d9db@haskell.org> #14392: `make binary-dist` is broken -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Build 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:D4844 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4844 Comment: The patch originally introducing this issue, 1e9f90af7311c33de0f7f5b7dba594725596d675, was reverted in d9b6015d1942aa176e85bb71f34200bab54e1c9c. This ticket should have been closed at this point. Unfortunately it does look like there is now another related issue due to the recent `libiserv` renaming, which inexplicably dropped the license file, which is expected by the bindist script. This should be fixed by Phab:D4844. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 16:04:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 16:04:47 -0000 Subject: [GHC] #15270: TH doesn't verify name types during conversion Message-ID: <046.884d12edfebb255ed830a85371c14d75@haskell.org> #15270: TH doesn't verify name types during conversion -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template | Version: 8.4.3 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Angerman reported that a use of the [[http://hackage.haskell.org/package /deriving-compat-0.4.2/docs/src/Data.Eq.Deriving.Internal.html#deriveEq1 `deriveEq`]] splice is causing GHC to abort with an assertion failure: {{{#!hs zonkExpr env (HsVar x (L l id)) = ASSERT2( isNothing (isDataConId_maybe id), ppr id ) return (HsVar x (L l (zonkIdOcc env id))) }}} I suspect the `deriveEq1` is calling `varE` with a DataCon name. We should catch this case and throw a better error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 16:19:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 16:19:08 -0000 Subject: [GHC] #15269: Qualified Names in --show-iface output In-Reply-To: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> References: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> Message-ID: <061.42c64a4509092d86747f29110af81a75@haskell.org> #15269: Qualified Names in --show-iface output -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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 simonpj): It would help me to understand what you are proposing if you could give an example of what you currently get with `--show-iface` and what you'd like to get instead. Also, is it really best to work from a textual dump? You could instead use the GHC API to load the .hi file into memory, and interrogate it directly, perhaps? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 16:23:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 16:23:24 -0000 Subject: [GHC] #15270: TH doesn't verify name types during conversion In-Reply-To: <046.884d12edfebb255ed830a85371c14d75@haskell.org> References: <046.884d12edfebb255ed830a85371c14d75@haskell.org> Message-ID: <061.4fed61cd171807a4e6ce53ed17141573@haskell.org> #15270: TH doesn't verify name types during conversion -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.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 RyanGlScott): If you could figure out which part of `deriving-compat` is doing something infelicitous with `varE`, let me know and I'll fix that separately. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 16:35:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 16:35:15 -0000 Subject: [GHC] #15270: TH doesn't verify name types during conversion In-Reply-To: <046.884d12edfebb255ed830a85371c14d75@haskell.org> References: <046.884d12edfebb255ed830a85371c14d75@haskell.org> Message-ID: <061.115dd195323b64fe5059121e4fbfa3bf@haskell.org> #15270: TH doesn't verify name types during conversion -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.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): I think my hypothesis may not be quite right, actually. For the record, the failing module is https://github.com/input-output-hk/cardano- sl/blob/e24a7c11203446b7a926acc340db2afedfba1664/core/src/Pos/Core/Script.hs#L31-L33. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 16:35:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 16:35:36 -0000 Subject: [GHC] #15270: TH doesn't verify name types during conversion In-Reply-To: <046.884d12edfebb255ed830a85371c14d75@haskell.org> References: <046.884d12edfebb255ed830a85371c14d75@haskell.org> Message-ID: <061.b8aa42b02ad128fdf46ae385db41a3c0@haskell.org> #15270: TH doesn't verify name types during conversion -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.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 bgamari: Old description: > Angerman reported that a use of the [[http://hackage.haskell.org/package > /deriving-compat-0.4.2/docs/src/Data.Eq.Deriving.Internal.html#deriveEq1 > `deriveEq`]] splice is causing GHC to abort with an assertion failure: > {{{#!hs > zonkExpr env (HsVar x (L l id)) > = ASSERT2( isNothing (isDataConId_maybe id), ppr id ) > return (HsVar x (L l (zonkIdOcc env id))) > }}} > > I suspect the `deriveEq1` is calling `varE` with a DataCon name. We > should catch this case and throw a better error message. New description: Angerman reported that a use of the [[http://hackage.haskell.org/package /deriving- compat-0.4.2/docs/src/Data.Eq.Deriving.Internal.html#deriveEq1|`deriveEq`]] splice is causing GHC to abort with an assertion failure: {{{#!hs zonkExpr env (HsVar x (L l id)) = ASSERT2( isNothing (isDataConId_maybe id), ppr id ) return (HsVar x (L l (zonkIdOcc env id))) }}} I suspect the `deriveEq1` is calling `varE` with a DataCon name. We should catch this case and throw a better error message. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 18:37:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 18:37:42 -0000 Subject: [GHC] #14475: Upload documentation dumps In-Reply-To: <046.875271090aacfb7d8f31943e1b69bd4b@haskell.org> References: <046.875271090aacfb7d8f31943e1b69bd4b@haskell.org> Message-ID: <061.321806bf51effd233120f91dd449761d@haskell.org> #14475: Upload documentation dumps -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gander Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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 gander): I have begun some investigation but wondered if it might be best if you gave me a starting point or background. I have: - used {{{make -C docs}}}, {{{make pdf}}} etc. to generate documentation in docs/user_guide but they fail with: make[2]: * * * No rule to make target 'html_docs/users_guide'. Stop. - tried a freshly built haddock (./inplace/bin/haddock) but havent yet figured out the options; - installed Sphinx for python2 & 3 but but, also, havent yet figured out the options; So, am I on the right track with any of the above? Q: How would you want it to work? A: Triggered by the recent successful GHC CI? Or unsuccessful. Please tell me if you prefer another approach. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 18:57:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 18:57:03 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.0882c72dd8dc523a5f312e3f2150d0ef@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: patch Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/should_run/T14963 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4833 Wiki Page: | Phab:D4830 -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:36 simonpj]: > Let's not go overboard on this. At the moment we are just implementing a workaround for a bug that we will fix. Moreover the workaround is a one-line addition to Phab:D4830. DO we need to do more? Oh, of course the proposal is not going to help with the issue at hand. I just noticed some unintuitive behavior, and a possible fix. If it's not deemed fix-worthy, then you'll never hear me about it again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 19:20:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 19:20:56 -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.5b1457d68975fe22457a6be50874f4ff@haskell.org> #13564: Why does memory usage increase so much during CoreTidy? -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.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: #13586 | Differential Rev(s): Phab:D3516, Wiki Page: | Phab:D3524 -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * related: => #13586 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 19:22:21 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 19:22:21 -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.2063cc43e24e46df8cae968f80f195eb@haskell.org> #13564: Why does memory usage increase so much during CoreTidy? -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.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: #13586 | Differential Rev(s): Phab:D3516, Wiki Page: | Phab:D3524 -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * cc: MikolajKonarski (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 19:34:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 19:34:27 -0000 Subject: [GHC] #13586: ghc --make seems to leak memory In-Reply-To: <054.b9022cd384af70aab8c44b70e8c723cb@haskell.org> References: <054.b9022cd384af70aab8c44b70e8c723cb@haskell.org> Message-ID: <069.7bddfb449ef72261d5c0ef09881d1ed0@haskell.org> #13586: ghc --make seems to leak memory -------------------------------------+------------------------------------- Reporter: MikolajKonarski | 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) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13379 #13564 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Just one more data point, showing (I guess) how big .hi files loaded into memory and never freed can lock up lots of RAM during compilation: this commit https://github.com/LambdaHack/LambdaHack/commit/9adc5ee93ab32a9a1ba949362371a6a28abf446a lowers maximum resident set size of GHC during compilation from 4.5G to 2.8G, as measured with `/usr/bin/time -v cabal build -j1`on Ubuntu with GHC 8.4.3. As reported in other comments, it's also the case that interrupting the compilation and then restarting it lowers resident set size considerably. Before the commit, two RAM usage peaks coincide when compiling the library section of the .cabal file --- one peak from 120 large .hi files loaded into memory (I guess ~2G) and another from an excessive amount of specialisations performed when compiling a single module that provides a concrete implementation of a certain monad. The commit just moves the specialization to executable section of the .cabal file thus separating the peaks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 20:44:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 20:44:03 -0000 Subject: [GHC] #15269: Qualified Names in --show-iface output In-Reply-To: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> References: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> Message-ID: <061.eb781fb50c261e5f17a6f477d7ba7170@haskell.org> #15269: Qualified Names in --show-iface output -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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: | -------------------------------------+------------------------------------- Old description: > == Motivation > > In the Hi Haddock project we use tests based on the `--show-iface` mode. > > In the `.hi`-files we dump, we list the `Name`s that may correspond to an > identifier found in a docstring. In the case of ambiguous identifiers, it > would be nice to see the module names of the corresponding `Name`s, so we > can tell them apart. > > == Possible solutions > > * In Phab:D4806, I proposed to hardcode qualification for `--show-iface`. > But this may create unwanted noise in different usecases. > > * If I could use `-dppr-debug` with `--show-iface` I would do that. > Currently I get the following error if try: > > {{{ > Warning: the following files would be used as linker inputs, but > linking is not being done: NoExportList.hi > -dppr-debug: openBinaryFile: does not exist (No such file or > directory) > }}} New description: == Motivation In the Hi Haddock project we use tests based on the `--show-iface` mode. In the `.hi`-files we dump, we list the `Name`s that may correspond to an identifier found in a docstring. In the case of ambiguous identifiers, it would be nice to see the module names of the corresponding `Name`s, so we can tell them apart. For example, for a module containing a docstring `"'elem'"` and a declaration for `elem`, we would currently see: {{{ "elem": elem elem }}} One `elem` refers to the local one, the other to the one in the `Prelude`. What I'd like to see instead is {{{ "elem": Data.Foldable.elem MyModule.elem }}} If the output would also contain package names and/or ids, I wouldn't mind. == Possible solutions * In Phab:D4806, I proposed to hardcode qualification for `--show-iface`. But this may create unwanted noise in different usecases. * If I could use `-dppr-debug` with `--show-iface` I would do that. Currently I get the following error if try: {{{ Warning: the following files would be used as linker inputs, but linking is not being done: NoExportList.hi -dppr-debug: openBinaryFile: does not exist (No such file or directory) }}} -- Comment (by sjakobi): > It would help me to understand what you are proposing if you could give an example of what you currently get with --show-iface and what you'd like to get instead. I have updated the description. > Also, is it really best to work from a textual dump? You could instead use the GHC API to load the .hi file into memory, and interrogate it directly, perhaps? I'm not sure how to integrate tests like that into the GHC testsuite. Also, apart from this issue, `--show-iface` works pretty well for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 20:49:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 20:49:33 -0000 Subject: [GHC] #15269: Qualified Names in --show-iface output In-Reply-To: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> References: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> Message-ID: <061.0ced3e6906d8c6e10c594476fc12a20e@haskell.org> #15269: Qualified Names in --show-iface output -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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 sjakobi): > In ​Phab:D4806, I proposed to hardcode qualification for --show-iface. But this may create unwanted noise in different usecases. I'm wondering if it might be more acceptable if I limit the hardcoded qualification to the the area of interest to me? I just found out about `withPprStyle`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 13 23:42:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Jun 2018 23:42:44 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.96eed79f917de53a6824c3c83a00938e@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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:D4783 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgillespie): Replying to [comment:32 Phyx-]: > It's quite common to have to update test outputs when you change user visible messages. I'd be more surprised if you didn't have to. In any case, will change it later. After further review, it was only 2 tests. I updated them and added them to the phabricator revision. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 00:50:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 00:50:14 -0000 Subject: [GHC] #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity Message-ID: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity -------------------------------------+------------------------------------- Reporter: claude | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 bug report is about the incorrect result not the poor performance.) Very large positive exponent in floating point literal at Double type gives `0` instead of `Infinity` in `ghci-8.4.3` (self-compiled on Debian Buster x86_64 / amd64): {{{ $ ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> :set +s Prelude> 1e100000000 :: Double Infinity (5.70 secs, 68,552 bytes) Prelude> 1e1000000000 :: Double 0.0 (69.35 secs, 60,088 bytes) }}} Writing `10^` instead of `1e` completes almost instantly with the correct result (`Infinity`) in both cases. More precisely, {{{ Prelude> 1e646457008 :: Double Infinity (40.80 secs, 64,272 bytes) Prelude> 1e646457009 :: Double 0.0 (40.46 secs, 60,088 bytes) }}} Note: {{{#!hs (floor $ 2^31 / logBase 2 10 + 16) == 646457009 }}} This vague numerology makes me think something C `int`-related is overflowing somewhere (GMP? integer-gmp? GHC?). Standalone test program: {{{#!hs main = do print 1e646457008 print 1e646457009 }}} Interestingly, it doesn't occur, or at least not near the same threshold, in 32-bit `ghci-8.0.1` (Debian Stretch i686), though it aborts when getting too large (the 32-bit i686 machine has 1GB RAM and 4GB swap, the 64-bit x86_64/amd64 has 32GB RAM). The sheer time it takes to run makes bisecting the exact threshold on i686 not something I want to take on (though if someone writes some code that can do it programmatically I'd be happy to run it overnight if it would help). {{{ $ ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> :set +s Prelude> 1e646457008 :: Double Infinity (415.26 secs, 17,908 bytes) Prelude> 1e646457009 :: Double Infinity (417.66 secs, 17,820 bytes) Prelude> 1e746457298 :: Double Infinity (490.00 secs, 17,820 bytes) Prelude> 1e1000000000 :: Double GNU MP: Cannot allocate memory (size=419438600) Aborted $ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 02:08:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 02:08:27 -0000 Subject: [GHC] #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity In-Reply-To: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> References: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> Message-ID: <060.e17688912b0b47727750f945397353c8@haskell.org> #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity -------------------------------------+------------------------------------- Reporter: claude | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: | -------------------------------------+------------------------------------- Description changed by claude: Old description: > (This bug report is about the incorrect result not the poor performance.) > > Very large positive exponent in floating point literal at Double type > gives `0` instead of `Infinity` in `ghci-8.4.3` (self-compiled on Debian > Buster x86_64 / amd64): > > {{{ > $ ghci > GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help > Prelude> :set +s > Prelude> 1e100000000 :: Double > Infinity > (5.70 secs, 68,552 bytes) > Prelude> 1e1000000000 :: Double > 0.0 > (69.35 secs, 60,088 bytes) > }}} > > Writing `10^` instead of `1e` completes almost instantly with the correct > result (`Infinity`) in both cases. > > More precisely, > > {{{ > Prelude> 1e646457008 :: Double > Infinity > (40.80 secs, 64,272 bytes) > Prelude> 1e646457009 :: Double > 0.0 > (40.46 secs, 60,088 bytes) > }}} > > Note: > > {{{#!hs > (floor $ 2^31 / logBase 2 10 + 16) == 646457009 > }}} > > This vague numerology makes me think something C `int`-related is > overflowing somewhere (GMP? integer-gmp? GHC?). > > Standalone test program: > > {{{#!hs > main = do > print 1e646457008 > print 1e646457009 > }}} > > Interestingly, it doesn't occur, or at least not near the same threshold, > in 32-bit `ghci-8.0.1` (Debian Stretch i686), though it aborts when > getting too large (the 32-bit i686 machine has 1GB RAM and 4GB swap, the > 64-bit x86_64/amd64 has 32GB RAM). The sheer time it takes to run makes > bisecting the exact threshold on i686 not something I want to take on > (though if someone writes some code that can do it programmatically I'd > be happy to run it overnight if it would help). > > {{{ > $ ghci > GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help > Prelude> :set +s > Prelude> 1e646457008 :: Double > Infinity > (415.26 secs, 17,908 bytes) > Prelude> 1e646457009 :: Double > Infinity > (417.66 secs, 17,820 bytes) > Prelude> 1e746457298 :: Double > Infinity > (490.00 secs, 17,820 bytes) > Prelude> 1e1000000000 :: Double > GNU MP: Cannot allocate memory (size=419438600) > Aborted > $ > }}} New description: (This bug report is about the incorrect result not the poor performance.) Very large positive exponent in floating point literal at Double type gives `0` instead of `Infinity` in `ghci-8.4.3` (self-compiled on Debian Buster x86_64 / amd64): {{{ $ ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> :set +s Prelude> 1e100000000 :: Double Infinity (5.70 secs, 68,552 bytes) Prelude> 1e1000000000 :: Double 0.0 (69.35 secs, 60,088 bytes) }}} Writing `10^` instead of `1e` completes almost instantly with the correct result (`Infinity`) in both cases. More precisely, {{{ Prelude> 1e646457008 :: Double Infinity (40.80 secs, 64,272 bytes) Prelude> 1e646457009 :: Double 0.0 (40.46 secs, 60,088 bytes) }}} Note: {{{#!hs (floor $ 2^31 / logBase 2 10 + 16) == 646457009 }}} This vague numerology makes me think something C `int`-related is overflowing somewhere (GMP? integer-gmp? GHC?). Standalone test program: {{{#!hs main = do print 1e646457008 print 1e646457009 }}} Interestingly, it doesn't occur, or at least not near the same threshold, in 32-bit `ghci-8.0.1` (Debian Stretch i686), though it aborts when getting too large (the 32-bit i686 machine has 1GB RAM and 4GB swap, the 64-bit x86_64/amd64 has 32GB RAM). The sheer time it takes to run makes bisecting the exact threshold on i686 not something I want to take on (though if someone writes some code that can do it programmatically I'd be happy to run it overnight if it would help). {{{ $ ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> :set +s Prelude> 1e646457008 :: Double Infinity (415.26 secs, 17,908 bytes) Prelude> 1e646457009 :: Double Infinity (417.66 secs, 17,820 bytes) Prelude> 1e746457298 :: Double Infinity (490.00 secs, 17,820 bytes) Prelude> 1e1000000000 :: Double GNU MP: Cannot allocate memory (size=419438600) Aborted $ }}} `ghci-8.0.2` on Debian Buster amd64 exhibits the problem also. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 04:19:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 04:19:44 -0000 Subject: [GHC] #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity In-Reply-To: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> References: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> Message-ID: <060.b3d272243ce02cef952342e5f257b578@haskell.org> #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity -------------------------------------+------------------------------------- Reporter: claude | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 sighingnow): Currently we store literal rationals as `Rational` in parsed ast, that means, for `1e5`, we will have: {{{#!hs (HsFractional (FL (SourceText "1e1000") (False) (:% (100000) (1)))) }}} Note that we have evaluate `1e5` as `100000`. A possible fix for this problem would be: 1. In `readRational__` (in compiler/utils/Util.hs), we only validate the format of literal numbers, don't evaluate it. 2. We evaluate the literal to numeric value during code generation, after typechecking. Then we can know the type of the literal number and once when we know the value is larger than the maximum bound of `Float/Double` type, we can safely feed a `Infinity` value into the cell, without evaluating the whole literal string and knowing the true `Rational` value of the literal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 07:03:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 07:03:06 -0000 Subject: [GHC] #15252: syn_arg_wraps and syn_res_wrap are only populated after typechecking In-Reply-To: <049.1a5ef24fb5e35afe5e2b66465a8d0d89@haskell.org> References: <049.1a5ef24fb5e35afe5e2b66465a8d0d89@haskell.org> Message-ID: <064.2a7eabb1a7084f5ef83c8794ef84656c@haskell.org> #15252: syn_arg_wraps and syn_res_wrap are only populated after typechecking -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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 Shayan-Najd): Thanks for reporting this. I also battled with this before. As far as I remember, all instances of `SyntaxExpr` should be considered as extensions. I am revisiting the current implementation of TTG to match [wiki:ImplementingTreesThatGrow/TreesThatGrowGuidance the idiom]. I will close this ticket once I am done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 07:34:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 07:34:15 -0000 Subject: [GHC] #15241: Validate failures in sanity way In-Reply-To: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> References: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> Message-ID: <058.4c120965ab0a5a6be5ec6f7fdb767fb0@haskell.org> #15241: Validate failures in sanity way -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.5 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:D4839 Wiki Page: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: > It seems like some of the sanity checks fail when running the test suite. > To reproduce, run the test suite using: > > {{{ > make EXTRA_HC_OPTS='-debug -rtsopts' WAY=sanity THREADS=12 > }}} > > Results: > > {{{ > Unexpected failures: > rts/T2783.run T2783 [bad exit > code] (sanity) > rts/flags/T12870e.run T12870e [bad > stdout] (sanity) > rts/flags/T12870f.run T12870f [bad > stdout] (sanity) > ../../libraries/base/tests/length001.run length001 [bad > exit code] (sanity) > ../../libraries/ghc-heap/tests/heap_all.run heap_all [bad > exit code] (sanity) > rts/T7919.run T7919 [bad exit > code] (sanity) > ../../libraries/base/tests/memo001.run memo001 [bad exit > code] (sanity) > ../../libraries/hpc/tests/raytrace/hpc_raytrace.run hpc_raytrace [bad > exit code] (sanity) > }}} > > T2783: > > {{{ > T2783: internal error: ASSERTION FAILED: file rts/ThreadPaused.c, line > 314 > > Stack trace: > test: Failed to get stack frames of current process: no matching address > range: Success > 0x4a3fbd set_initial_registers (rts/Libdw.c:288.0) > 0x7f9d70fd7a18 dwfl_thread_getframes (/usr/lib/x86_64 > -linux-gnu/libdw-0.170.so) > 0x7f9d70fd7efc dwfl_getthread_frames (/usr/lib/x86_64 > -linux-gnu/libdw-0.170.so) > 0x4a3eb6 libdwGetBacktrace (rts/Libdw.c:257.0) > 0x474de3 rtsFatalInternalErrorFn > (rts/RtsMessages.c:171.0) > 0x474ad0 barf (rts/RtsMessages.c:48.0) > 0x474b02 errorBelch (rts/RtsMessages.c:67.0) > 0x479273 threadPaused (rts/ThreadPaused.c:318.0) > 0x48ccdb stg_returnToSched > (rts/StgStartup.cmm:117.1) > 0x48f428 stg_enter_info > (rts/HeapStackCheck.cmm:166.1) > 0x45fd18 > integerzmgmp_GHCziIntegerziType_minusInteger_info > (/home/omer/haskell/test) > > (GHC version 8.4.2 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > zsh: abort (core dumped) ./T2783 +RTS -DS > }}} > > memo001: > > {{{ > memo001: internal error: ASSERTION FAILED: file rts/sm/GCAux.c, line 44 > > (GHC version 8.5.20180612 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > zsh: abort (core dumped) ./memo001 +RTS -DS -A10k > }}} New description: It seems like some of the sanity checks fail when running the test suite. To reproduce, run the test suite using: {{{ make EXTRA_HC_OPTS='-debug -rtsopts' WAY=sanity THREADS=12 }}} Results: {{{ Unexpected failures: rts/T2783.run T2783 [bad exit code] (sanity) rts/flags/T12870e.run T12870e [bad stdout] (sanity) rts/flags/T12870f.run T12870f [bad stdout] (sanity) ../../libraries/base/tests/length001.run length001 [bad exit code] (sanity) ../../libraries/ghc-heap/tests/heap_all.run heap_all [bad exit code] (sanity) rts/T7919.run T7919 [bad exit code] (sanity) ../../libraries/base/tests/memo001.run memo001 [bad exit code] (sanity) ../../libraries/hpc/tests/raytrace/hpc_raytrace.run hpc_raytrace [bad exit code] (sanity) }}} T2783: {{{ T2783: internal error: ASSERTION FAILED: file rts/ThreadPaused.c, line 314 Stack trace: test: Failed to get stack frames of current process: no matching address range: Success 0x4a3fbd set_initial_registers (rts/Libdw.c:288.0) 0x7f9d70fd7a18 dwfl_thread_getframes (/usr/lib/x86_64 -linux-gnu/libdw-0.170.so) 0x7f9d70fd7efc dwfl_getthread_frames (/usr/lib/x86_64 -linux-gnu/libdw-0.170.so) 0x4a3eb6 libdwGetBacktrace (rts/Libdw.c:257.0) 0x474de3 rtsFatalInternalErrorFn (rts/RtsMessages.c:171.0) 0x474ad0 barf (rts/RtsMessages.c:48.0) 0x474b02 errorBelch (rts/RtsMessages.c:67.0) 0x479273 threadPaused (rts/ThreadPaused.c:318.0) 0x48ccdb stg_returnToSched (rts/StgStartup.cmm:117.1) 0x48f428 stg_enter_info (rts/HeapStackCheck.cmm:166.1) 0x45fd18 integerzmgmp_GHCziIntegerziType_minusInteger_info (/home/omer/haskell/test) (GHC version 8.4.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./T2783 +RTS -DS }}} memo001: {{{ memo001: internal error: ASSERTION FAILED: file rts/sm/GCAux.c, line 44 (GHC version 8.5.20180612 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./memo001 +RTS -DS -A10k }}} length001: {{{ length001: Stack space overflow: current size 33624 bytes. length001: Use `+RTS -Ksize -RTS' to increase it. }}} Note that the test is run with `-K8m`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 09:34:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 09:34:37 -0000 Subject: [GHC] #15265: Print result summary in test suite when interrupted In-Reply-To: <043.f6136d5e515deaf3f2a252d8637b12b1@haskell.org> References: <043.f6136d5e515deaf3f2a252d8637b12b1@haskell.org> Message-ID: <058.442415cde4be824515b6c1bfcc49b361@haskell.org> #15265: Print result summary in test suite when interrupted -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: patch Priority: lowest | Milestone: Component: Test Suite | Version: 8.5 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:D4841 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"a3c0b42ee6abe0b0fa4cf6f24a7011c5ebcb0225/ghc" a3c0b42/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a3c0b42ee6abe0b0fa4cf6f24a7011c5ebcb0225" testsuite: Print summary even if interrupted Fixes #15265. Reviewers: osa1 Reviewed By: osa1 Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15265 Differential Revision: https://phabricator.haskell.org/D4841 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 09:35:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 09:35:35 -0000 Subject: [GHC] #15265: Print result summary in test suite when interrupted In-Reply-To: <043.f6136d5e515deaf3f2a252d8637b12b1@haskell.org> References: <043.f6136d5e515deaf3f2a252d8637b12b1@haskell.org> Message-ID: <058.a9560c2acba8d2494ef9bc1de7c3b4e1@haskell.org> #15265: Print result summary in test suite when interrupted -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: closed Priority: lowest | Milestone: Component: Test Suite | Version: 8.5 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:D4841 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 12:53:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 12:53:45 -0000 Subject: [GHC] #15216: plugins10 broken In-Reply-To: <046.4e5e0be222cd091f3b7f1aa715644fd7@haskell.org> References: <046.4e5e0be222cd091f3b7f1aa715644fd7@haskell.org> Message-ID: <061.5b38df003133930222b99f0cbadd6fd8@haskell.org> #15216: plugins10 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): * owner: (none) => tdammers -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 13:39:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 13:39:49 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.0bae6e511152e46eb9e626164a6dd92d@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * related: #5129 => #5129 #15225 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 13:52:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 13:52:45 -0000 Subject: [GHC] #14672: Make likelyhood of branches/conditions available throughout the compiler. In-Reply-To: <047.de2c13e36902d9be8400d9448aa09671@haskell.org> References: <047.de2c13e36902d9be8400d9448aa09671@haskell.org> Message-ID: <062.ba54e5af40043a90e86a4b4e58561177@haskell.org> #14672: Make likelyhood of branches/conditions available throughout the compiler. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #849 #15124 | Differential Rev(s): Phab:D4316 Wiki Page: | Phab:D4324 Phab:D4327 -------------------------------------+------------------------------------- Comment (by AndreasK): Doing this right might also help with performance being dependant on the syntactic order of Constructors in the end. For example containers has this note in Data.IntSet.Internal {{{ -- [Note: Order of constructors] -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- The order of constructors of IntMap matters when considering performance. -- Currently in GHC 7.0, when type has 3 constructors, they are matched from -- the first to the last -- the best performance is achieved when the -- constructors are ordered by frequency. -- On GHC 7.0, reordering constructors from Nil | Tip | Bin to Bin | Tip | Nil -- improves the benchmark by circa 10%. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:03:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:03:39 -0000 Subject: [GHC] #12903: SIGINT is not handled in forked process In-Reply-To: <045.73f1eb35eda69f56b71c66e83162bd9f@haskell.org> References: <045.73f1eb35eda69f56b71c66e83162bd9f@haskell.org> Message-ID: <060.713c7cc2954ae2846236433b0748d4f0@haskell.org> #12903: SIGINT is not handled in forked process -------------------------------------+------------------------------------- Reporter: qnikst | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime 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:D2770 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"16c70dafe21ddf8da6085e22994376a9c79628fb/ghc" 16c70daf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="16c70dafe21ddf8da6085e22994376a9c79628fb" Disable T12903 on Darwin due to flakiness Test seems to randomly fail on harbormaster and CircleCI. Disabling it until it can be fixed. Test Plan: make test TEST=T12903 Reviewers: austin, bgamari, simonmar, mpickering Reviewed By: mpickering Subscribers: mpickering, thomie, qnikst GHC Trac Issues: #12903 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:04:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:04:08 -0000 Subject: [GHC] #14392: `make binary-dist` is broken In-Reply-To: <047.e12bb26020da23d6c31cd3a9b180d24f@haskell.org> References: <047.e12bb26020da23d6c31cd3a9b180d24f@haskell.org> Message-ID: <062.382e9fb8cc16f0df36ccb5a6289c04ff@haskell.org> #14392: `make binary-dist` is broken -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Build 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:D4844 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"908edbfbc65049d102c2a861cc5954fa50c772ae/ghc" 908edbf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="908edbfbc65049d102c2a861cc5954fa50c772ae" libiserv: Add license file Test Plan: Run `make bindist` on built tree. Subscribers: rwbarton, thomie, carter, angerman GHC Trac Issues: #14392 Differential Revision: https://phabricator.haskell.org/D4844 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:05:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:05:07 -0000 Subject: [GHC] #15268: Clarify and test the interaction of -with-rtsopts and -rtsopts flags In-Reply-To: <043.5fda2ae4244feef581761e0721041e3e@haskell.org> References: <043.5fda2ae4244feef581761e0721041e3e@haskell.org> Message-ID: <058.3c481861c9ae7a82c7e0d528204be80f@haskell.org> #15268: Clarify and test the interaction of -with-rtsopts and -rtsopts flags -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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:D4840 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"97d141989348b2bd399ff7bc92eaf1a502f59952/ghc" 97d1419/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="97d141989348b2bd399ff7bc92eaf1a502f59952" Update user manual sections for -rtsopts and -with-rtsopts - References to -rtsopts updated for the new ignore and ignoreAll options. - Short description of -rtsopts updated. ignore and ignoreAll are now shown in the man page. - Add a few clarifications about -rtsopts and -with-rtsopts interaction. Reviewers: bgamari, AndreasK Reviewed By: AndreasK Subscribers: Phyx, rwbarton, thomie, carter GHC Trac Issues: #15268 Differential Revision: https://phabricator.haskell.org/D4840 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:05:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:05:23 -0000 Subject: [GHC] #15184: T4442 fails on i386 In-Reply-To: <043.2aff333ef7aff4746a063eeba88c2731@haskell.org> References: <043.2aff333ef7aff4746a063eeba88c2731@haskell.org> Message-ID: <058.f8f930c427e49f27cd8797708e9cad65@haskell.org> #15184: T4442 fails on i386 -------------------------------------+---------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4838 Wiki Page: | -------------------------------------+---------------------------------- Comment (by Ben Gamari ): In [changeset:"ca7653a97e660e95e2a52713cb0a9417c1c239ae/ghc" ca7653a9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ca7653a97e660e95e2a52713cb0a9417c1c239ae" testsuite: Fix T4442 on i386 Test Plan: Validate on i386 Reviewers: tdammers Reviewed By: tdammers Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15184 Differential Revision: https://phabricator.haskell.org/D4838 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:05:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:05:37 -0000 Subject: [GHC] #15237: New SRT scheme breaks -fvia-C In-Reply-To: <046.e3fad0365f09ac73a9b55199ebd3f969@haskell.org> References: <046.e3fad0365f09ac73a9b55199ebd3f969@haskell.org> Message-ID: <061.829c98358b81ae5b699b757150aab87f@haskell.org> #15237: New SRT scheme breaks -fvia-C -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4837 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0238a6c78102d43dae2f56192bd3486e4f9ecf1d/ghc" 0238a6c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0238a6c78102d43dae2f56192bd3486e4f9ecf1d" UNREG: PprC: add support for of W32 literals Today UNREG build fails to generate sub-word literals: ``` rts_dist_HC rts/dist/build/StgStartup.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.5.20180612 for x86_64-unknown-linux): pprStatics: cannot emit a non-word-sized static literal W32 ``` The change allows combining two subwords into one word. Signed-off-by: Sergei Trofimovich Reviewers: simonmar, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15237 Differential Revision: https://phabricator.haskell.org/D4837 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:05:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:05:52 -0000 Subject: [GHC] #15259: Out-of-scope-variables error still can be deferred in ghci In-Reply-To: <049.79f743e34e707788f506b428cc286905@haskell.org> References: <049.79f743e34e707788f506b428cc286905@haskell.org> Message-ID: <064.ebf654b99ec5d695355a9bbbcbd58909@haskell.org> #15259: Out-of-scope-variables error still can be deferred in ghci -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: tdammers Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14963 | Differential Rev(s): Phab:D4830 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4a931665e41be2621abe4458b64190123109b746/ghc" 4a931665/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4a931665e41be2621abe4458b64190123109b746" Disable `-fdefer-out-of-scope-variables` in ghci. We have already disabled `-fdefer-type-errors` and `-fdefer-typed-holes` in ghci. This patch disables `-fdefer-out-of-scope-variables` as well. Fixes Trac #15259, as well as #14963. Test Plan: make test TEST="T15259 T14963a T14963b T14963c" Reviewers: bgamari, tdammers Reviewed By: tdammers Subscribers: tdammers, rwbarton, thomie, carter GHC Trac Issues: #15259, #14963 Differential Revision: https://phabricator.haskell.org/D4830 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:05:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:05:52 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.f6ec9d19c42c506a7f31c1c88d9dbff6@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: patch Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/should_run/T14963 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4833 Wiki Page: | Phab:D4830 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4a931665e41be2621abe4458b64190123109b746/ghc" 4a931665/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4a931665e41be2621abe4458b64190123109b746" Disable `-fdefer-out-of-scope-variables` in ghci. We have already disabled `-fdefer-type-errors` and `-fdefer-typed-holes` in ghci. This patch disables `-fdefer-out-of-scope-variables` as well. Fixes Trac #15259, as well as #14963. Test Plan: make test TEST="T15259 T14963a T14963b T14963c" Reviewers: bgamari, tdammers Reviewed By: tdammers Subscribers: tdammers, rwbarton, thomie, carter GHC Trac Issues: #15259, #14963 Differential Revision: https://phabricator.haskell.org/D4830 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:06:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:06:07 -0000 Subject: [GHC] #15180: Make Control.Exception.throw levity polymorphic In-Reply-To: <049.93e817224f99000e45e381c766dae62b@haskell.org> References: <049.93e817224f99000e45e381c766dae62b@haskell.org> Message-ID: <064.1e6befffd534eb6a5c0673e7bc64ccd6@haskell.org> #15180: Make Control.Exception.throw levity polymorphic -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | LevityPolymorphism, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/typecheck/should_compile/T15180.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4827 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8ae7c1b5033beba576a2d9ffeb9f148bff220482/ghc" 8ae7c1b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8ae7c1b5033beba576a2d9ffeb9f148bff220482" Make Control.Exception.throw levity polymorphic. Test Plan: Validate. Reviewers: hvr, bgamari, sighingnow Reviewed By: sighingnow Subscribers: tdammers, sighingnow, rwbarton, thomie, carter GHC Trac Issues: #15180 Differential Revision: https://phabricator.haskell.org/D4827 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:06:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:06:08 -0000 Subject: [GHC] #15228: Remove use of showSDocUnsafe in extending_ghc.rst In-Reply-To: <049.650bd7ca58a3da7c4bb024d6426a0cdd@haskell.org> References: <049.650bd7ca58a3da7c4bb024d6426a0cdd@haskell.org> Message-ID: <064.5474448dc48c0f9741b4242ee62880e3@haskell.org> #15228: Remove use of showSDocUnsafe in extending_ghc.rst -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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:D4815 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:06:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:06:18 -0000 Subject: [GHC] #15240: GHCi's :doc doesn't find the documentation for some class methods In-Reply-To: <046.ede54e8388156191497230366321bb0a@haskell.org> References: <046.ede54e8388156191497230366321bb0a@haskell.org> Message-ID: <061.00a82c4b659b0edd8718cf728d040bb3@haskell.org> #15240: GHCi's :doc doesn't find the documentation for some class methods -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: sjakobi Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 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:D4816 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:06:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:06:23 -0000 Subject: [GHC] #11259: Use system runtime linker in GHCi on PowerPC 64 bit In-Reply-To: <047.f1dbe111d1a2b1b825a51a6a842cbde6@haskell.org> References: <047.f1dbe111d1a2b1b825a51a6a842cbde6@haskell.org> Message-ID: <062.7752baa4802650660dcfa3ce4b0d7df6@haskell.org> #11259: Use system runtime linker in GHCi on PowerPC 64 bit -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: GHCi crash | Test Case: ghcilink004, | prog001, and 11 more Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5f5d0c9d43bbab922582f437c4a1a3f06ff3fd0e/ghc" 5f5d0c9d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5f5d0c9d43bbab922582f437c4a1a3f06ff3fd0e" Mark test broken on powerpc64[le] Test num009 fails different results. #15062 lists more issues on other platforms. Test T14894 fails because DWARF support is not implemented in the PowerPC native code backend. T5435_v_asm_b fails because the runtime linker is not implemented for PowerPC 64-bit systems. Test Plan: validate Reviewers: bgamari, hvr, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #13634, #11261, #11259, #15062 Differential Revision: https://phabricator.haskell.org/D4825 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:06:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:06:23 -0000 Subject: [GHC] #13634: num009 fails on POWER8 In-Reply-To: <047.91c77b7baae4e3fa8bc1163d9b8de491@haskell.org> References: <047.91c77b7baae4e3fa8bc1163d9b8de491@haskell.org> Message-ID: <062.aa9d096d5da0f26b856e9f2004628aca@haskell.org> #13634: num009 fails on POWER8 -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | libraries/base/tests/Numeric/num009 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5f5d0c9d43bbab922582f437c4a1a3f06ff3fd0e/ghc" 5f5d0c9d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5f5d0c9d43bbab922582f437c4a1a3f06ff3fd0e" Mark test broken on powerpc64[le] Test num009 fails different results. #15062 lists more issues on other platforms. Test T14894 fails because DWARF support is not implemented in the PowerPC native code backend. T5435_v_asm_b fails because the runtime linker is not implemented for PowerPC 64-bit systems. Test Plan: validate Reviewers: bgamari, hvr, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #13634, #11261, #11259, #15062 Differential Revision: https://phabricator.haskell.org/D4825 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:06:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:06:23 -0000 Subject: [GHC] #11261: Implement DWARF debugging on powerpc64 In-Reply-To: <047.fcb308b656617448e39264eeafa29658@haskell.org> References: <047.fcb308b656617448e39264eeafa29658@haskell.org> Message-ID: <062.5cc27d9dd858753433e98e6d096f9b20@haskell.org> #11261: Implement DWARF debugging on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.6.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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5f5d0c9d43bbab922582f437c4a1a3f06ff3fd0e/ghc" 5f5d0c9d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5f5d0c9d43bbab922582f437c4a1a3f06ff3fd0e" Mark test broken on powerpc64[le] Test num009 fails different results. #15062 lists more issues on other platforms. Test T14894 fails because DWARF support is not implemented in the PowerPC native code backend. T5435_v_asm_b fails because the runtime linker is not implemented for PowerPC 64-bit systems. Test Plan: validate Reviewers: bgamari, hvr, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #13634, #11261, #11259, #15062 Differential Revision: https://phabricator.haskell.org/D4825 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:06:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:06:23 -0000 Subject: [GHC] #15062: num009 is incredibly platform-sensitive In-Reply-To: <046.fd26963ba1ba8046e379799dd9722c15@haskell.org> References: <046.fd26963ba1ba8046e379799dd9722c15@haskell.org> Message-ID: <061.e4212a01071066a2e95f95739faab64c@haskell.org> #15062: num009 is incredibly platform-sensitive -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.2 Resolution: | Keywords: ci-breakage 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:"5f5d0c9d43bbab922582f437c4a1a3f06ff3fd0e/ghc" 5f5d0c9d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5f5d0c9d43bbab922582f437c4a1a3f06ff3fd0e" Mark test broken on powerpc64[le] Test num009 fails different results. #15062 lists more issues on other platforms. Test T14894 fails because DWARF support is not implemented in the PowerPC native code backend. T5435_v_asm_b fails because the runtime linker is not implemented for PowerPC 64-bit systems. Test Plan: validate Reviewers: bgamari, hvr, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #13634, #11261, #11259, #15062 Differential Revision: https://phabricator.haskell.org/D4825 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:06:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:06:44 -0000 Subject: [GHC] #15180: Make Control.Exception.throw levity polymorphic In-Reply-To: <049.93e817224f99000e45e381c766dae62b@haskell.org> References: <049.93e817224f99000e45e381c766dae62b@haskell.org> Message-ID: <064.e5363137122b5e32a193fe9cdc2a3149@haskell.org> #15180: Make Control.Exception.throw levity polymorphic -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: | LevityPolymorphism, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/typecheck/should_compile/T15180.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4827 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:06:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:06:53 -0000 Subject: [GHC] #15240: GHCi's :doc doesn't find the documentation for some class methods In-Reply-To: <046.ede54e8388156191497230366321bb0a@haskell.org> References: <046.ede54e8388156191497230366321bb0a@haskell.org> Message-ID: <061.678c7362d4bd86220ada3a02458eaf19@haskell.org> #15240: GHCi's :doc doesn't find the documentation for some class methods -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: sjakobi Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 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:D4816 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"69b50efe08bdd09de0b4f0208fe52804ad938853/ghc" 69b50efe/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="69b50efe08bdd09de0b4f0208fe52804ad938853" Fix deserialization of docs (#15240) We were using Map.fromDistinctAscList to deserialize a (Map Name HsDocString). As the Names' Uniques had changed, we ended up with an invalid map in which we couldn't lookup certain keys. Switching to Map.fromList fixed the issue. Added comments in several places. Reviewers: alexbiehl, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15240 Differential Revision: https://phabricator.haskell.org/D4816 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:07:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:07:07 -0000 Subject: [GHC] #15228: Remove use of showSDocUnsafe in extending_ghc.rst In-Reply-To: <049.650bd7ca58a3da7c4bb024d6426a0cdd@haskell.org> References: <049.650bd7ca58a3da7c4bb024d6426a0cdd@haskell.org> Message-ID: <064.b9cc266b7f4558499651d7a08d690a65@haskell.org> #15228: Remove use of showSDocUnsafe in extending_ghc.rst -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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:D4815 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d24e73adf7fb33e2c94b7b6c43fe9feb9b23c3a6/ghc" d24e73a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d24e73adf7fb33e2c94b7b6c43fe9feb9b23c3a6" Replace `showSDocUnsafe` with `showSDoc` in extending_ghc.rst ... and fix compile errors. Replace the usage of `showSDocUnsafe` with `showSDoc dflags` in example code in extending_ghc.rts. This example contains several compile errors (missing import and syntax error), this patch also fixes that. Test Plan: [skip ci] Reviewers: bgamari, mpickering Reviewed By: mpickering Subscribers: mpickering, rwbarton, thomie, carter GHC Trac Issues: #15228 Differential Revision: https://phabricator.haskell.org/D4815 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:07:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:07:27 -0000 Subject: [GHC] #14492: Tiered memory allocation restricts available memory In-Reply-To: <044.e21e37476590d999c81ca942af908658@haskell.org> References: <044.e21e37476590d999c81ca942af908658@haskell.org> Message-ID: <059.807d4b7773d794422700e6a019256c31@haskell.org> #14492: Tiered memory allocation restricts available memory -------------------------------------+------------------------------------- Reporter: unode | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.0.2 Resolution: fixed | Keywords: memory ulimit Operating System: Linux | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4215 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"233d8150e672494dc5764d0dad5ea721a56517a1/ghc" 233d8150/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="233d8150e672494dc5764d0dad5ea721a56517a1" rts: Ignore RLIMIT_AS if it is zero Reviewers: erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14492 Differential Revision: https://phabricator.haskell.org/D4811 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:07:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:07:40 -0000 Subject: [GHC] #15237: New SRT scheme breaks -fvia-C In-Reply-To: <046.e3fad0365f09ac73a9b55199ebd3f969@haskell.org> References: <046.e3fad0365f09ac73a9b55199ebd3f969@haskell.org> Message-ID: <061.010579c246c75ea442f3152ad6d16ced@haskell.org> #15237: New SRT scheme breaks -fvia-C -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4837 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:08:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:08:28 -0000 Subject: [GHC] #15184: T4442 fails on i386 In-Reply-To: <043.2aff333ef7aff4746a063eeba88c2731@haskell.org> References: <043.2aff333ef7aff4746a063eeba88c2731@haskell.org> Message-ID: <058.ef9fecef0c207830427a1907e84a0876@haskell.org> #15184: T4442 fails on i386 -------------------------------------+---------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4838 Wiki Page: | -------------------------------------+---------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:26:58 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:26:58 -0000 Subject: [GHC] #14392: `make binary-dist` is broken In-Reply-To: <047.e12bb26020da23d6c31cd3a9b180d24f@haskell.org> References: <047.e12bb26020da23d6c31cd3a9b180d24f@haskell.org> Message-ID: <062.25efd926ff7f93342c03d2326a5151bd@haskell.org> #14392: `make binary-dist` is broken -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Build 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:D4844 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 Comment: This should now be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:29:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:29:33 -0000 Subject: [GHC] #14601: Remove uses of unsafeGlobalDynFlags for -fopt-coercions In-Reply-To: <046.d361ab7de37c58253c96beea1e2ddfca@haskell.org> References: <046.d361ab7de37c58253c96beea1e2ddfca@haskell.org> Message-ID: <061.c9815d445dccb189fe3f8398a32615eb@haskell.org> #14601: Remove uses of unsafeGlobalDynFlags for -fopt-coercions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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:D4774 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * differential: => Phab:D4774 * resolution: => fixed * milestone: => 8.6.1 Comment: This was fixed with 64c71ce956af3af593a46ef0d615c7f6fe6ecece. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:31:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:31:09 -0000 Subject: [GHC] #15272: Handle implied flags more intuitively Message-ID: <047.07f59a904afd8a010ee2318a873a6b9c@haskell.org> #15272: Handle implied flags more intuitively -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14963 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Many flags in GHC imply other flags. For example, enabling `-fdefer-type- errors` also enables `-fdefer-type-holes` and `-fdefer-out-of-scope- variables`: {{{ GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help Prelude> :set options currently set: none. base language is: Haskell2010 with the following modifiers: -XNoDatatypeContexts -XNondecreasingIndentation GHCi-specific dynamic flag settings: other dynamic, non-language, flag settings: -fignore-optim-changes -fignore-hpc-changes -fimplicit-import-qualified warning settings: Prelude> :set -fdefer-type -fdefer-type-errors -fdefer-typed-holes Prelude> :set -fdefer-type-errors Prelude> :set options currently set: none. base language is: Haskell2010 with the following modifiers: -XNoDatatypeContexts -XNondecreasingIndentation GHCi-specific dynamic flag settings: other dynamic, non-language, flag settings: -fdefer-type-errors -fdefer-typed-holes -fdefer-out-of-scope-variables -fignore-optim-changes -fignore-hpc-changes -fimplicit-import-qualified warning settings: }}} This is fine. Disabling previously enabled flags does not disable the implied flags: `-fno-defer-type-errors` does not also set `-fno-defer-type-holes` and `-fno-defer-out-of-scope-variables`. This is also fine in principle; otherwise, setting `-fdefer-type-holes -fno-defer-type-errors` would do the unintuitive thing of setting neither flag. But it does lead to unintuitive behavior when the implied flags have never been touched explicitly: setting `-fdefer-type-errors`, and then later `-fno-defer-type-errors`, leaves `-fdefer-type-holes` and `-fdefer-out-of- scope-variables` set, even though the user never asked for them: {{{ Prelude> :set -fdefer-type-errors Prelude> :set options currently set: none. base language is: Haskell2010 with the following modifiers: -XNoDatatypeContexts -XNondecreasingIndentation GHCi-specific dynamic flag settings: other dynamic, non-language, flag settings: -fdefer-type-errors -fdefer-typed-holes -fdefer-out-of-scope-variables -fignore-optim-changes -fignore-hpc-changes -fimplicit-import-qualified warning settings: Prelude> :set -fno-defer-type-errors Prelude> :set options currently set: none. base language is: Haskell2010 with the following modifiers: -XNoDatatypeContexts -XNondecreasingIndentation GHCi-specific dynamic flag settings: other dynamic, non-language, flag settings: -fdefer-typed-holes <- These two are -fdefer-out-of-scope-variables <- unexpected! -fignore-optim-changes -fignore-hpc-changes -fimplicit-import-qualified warning settings: }}} So we have a conundrum: when unsetting a flag, we may or may not need to unset the options it implies - neither is always correct, so in order to figure out what to do, we need to know *why* the flag was set. But it's even worse: if we have a flag X, and two other flags A and B, both of which imply X, and we first set A and B, and then unset B, we would have to keep X set, because otherwise we would break A. But if we then also unset A, we would have to also unset X. Tracking which option implicitly enabled which other option, and correctly resolving that, seems like terribly messy business. So I propose a different solution: 1. Maintain one set of `DynFlags` that holds only those flags that were requested explicitly. Setting `-fdefer-type-errors` would only set `Opt_DeferTypeErrors` in this set, but none of the implied flags; and `-fno-defer-type-errors` would simply unset `Opt_DeferTypeErrors`. 2. Maintain another set of `DynFlags` that holds the effective flags: we can always calculate these based on the explicit flags. We could either do this on the fly, just before running the actual compilation / evaluation, or we could keep the data structure around and only update it when the explicit flags have changed. This way, setting and unsetting flags will always do the right thing, and we don't throw away the information about which flags were set explicitly. This is probably more relevant in GHCi, because in plain GHC, one would typically just set all the needed flags at once and then never change them again until the next run; but in GHCi, modifying compiler flags between evaluations is a common thing to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:33:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:33:33 -0000 Subject: [GHC] #15268: Clarify and test the interaction of -with-rtsopts and -rtsopts flags In-Reply-To: <043.5fda2ae4244feef581761e0721041e3e@haskell.org> References: <043.5fda2ae4244feef581761e0721041e3e@haskell.org> Message-ID: <058.dde8c252a37b27e575caee384c6fb3c1@haskell.org> #15268: Clarify and test the interaction of -with-rtsopts and -rtsopts flags -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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:D4840 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 14:38:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 14:38:45 -0000 Subject: [GHC] #15272: Handle implied flags more intuitively In-Reply-To: <047.07f59a904afd8a010ee2318a873a6b9c@haskell.org> References: <047.07f59a904afd8a010ee2318a873a6b9c@haskell.org> Message-ID: <062.824bba4ad4dd80776e9508227201cc94@haskell.org> #15272: Handle implied flags more intuitively -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #14963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Hmm, would that still lead to the desired outcome if the user specifies `-fdefer-type-errors -fno-defer-type-holes`? Currently, I expect that after this, `defer-type-holes` is disabled. Under your scheme, it seems that `-fno-defered-type-holes` does not actually affect the list of ''explicit flags'' (because there is no `Opt_DeferTypeHoles` to undo), but then when we calculate the set of ''explicit flags'' `Opt_DeferTypeErrors` will imply `Opt_DeferTypeHoles`, and that flag will be enabled – against the user’s intention, I presume? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 15:00:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 15:00:08 -0000 Subject: [GHC] #15259: Out-of-scope-variables error still can be deferred in ghci In-Reply-To: <049.79f743e34e707788f506b428cc286905@haskell.org> References: <049.79f743e34e707788f506b428cc286905@haskell.org> Message-ID: <064.9b18fc518d24986b58a8439a52366c23@haskell.org> #15259: Out-of-scope-variables error still can be deferred in ghci -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: tdammers Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14963 | Differential Rev(s): Phab:D4830 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 15:16:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 15:16:04 -0000 Subject: [GHC] #15225: `-fno-state-hack` produces incorrect results in nofib In-Reply-To: <047.20e2da7aa2a2e4221951af3d8807d250@haskell.org> References: <047.20e2da7aa2a2e4221951af3d8807d250@haskell.org> Message-ID: <062.51cc50e98e9f2e5a09190fd5299bd2af@haskell.org> #15225: `-fno-state-hack` produces incorrect results in nofib -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7411 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): So here's a hint. The documentation to `unsafeUseAsCString` mentions this: > After calling this function the `CString` shares the underlying byte > buffer with the original `ByteString`. Thus **modifying the > `CString`**, either in C, or **using poke**, will cause the contents > of the `ByteString` to change, **breaking referential transparency**. > Other `ByteStrings` created by sharing (such as those produced via > 'take' or 'drop') will also reflect these changes. Modifying the > `CString` will break referential transparency. To avoid this, use > `useAsCString`, which makes a copy of the original `ByteString`. (emphasis mine). And then in the `fasta/Main.hs` source code, we see this: {{{#!hs unsafeUseAsCString line $ \ptr -> do --- snip --- plusPtr ptr i `poke` unsafeIndex lookupTable newseed --- snip --- }}} In other words, `fasta` does exactly what the documentation says not to do. Which would suggest that the state hack itself isn't really to blame, it just causes different sharing behavior. I'll run a few tests to get more certainty here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 15:22:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 15:22:06 -0000 Subject: [GHC] #15225: `-fno-state-hack` produces incorrect results in nofib In-Reply-To: <047.20e2da7aa2a2e4221951af3d8807d250@haskell.org> References: <047.20e2da7aa2a2e4221951af3d8807d250@haskell.org> Message-ID: <062.7bbebe9229b7367af3d8682fd36cd1be@haskell.org> #15225: `-fno-state-hack` produces incorrect results in nofib -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7411 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Yikes! Indeed that does look quite suspicious since `line` is also used elsewhere in this block. Sounds like this is the culprit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 16:29:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 16:29:09 -0000 Subject: [GHC] #14170: 8.2.1 regression: GHC fails to simplify `natVal` In-Reply-To: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> References: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> Message-ID: <063.5b570e645602f64d473eed04cb875d16@haskell.org> #14170: 8.2.1 regression: GHC fails to simplify `natVal` -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Bodigrim Type: bug | Status: patch Priority: high | Milestone: 8.6.1 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:D4212 Wiki Page: | -------------------------------------+------------------------------------- Comment (by darchon): I would really like this patch to land in 8.6.1 as our Clash Haskell-to- Hardware compiler has to work a lot harder with these unsimplified naturals. I just saw that a 8.6 branch was created on git, hence why I'm posting now. Patch D4212 seems to have gotten the OKs, what still needs to happen to it before it lands in HEAD and can end up in the 8.6 branch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 16:58:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 16:58:04 -0000 Subject: [GHC] #15273: Datatypes with CUSKs should quantify over unknown kinds Message-ID: <047.ec7ed2596e5045a5e66eba34c3a673fe@haskell.org> #15273: Datatypes with CUSKs should quantify over unknown kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4845 | Wiki Page: -------------------------------------+------------------------------------- In [https://github.com/ghc-proposals/ghc-proposals/pull/54 the future], we will be able to give full kind signatures to datatype declarations. But in the present, we use CUSKs to write kind signatures. However, consider {{{#!hs data T (a :: Proxy k) }}} That has a CUSK, according to the CUSK rules. Yet we don't know the kind of `k`. Currently, this definition is rejected, accusing the user of lying about having a complete kind. However, let's instead pretend the user had written {{{#!hs type T :: Proxy k -> Type data T a }}} After all, that's what the CUSK is shorthand for. In this case, it's clear that we should infer `T :: forall k1 (k :: k1). Proxy k -> Type`, just the way we would do with a term-level type signature. This turns out to be quite easy. See Phab:D4845. This change allows strictly more programs to be accepted, and I think it falls under the threshold for requiring a proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 19:07:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 19:07:23 -0000 Subject: [GHC] #15195: Merge -XPolyKinds with -XTypeInType In-Reply-To: <047.c44c81564ca3186b8f7d6c799db31ecf@haskell.org> References: <047.c44c81564ca3186b8f7d6c799db31ecf@haskell.org> Message-ID: <062.fbb98a14e4d1fa1413e67f32bd17eb9f@haskell.org> #15195: Merge -XPolyKinds with -XTypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: int-index Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4748 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"d650729f9a0f3b6aa5e6ef2d5fba337f6f70fa60/ghc" d650729/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d650729f9a0f3b6aa5e6ef2d5fba337f6f70fa60" Embrace -XTypeInType, add -XStarIsType Summary: Implement the "Embrace Type :: Type" GHC proposal, .../ghc-proposals/blob/master/proposals/0020-no-type-in-type.rst GHC 8.0 included a major change to GHC's type system: the Type :: Type axiom. Though casual users were protected from this by hiding its features behind the -XTypeInType extension, all programs written in GHC 8+ have the axiom behind the scenes. In order to preserve backward compatibility, various legacy features were left unchanged. For example, with -XDataKinds but not -XTypeInType, GADTs could not be used in types. Now these restrictions are lifted and -XTypeInType becomes a redundant flag that will be eventually deprecated. * Incorporate the features currently in -XTypeInType into the -XPolyKinds and -XDataKinds extensions. * Introduce a new extension -XStarIsType to control how to parse * in code and whether to print it in error messages. Test Plan: Validate Reviewers: goldfire, hvr, bgamari, alanz, simonpj Reviewed By: goldfire, simonpj Subscribers: rwbarton, thomie, mpickering, carter GHC Trac Issues: #15195 Differential Revision: https://phabricator.haskell.org/D4748 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 19:14:58 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 19:14:58 -0000 Subject: [GHC] #15195: Merge -XPolyKinds with -XTypeInType In-Reply-To: <047.c44c81564ca3186b8f7d6c799db31ecf@haskell.org> References: <047.c44c81564ca3186b8f7d6c799db31ecf@haskell.org> Message-ID: <062.2b19acb1a4b96ed26a5bf734f14d8052@haskell.org> #15195: Merge -XPolyKinds with -XTypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: int-index Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4748 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: Thanks, @int-index, for seeing this through. Tests are plentiful, but not new. int-index, add a test case if you're particularly inspired to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 21:06:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 21:06:21 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.0e82c0172c14c2a506af72c027d8e9a3@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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:D4783 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Thanks! The new error messages look good to me! I'll give dfeuer a few days to respond to your review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 22:02:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 22:02:13 -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.b2531edeff05ad5f2a21343ff9d14bbc@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): Phab:D3745 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ntc2): * status: closed => new * resolution: fixed => Comment: Ran into one that's still broken: docs/users_guide/glasgow_exts.rst:2 `__. I can't find the corresponding paper on research.microsoft.com, but there's a copy on haskell.org: https://www.haskell.org/ghc/docs/papers/th2.ps. PR on GitHub: https://github.com/ghc/ghc/pull/146. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 22:15:50 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 22:15:50 -0000 Subject: [GHC] #14170: 8.2.1 regression: GHC fails to simplify `natVal` In-Reply-To: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> References: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> Message-ID: <063.0167552fa64418c189cc95c7bb2d98db@haskell.org> #14170: 8.2.1 regression: GHC fails to simplify `natVal` -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Bodigrim Type: bug | Status: patch Priority: high | Milestone: 8.6.1 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:D4212 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Bodigrim): +1 to have it merged into 8.6.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 22:20:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 22:20:28 -0000 Subject: [GHC] #15273: Datatypes with CUSKs should quantify over unknown kinds In-Reply-To: <047.ec7ed2596e5045a5e66eba34c3a673fe@haskell.org> References: <047.ec7ed2596e5045a5e66eba34c3a673fe@haskell.org> Message-ID: <062.d2d670a29855da7a395013c03530796c@haskell.org> #15273: Datatypes with CUSKs should quantify over unknown kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4845 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes I agree. Trac #11648 is highly relevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 22:53:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 22:53:42 -0000 Subject: [GHC] #15269: Qualified Names in --show-iface output In-Reply-To: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> References: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> Message-ID: <061.9b8cc7a267ff79c391ab271e4df7dd83@haskell.org> #15269: Qualified Names in --show-iface output -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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 simonpj): I didn't know this, but indeed `--show-iface` doesn't seem to show qualified names, which is confusing in unfoldings. (It might be reasonable not to quality names from the current module.) This is controlled by the pretty-printing style. I'm not sure how `--show-iface` invokes the pretty-printer, but it looks as though `defaultUserStyle` omits the module qualifier on everything, which isn't what we want here {{{ defaultUserStyle :: DynFlags -> PprStyle defaultUserStyle dflags = mkUserStyle dflags neverQualify AllTheWay }}} Note that `neverQualify`. So I think you could fix it for all of `--show-iface` not just for docstring. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 22:55:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 22:55:42 -0000 Subject: [GHC] #15274: Numerous validation failures when building GHC with LLVM Message-ID: <046.83a071bfa50c4ead83f977af9cb85f1c@haskell.org> #15274: Numerous validation failures when building GHC with LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (LLVM) | 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 CircleCI x86_64/Linux LLVM way exhibits numerous testsuite failures: {{{ TEST="ClosedFam1TH T10508_api T10828 T10891 T11341 T11345 T11463 T11721_TH T11797 T12403 T12478_1 T12646 T12962 T13642 T13887 T14060 T1835 T2222 T2552 T2700 T3920 T4135 T4188 T5037 T5358 T5362 T5363 T5559 T680 T7477 T8761 T8884 T8953 T9064 T9262 T9692 TH_PromotedList TH_RichKinds TH_RichKinds2 TH_Roles3 TH_TyInstWhere2 TH_foreignCallingConventions TH_reifyDecl1 TH_reifyDecl2 TH_reifyInstances TH_repGuard TH_repPrim TH_repPrim2 TH_repUnboxedTuples posix002 prof-doc-fib prof-doc-last profinline001 prog001 scc001 scc002 scc003 scc005" }}} Unfortunately, most of these appear to be segmentation faults and similar, suggesting miscompilation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 23:27:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 23:27:31 -0000 Subject: [GHC] #15245: Data family promotion is possible In-Reply-To: <048.2bfd93318ecc0fe9c70183281e7bf50f@haskell.org> References: <048.2bfd93318ecc0fe9c70183281e7bf50f@haskell.org> Message-ID: <063.a86371289775afd9f67a98cd7a65d063@haskell.org> #15245: Data family promotion is possible -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | dependent/should_fail/T15245.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4748 Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * status: new => merge * testcase: => dependent/should_fail/T15245.hs * differential: => D4748 * component: Documentation => Compiler (Type checker) * failure: None/Unknown => GHC accepts invalid program Comment: This is now fixed in HEAD by disallowing promotion of data families. If anyone needs this feature, it would be appropriate to create a feature request. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 14 23:33:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Jun 2018 23:33:49 -0000 Subject: [GHC] #15245: Data family promotion is possible In-Reply-To: <048.2bfd93318ecc0fe9c70183281e7bf50f@haskell.org> References: <048.2bfd93318ecc0fe9c70183281e7bf50f@haskell.org> Message-ID: <063.d60399f1cfa68e3e9891573e92ab897b@haskell.org> #15245: Data family promotion is possible -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | dependent/should_fail/T15245.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4748 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: D4748 => Phab:D4748 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 01:03:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 01:03:27 -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.54b352402067ef1f2d2cf85febec4852@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.6.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): As mentioned in the description the problem happens when compiling one particular file, it would be nice if somebody could reduce the test case to that so we could profile the compiler compiling that one file. This issues is still reproducible in ghc 8.4.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 03:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 03:21:06 -0000 Subject: [GHC] #15275: AArch64 validation fails with many invalid relocations Message-ID: <046.09db5dc304d31321bf750c17c4d53c7c@haskell.org> #15275: AArch64 validation fails with many invalid relocations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Linking) | 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: -------------------------------------+------------------------------------- Test ways requiring the RTS linker (e.g. `ext-interp`) are failing due to the `assert(isInt64(32, addend));` assertion in the `COMPAT_R_AARCH64_ADR_PREL_PG_HI21` of `encodeAddendAarch64`. One such relocation is, {{{ RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 000000000000001c R_AARCH64_ADR_PREL_PG_HI21 stg_upd_frame_info }}} although there are plenty of others. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 03:23:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 03:23:36 -0000 Subject: [GHC] #15275: AArch64 validation fails with many invalid relocations In-Reply-To: <046.09db5dc304d31321bf750c17c4d53c7c@haskell.org> References: <046.09db5dc304d31321bf750c17c4d53c7c@haskell.org> Message-ID: <061.0ecd2df6a15051c89987e561a27461f1@haskell.org> #15275: AArch64 validation fails with many invalid relocations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Linking) | 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): It seems to me that this may just be the result of us not building with `-fPIC` by default. It seems like fixing this would likely resolve this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 07:47:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 07:47:32 -0000 Subject: [GHC] #15276: Bogus type in typechecker error recovery Message-ID: <046.5e2e8780e9e4fc166714aa3dda0e680b@haskell.org> #15276: Bogus type in typechecker error recovery -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- If the typechecker sees {{{ let f = in }}} and there's a type error in ``, GHC recovers from the error, binds `f` to "a type that should cause no more trouble", and continues with `` in the hope of finding more type errors. What is "a type that should cause no more trouble"? Well `forall a.a` seems like a good candidate. But, in this commit {{{ commit 6746549772c5cc0ac66c0fce562f297f4d4b80a2 Author: Richard Eisenberg Date: Fri Dec 11 18:19:53 2015 -0500 Add kind equalities to GHC. }}} we made the type look like this: `forall r. forall (a :: TYPE r). a` Alas! That type is ill-formed because the kind `TYPE r` escapes the scope of `f`. I discovered this when beefing up `typeKind` in pursuit of #14939 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 08:10:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 08:10:23 -0000 Subject: [GHC] #15237: New SRT scheme breaks -fvia-C In-Reply-To: <046.e3fad0365f09ac73a9b55199ebd3f969@haskell.org> References: <046.e3fad0365f09ac73a9b55199ebd3f969@haskell.org> Message-ID: <061.052ff4396a15f8fd44a1eb4116b01ede@haskell.org> #15237: New SRT scheme breaks -fvia-C -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4837 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"01c9d95aca12caf5c954320a2a82335b32568554/ghc" 01c9d95a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="01c9d95aca12caf5c954320a2a82335b32568554" UNREG: PprC: add support for of W16 literals (Ticket #15237) Fix UNREG build failure for 32-bit targets. This change is an equivalent of commit 0238a6c78102d43dae2f56192bd3486e4f9ecf1d ("UNREG: PprC: add support for of W32 literals") The change allows combining two subwords into one word on 32-bit targets. Tested on nios2-unknown-linux-gnu. GHC Trac Issues: #15237 Signed-off-by: Sergei Trofimovich }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 08:22:01 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 08:22:01 -0000 Subject: [GHC] #14845: TypeInType, index GADT by constraint witness In-Reply-To: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> References: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> Message-ID: <066.600d832107372b6d2b21ed48cb14b45f@haskell.org> #14845: TypeInType, index GADT by constraint witness -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13895, #15215 | Differential Rev(s): Phab:D4728 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * related: #13895 => #13895, #15215 Comment: #15215 (after fixing the bug in that ticket) is another example of the horrible error message reported in the Description. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 10:05:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 10:05:09 -0000 Subject: [GHC] #15225: `-fno-state-hack` produces incorrect results in nofib In-Reply-To: <047.20e2da7aa2a2e4221951af3d8807d250@haskell.org> References: <047.20e2da7aa2a2e4221951af3d8807d250@haskell.org> Message-ID: <062.034e534d54f0eb405eb20f4358aca5a3@haskell.org> #15225: `-fno-state-hack` produces incorrect results in nofib -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7411 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): I quickly and naively tried just using `useAsCString` instead of `unsafeUseAsCString`, but of course that doesn't quite work - probably because the code relies on actually manipulating the bytestring in place, whereas `useAsCString` creates a copy and manipulates that. So the output no longer matches that of the C implementation, but the `-fno-state-hack` flag no longer causes the output to differ. So I went a step further, and rewrote the relevant part in more idiomatic Haskell, using `ByteString.unfoldrN` instead of manipulating C strings in- place: {{{#!diff commit dc2753f4e10fec79c02ed293b72573f1aeaa2271 Author: Tobias Dammers Date: Fri Jun 15 11:27:36 2018 +0200 Rewrite fasta in more idiomatic Haskell diff --git a/shootout/fasta/Main.hs b/shootout/fasta/Main.hs index 4bd0849..795a470 100644 --- a/shootout/fasta/Main.hs +++ b/shootout/fasta/Main.hs @@ -11,7 +11,9 @@ import Foreign.Ptr import Foreign.Storable import System.Environment import qualified Data.ByteString.Char8 as B +import qualified Data.ByteString as BS import qualified Data.ByteString.Lazy.Char8 as L +import Data.Word (Word8) main = do n <- getArgs >>= readIO.head @@ -27,21 +29,30 @@ make name n0 tbl seed0 = do B.putStrLn name let modulus = 139968 fill ((c,p):cps) j = - let !k = min modulus (floor (fromIntegral modulus * (p::Float) + 1)) - in B.replicate (k - j) c : fill cps k + let !k = min modulus (floor (fromIntegral modulus * (p::Float) + 1)) + in B.replicate (k - j) c : fill cps k fill _ _ = [] lookupTable = B.concat $ fill (scanl1 (\(_,p) (c,q) -> (c,p+q)) tbl) 0 - line = B.replicate 60 '\0' - unsafeUseAsCString line $ \ptr -> do - let make' n !i seed - | n > (0::Int) = do - let newseed = rem (seed * 3877 + 29573) modulus - plusPtr ptr i `poke` unsafeIndex lookupTable newseed - if i+1 >= 60 - then puts line 60 >> make' (n-1) 0 newseed - else make' (n-1) (i+1) newseed - | otherwise = when (i > 0) (puts line i) >> return seed - make' n0 0 seed0 + + let next :: Int -> Maybe (Word8, Int) + next seed = + let newseed = rem (seed * 3877 + 29573) modulus + val = unsafeIndex lookupTable newseed + in Just (val, newseed) + + let make' :: Int -> Int -> IO Int + make' n seed = do + if n <= (0 :: Int) then + return seed + else if n >= 60 then do + let (line, Just newseed) = BS.unfoldrN 60 next seed + puts line 60 + make' (n-60) newseed + else do + let (line, Just newseed) = BS.unfoldrN n next seed + puts line n + return newseed + make' n0 seed0 alu = "GGCCGGGCGCGGTGGCTCACGCCTGTAATCCCAGCACTTTGGGAGGCCGAGGCGGGCGGATCACCTGAGG\ \TCAGGAGTTCGAGACCAGCCTGGCCAACATGGTGAAACCCCGTCTCTACTAAAAATACAAAAATTAGCCGGG\ }}} The patched version produces the correct output regardless of the state hack; however, I haven't done a full profiling run yet to see how it affects performance. However, considering that the unidiomatic version is essentially wrong, and, well, unidiomatic, I'm not so sure whether it told us anything meaningful in the first place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 11:12:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 11:12:50 -0000 Subject: [GHC] #15276: Bogus type in typechecker error recovery In-Reply-To: <046.5e2e8780e9e4fc166714aa3dda0e680b@haskell.org> References: <046.5e2e8780e9e4fc166714aa3dda0e680b@haskell.org> Message-ID: <061.d82fa28819ddf27daa94bb2ee3db0f8e@haskell.org> #15276: Bogus type in typechecker error recovery -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 Simon Peyton Jones ): In [changeset:"807ab222d08c11a4d00064c9835f9ed9f20ffc7c/ghc" 807ab22/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="807ab222d08c11a4d00064c9835f9ed9f20ffc7c" Fix the bind-recovery type This patch uses (forall (a::*). a) for the type to use when recovering from an error in a binding. Previously (Trac #15276) we had (forall r (a :: TYPE r). a), which is ill-kinded. It's quite hard to provoke an error arising from this, because it only happens in programs that have a type error anyway, but in a subequent patch I make typeKind fall over if it returns an ill-scoped kind, and that makes ghci/scripts/T13202 crash without this fix. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 11:12:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 11:12:50 -0000 Subject: [GHC] #14845: TypeInType, index GADT by constraint witness In-Reply-To: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> References: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> Message-ID: <066.efd56172baf7f65b1d903e4434084a6f@haskell.org> #14845: TypeInType, index GADT by constraint witness -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13895, #15215 | Differential Rev(s): Phab:D4728 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2f6069ccf21d7be0e09016896238f417d2492ffa/ghc" 2f6069c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2f6069ccf21d7be0e09016896238f417d2492ffa" Make better "fake tycons" in error recovery Consider (Trac #15215) data T a = MkT ... data S a = ...T...MkT.... If there is an error in the definition of 'T' we add a "fake type constructor" to the type environment, so that we can continue to typecheck 'S'. But we /were not/ adding a fake anything for 'MkT' and so there was an internal error when we met 'MkT' in the body of 'S'. The fix is to add fake tycons for all the 'implicits' of 'T'. This is done by mk_fake_tc in TcTyClsDecls.checkValidTyCl, which now returns a /list/ of TyCons rather than just one. On the way I did some refactoring: * Rename TcTyDecls.tcAddImplicits to tcAddTyConsToGblEnv and make it /include/ the TyCons themeselves as well as their implicits * Some incidental refactoring about tcRecSelBinds. The main thing is that I've avoided creating a HsValBinds that we immediately decompose. That meant moving some deck chairs around. NB: The new error message for the regression test T15215 has the opaque error "Illegal constraint in a type:", flagged in Trac #14845. But that's the fault of the latter ticket. The fix here not to blame. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 11:12:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 11:12:50 -0000 Subject: [GHC] #15215: GHC HEAD internal error when FlexibleContexts isn't enabled In-Reply-To: <050.f3a694ecbd9a7c8505c4c0847398da29@haskell.org> References: <050.f3a694ecbd9a7c8505c4c0847398da29@haskell.org> Message-ID: <065.dd509ba3df472c270d32f93a1622281e@haskell.org> #15215: GHC HEAD internal error when FlexibleContexts isn't enabled -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 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 Simon Peyton Jones ): In [changeset:"2f6069ccf21d7be0e09016896238f417d2492ffa/ghc" 2f6069c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2f6069ccf21d7be0e09016896238f417d2492ffa" Make better "fake tycons" in error recovery Consider (Trac #15215) data T a = MkT ... data S a = ...T...MkT.... If there is an error in the definition of 'T' we add a "fake type constructor" to the type environment, so that we can continue to typecheck 'S'. But we /were not/ adding a fake anything for 'MkT' and so there was an internal error when we met 'MkT' in the body of 'S'. The fix is to add fake tycons for all the 'implicits' of 'T'. This is done by mk_fake_tc in TcTyClsDecls.checkValidTyCl, which now returns a /list/ of TyCons rather than just one. On the way I did some refactoring: * Rename TcTyDecls.tcAddImplicits to tcAddTyConsToGblEnv and make it /include/ the TyCons themeselves as well as their implicits * Some incidental refactoring about tcRecSelBinds. The main thing is that I've avoided creating a HsValBinds that we immediately decompose. That meant moving some deck chairs around. NB: The new error message for the regression test T15215 has the opaque error "Illegal constraint in a type:", flagged in Trac #14845. But that's the fault of the latter ticket. The fix here not to blame. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 11:39:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 11:39:27 -0000 Subject: [GHC] #15276: Bogus type in typechecker error recovery In-Reply-To: <046.5e2e8780e9e4fc166714aa3dda0e680b@haskell.org> References: <046.5e2e8780e9e4fc166714aa3dda0e680b@haskell.org> Message-ID: <061.ab7ad8933aa81cb180d86e8f84ee10b1@haskell.org> #15276: Bogus type in typechecker error recovery -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 11:40:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 11:40:25 -0000 Subject: [GHC] #15215: GHC HEAD internal error when FlexibleContexts isn't enabled In-Reply-To: <050.f3a694ecbd9a7c8505c4c0847398da29@haskell.org> References: <050.f3a694ecbd9a7c8505c4c0847398da29@haskell.org> Message-ID: <065.db559606b02421c02be54a641c39a123@haskell.org> #15215: GHC HEAD internal error when FlexibleContexts isn't enabled -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | dependent/should_fail/T15215 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => dependent/should_fail/T15215 * resolution: => fixed Comment: Thanks for reporting this -- now fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 12:13:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 12:13:56 -0000 Subject: [GHC] #15260: Xmobar crashes with segmentation fault In-Reply-To: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> References: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> Message-ID: <061.d26abcae60b5c682dc76770d60b78595@haskell.org> #15260: Xmobar crashes with segmentation fault ----------------------------------+-------------------------------------- Reporter: Voronwe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by osa1): I wonder if this is a FFI misuse in X11 or xmobar. A `XNextEvent` FFI call overrides an info table pointer: {{{ Hardware watchpoint 2: ((StgClosure*)0x4200029f90)->header.info Old value = (const StgInfoTable *) 0x0 New value = (const StgInfoTable *) 0xcfe1f0 0x00007fdcd3143927 in XNextEvent () from /usr/lib/x86_64-linux- gnu/libX11.so.6 >>> bt #0 0x00007fdcd3143927 in XNextEvent () from /usr/lib/x86_64-linux- gnu/libX11.so.6 #1 0x000000000041385c in XUtil_zdwnextEventzq_info () #2 0x0000000000000011 in ?? () #3 0x0000000000000000 in ?? () }}} (because this is reverse-execution new and old values are swapped, so old value is actually the new value being written by XNextEvent) Before overriding the info table ptr the object is the string `" "`: {{{ >>> call printClosure(0x4200029f90) ghc-prim:GHC.Types.:(0xfa1501, 0xfa02e9) >>> call printClosure(0xfa1501) ghc-prim:GHC.Types.C#(0x32#) >>> call printClosure(0xfa02e9) ghc-prim:GHC.Types.[](0xcfdac8#) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 13:59:31 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 13:59:31 -0000 Subject: [GHC] #15230: unix tests fail under CircleCI's fedora environment In-Reply-To: <046.e75284c38f9e2e606bbb1d369702bf83@haskell.org> References: <046.e75284c38f9e2e606bbb1d369702bf83@haskell.org> Message-ID: <061.b03231ba7921d11742123d4d5d9e1175@haskell.org> #15230: unix tests fail under CircleCI's fedora environment -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 Integration | 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 suspect that this is due to our use of Docker in the CircleCI infrastructure as I am unable to reproduce this under a Fedora VM. I have SSH'd into the CircleCI build machine and tried running `getGroupEntryForName` under `strace`. The relevant bit appears to be: {{{ openat(AT_FDCWD, "/lib64/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 !\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=533864, ...}) = 0 mmap(NULL, 2626088, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f00d3f75000 mprotect(0x7f00d3ff6000, 2093056, PROT_NONE) = 0 mmap(0x7f00d41f5000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x80000) = 0x7f00d41f5000 close(3) = 0 mprotect(0x7f00d41f5000, 4096, PROT_READ) = 0 mprotect(0x7f00d440c000, 4096, PROT_READ) = 0 --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=NULL}} --- rt_sigreturn({mask=[]}) = 0 mprotect(0x7f00d4633000, 4096, PROT_READ) = 0 mprotect(0x7f00d4875000, 12288, PROT_READ) = 0 statfs("/sys/fs/selinux", 0x7ffc3c3aec40) = -1 ENOENT (No such file or directory) statfs("/selinux", 0x7ffc3c3aec40) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/proc/filesystems", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 read(3, "nodev\tsysfs\nnodev\trootfs\nnodev\tr"..., 1024) = 351 read(3, "", 1024) = 0 close(3) = 0 access("/etc/selinux/config", F_OK) = -1 ENOENT (No such file or directory) munmap(0x7f00d6059000, 17156) = 0 rt_sigprocmask(SIG_BLOCK, [HUP USR1 USR2 PIPE ALRM CHLD TSTP URG VTALRM PROF WINCH IO], [], 8) = 0 getpid() = 9044 getpid() = 9044 getpid() = 9044 openat(AT_FDCWD, "/sys/fs/kdbus/0-system/bus", O_RDWR|O_NOCTTY|O_CLOEXEC) = -1 ENOENT (No such file or directory) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 getsockopt(3, SOL_SOCKET, SO_RCVBUF, [212992], [4]) = 0 setsockopt(3, SOL_SOCKET, SO_RCVBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted) setsockopt(3, SOL_SOCKET, SO_RCVBUF, [8388608], 4) = 0 getsockopt(3, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0 setsockopt(3, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted) setsockopt(3, SOL_SOCKET, SO_SNDBUF, [8388608], 4) = 0 connect(3, {sa_family=AF_UNIX, sun_path="/var/run/dbus/system_bus_socket"}, 33) = -1 ENOENT (No such file or directory) getpid() = 9044 close(3) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0 write(2, "getGroupEntryForName: ", 22getGroupEntryForName: ) = 22 write(2, "getGroupEntryForName: does not e"..., 64getGroupEntryForName: does not exist (No such file or directory)) = 64 write(2, "\n", 1 ) = 1 }}} The most interesting line of the above is {{{ connect(3, {sa_family=AF_UNIX, sun_path="/var/run/dbus/system_bus_socket"}, 33) = -1 ENOENT (No such file or directory) }}} which suggests that `dbus` isn't running (which `ps` confirms). Moreover `/var/run/dbus` doesn't exist. However, strangely, `dnf` suggests that the `dbus` package is indeed installed. Moreover, `systemctl status fails: {{{ $ sudo systemctl status Failed to connect to bus: No such file or directory }}} This is somewhat expected given that this is a container and it explains why `dbus` wasn't started. The next question is why this testcase is calling for `dbus` at all. I do see a few mentions of `systemd` in the PAM configuration, although only as optional authentication steps. Perhaps more concerning is this in `/etc/nsswitch.conf`: {{{ passwd: sss files systemd shadow: files sss group: sss files systemd }}} Indeed removing the mentions of `systemd` from these lines allows the test to fail in the expected way: {{{ $ getGroupEntryForName.run/getGroupEntryForName getGroupEntryForName: getGroupEntryForName: does not exist (no such group) }}} It looks like we will need to modify `nsswitch.conf` to eliminate mentions of systemd while building the Docker image. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 14:39:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 14:39:28 -0000 Subject: [GHC] #15269: Qualified Names in --show-iface output In-Reply-To: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> References: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> Message-ID: <061.89659fef5cf9262426acb9bfcd9e5883@haskell.org> #15269: Qualified Names in --show-iface output -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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 sjakobi): `--show-iface` is implemented in `showIface` and uses `defaultDumpStyle dflags`, which in turn uses `neverQualify`: {{{ defaultDumpStyle :: DynFlags -> PprStyle -- Print without qualifiers to reduce verbosity, unless -dppr-debug defaultDumpStyle dflags | hasPprDebug dflags = PprDebug | otherwise = PprDump neverQualify }}} I think I'll try to make a custom `PrintUnqualified` style that qualifies (with module names) any names that are not defined in the current module, and apply this style to the entire `--show-iface` output. Does this sound like a good idea? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 14:42:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 14:42:34 -0000 Subject: [GHC] #15269: Qualified Names in --show-iface output In-Reply-To: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> References: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> Message-ID: <061.c6cda48610d01a796fe3788d3bc59afa@haskell.org> #15269: Qualified Names in --show-iface output -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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 simonpj): Yes, sounds good to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 14:48:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 14:48:32 -0000 Subject: [GHC] #15277: Move field name resolution to the type-checker Message-ID: <049.c9dde971331d5b48a8a6e9da784dd7ee@haskell.org> #15277: Move field name resolution to the type-checker -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: ORF | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15149 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Per discussion on #15149, we plan to make the type-checker responsible for all field name lookup in record construction, pattern-matching and updates. This should be simpler than the current story and let us get rid of `tcg_field_env`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 14:48:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 14:48:38 -0000 Subject: [GHC] #15277: Move field name resolution to the type-checker In-Reply-To: <049.c9dde971331d5b48a8a6e9da784dd7ee@haskell.org> References: <049.c9dde971331d5b48a8a6e9da784dd7ee@haskell.org> Message-ID: <064.275f03f3b4c24b02417a7edba90dc29a@haskell.org> #15277: Move field name resolution to the type-checker -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15149 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * owner: (none) => adamgundry -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 14:50:31 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 14:50:31 -0000 Subject: [GHC] #15149: Identical distinct type family fields miscompiled In-Reply-To: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> References: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> Message-ID: <066.a687c063b0e3165cb22f1b4ccdd284e8@haskell.org> #15149: Identical distinct type family fields miscompiled -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: adamgundry Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T15149 Blocked By: | Blocking: Related Tickets: #14747, #15277 | Differential Rev(s): Phab:D4821 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * related: #14747 => #14747, #15277 Comment: I think Phab:D4821 should be good to go with the small fix, and I've opened #15277 for the bigger refactoring. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 15:55:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 15:55:50 -0000 Subject: [GHC] #15230: unix tests fail under CircleCI's fedora environment In-Reply-To: <046.e75284c38f9e2e606bbb1d369702bf83@haskell.org> References: <046.e75284c38f9e2e606bbb1d369702bf83@haskell.org> Message-ID: <061.56473c98eeee03093307505932a946cb@haskell.org> #15230: unix tests fail under CircleCI's fedora environment -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 Integration | 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:D4851 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4851 Comment: Fixed by Phab:D4851. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 16:05:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 16:05:36 -0000 Subject: [GHC] #14600: Work out why Hadrian builds routinely fail In-Reply-To: <046.d1a91fc8ce0240183a8fe557b52881a5@haskell.org> References: <046.d1a91fc8ce0240183a8fe557b52881a5@haskell.org> Message-ID: <061.a609fc03f1e845afdd4470fa9433d019@haskell.org> #14600: Work out why Hadrian builds routinely fail -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Continuous | Version: 8.2.1 Integration | 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.6.1 Comment: Hadrian [[https://circleci.com/gh/ghc/ghc/5996|appears]] to be passing much more reliably now since Alp has worked his magic. I'm going to assume that the underlying issue has been resolved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 16:09:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 16:09:09 -0000 Subject: [GHC] #15230: unix tests fail under CircleCI's fedora environment In-Reply-To: <046.e75284c38f9e2e606bbb1d369702bf83@haskell.org> References: <046.e75284c38f9e2e606bbb1d369702bf83@haskell.org> Message-ID: <061.68158bc609970a306f45a64048b37e24@haskell.org> #15230: unix tests fail under CircleCI's fedora environment -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 Integration | 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:D4851 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"dbe5370ee4d582a45c7e94500f2acc6bf9e2b7cb/ghc" dbe5370e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dbe5370ee4d582a45c7e94500f2acc6bf9e2b7cb" circleci: Remove systemd from Fedora nsswitch configuration Lest we end up with a non-functional user/group lookup, resulting in #15230. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 16:09:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 16:09:45 -0000 Subject: [GHC] #15230: unix tests fail under CircleCI's fedora environment In-Reply-To: <046.e75284c38f9e2e606bbb1d369702bf83@haskell.org> References: <046.e75284c38f9e2e606bbb1d369702bf83@haskell.org> Message-ID: <061.5ed937551f9c378c4fdc1d4715c14f8e@haskell.org> #15230: unix tests fail under CircleCI's fedora environment -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 Integration | 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:D4851 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've committed this and updated the `linux-x86_64-fedora` image on DockerHub. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 16:09:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 16:09:50 -0000 Subject: [GHC] #15230: unix tests fail under CircleCI's fedora environment In-Reply-To: <046.e75284c38f9e2e606bbb1d369702bf83@haskell.org> References: <046.e75284c38f9e2e606bbb1d369702bf83@haskell.org> Message-ID: <061.5557b9f9af3b3ec87066bf219f0e9c92@haskell.org> #15230: unix tests fail under CircleCI's fedora environment -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 Integration | 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:D4851 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 16:43:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 16:43:50 -0000 Subject: [GHC] #14170: 8.2.1 regression: GHC fails to simplify `natVal` In-Reply-To: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> References: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> Message-ID: <063.0091ddc56c77cdcf5c2247032d7c3264@haskell.org> #14170: 8.2.1 regression: GHC fails to simplify `natVal` -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Bodigrim Type: bug | Status: patch Priority: high | Milestone: 8.6.1 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:D4212 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): I've just rebased D4212 on master. It should be ready to land. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 16:58:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 16:58:45 -0000 Subject: [GHC] #15184: T4442 fails on i386 In-Reply-To: <043.2aff333ef7aff4746a063eeba88c2731@haskell.org> References: <043.2aff333ef7aff4746a063eeba88c2731@haskell.org> Message-ID: <058.a9daab3dcf4bc1d368ee4bc049a73217@haskell.org> #15184: T4442 fails on i386 -------------------------------------+---------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4838 Wiki Page: | -------------------------------------+---------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => Comment: Sadly that wasn't quite sufficient. It appears there are deeper issues here. Marking as broken. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 17:02:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 17:02:46 -0000 Subject: [GHC] #15184: T4442 fails on i386 In-Reply-To: <043.2aff333ef7aff4746a063eeba88c2731@haskell.org> References: <043.2aff333ef7aff4746a063eeba88c2731@haskell.org> Message-ID: <058.81983e5b2362400b2cc185cef0003038@haskell.org> #15184: T4442 fails on i386 -------------------------------------+---------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4838 Wiki Page: | -------------------------------------+---------------------------------- Comment (by Ben Gamari ): In [changeset:"b7deeed00d93c306e55572c9c1c09ced4be61eef/ghc" b7deeed/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b7deeed00d93c306e55572c9c1c09ced4be61eef" testsuite: Make T4442 compile on i386 and mark as broken There are some rather suspicious failures in the 64-bit case. See #15184 for details. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 17:03:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 17:03:35 -0000 Subject: [GHC] #15184: T4442 fails on i386 In-Reply-To: <043.2aff333ef7aff4746a063eeba88c2731@haskell.org> References: <043.2aff333ef7aff4746a063eeba88c2731@haskell.org> Message-ID: <058.6da9a454e07ee84c09c66128361f6633@haskell.org> #15184: T4442 fails on i386 -------------------------------------+---------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4838 Wiki Page: | -------------------------------------+---------------------------------- Comment (by bgamari): Here are the discrepancies: {{{#!patch diff -uw "./primops/should_run/T4442.run/T4442.stdout.normalised" "./primops/should_run/T4442.run/T4442.run.stdout.normalised" --- ./primops/should_run/T4442.run/T4442.stdout.normalised 2018-06-15 12:55:21.215442394 -0400 +++ ./primops/should_run/T4442.run/T4442.run.stdout.normalised 2018-06-15 12:55:21.215442394 -0400 @@ -5,13 +5,115 @@ Int32# positive Int32# negative Int64# positive +[203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0] Int64# negative +[53,251,4,142,224,254,255,255,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [53,251,4,142,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[53,251,4,142,224,254,255,255,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [53,251,4,142,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,53,251,4,142,224,254,255,255,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,53,251,4,142,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,53,251,4,142,224,254,255,255,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,53,251,4,142,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,53,251,4,142,224,254,255,255,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,53,251,4,142,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,53,251,4,142,224,254,255,255,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,53,251,4,142,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,53,251,4,142,224,254,255,255,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,53,251,4,142,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,53,251,4,142,224,254,255,255,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,53,251,4,142,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,53,251,4,142,224,254,255,255,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,53,251,4,142,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,53,251,4,142,224,254,255,255,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,53,251,4,142,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,53,251,4,142,224,254,255,255,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,53,251,4,142,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,53,251,4,142,224,254,255,255,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,53,251,4,142,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,53,251,4,142,224,254,255,255,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,53,251,4,142,0,0,0,0,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,53,251,4,142,224,254,255,255,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,53,251,4,142,0,0,0,0,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,53,251,4,142,224,254,255,255,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,53,251,4,142,0,0,0,0,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,53,251,4,142,224,254,255,255,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,53,251,4,142,0,0,0,0,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,53,251,4,142,224,254,255,255,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,53,251,4,142,0,0,0,0,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,53,251,4,142,224,254,255,255,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,53,251,4,142,0,0,0,0,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,53,251,4,142,224,254,255,255,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,53,251,4,142,0,0,0,0,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,53,251,4,142,224,254,255,255,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,53,251,4,142,0,0,0,0,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,53,251,4,142,224,254,255,255,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,53,251,4,142,0,0,0,0,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,53,251,4,142,224,254,255,255,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,53,251,4,142,0,0,0,0,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,224,254,255,255,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,0,0,0,0,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,224,254,255,255,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,0,0,0,0,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,224,254,255,255,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,0,0,0,0,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,224,254,255,255,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,0,0,0,0,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,224,254,255,255,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,0,0,0,0,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,224,254,255,255,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,0,0,0,0,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,224,254,255,255,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,0,0,0,0,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,224,254,255,255,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,0,0,0,0,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,224,254,255,255,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,0,0,0,0,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,224,254,255,255,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,0,0,0,0,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,224,254,255,255] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,0,0,0,0] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,224,254,255,255] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,53,251,4,142,0,0,0,0] Int# positive Int# negative Word8# Word16# Word32# Word64# +[203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,31,1,0,0] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,203,4,251,113,0,0,0,0] Word# Char# WideChar# @@ -19,3 +121,37 @@ StablePtr# Float# Double# +[9,75,251,7,60,221,94,64,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [9,75,251,7,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[9,75,251,7,60,221,94,64,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [9,75,251,7,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,9,75,251,7,60,221,94,64,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,9,75,251,7,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,9,75,251,7,60,221,94,64,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,9,75,251,7,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,9,75,251,7,60,221,94,64,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,9,75,251,7,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,9,75,251,7,60,221,94,64,52,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,9,75,251,7,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,9,75,251,7,60,221,94,64,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,9,75,251,7,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,9,75,251,7,60,221,94,64,52,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,9,75,251,7,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,9,75,251,7,60,221,94,64,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,9,75,251,7,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,9,75,251,7,60,221,94,64,52,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,9,75,251,7,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,9,75,251,7,60,221,94,64,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,9,75,251,7,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,9,75,251,7,60,221,94,64,52,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,9,75,251,7,0,0,0,0,52,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,9,75,251,7,60,221,94,64,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,9,75,251,7,0,0,0,0,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,9,75,251,7,60,221,94,64,52,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,9,75,251,7,0,0,0,0,52,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,9,75,251,7,60,221,94,64,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,9,75,251,7,0,0,0,0,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,9,75,251,7,60,221,94,64,52,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,9,75,251,7,0,0,0,0,52,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,9,75,251,7,60,221,94,64,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,9,75,251,7,0,0,0,0,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,9,75,251,7,60,221,94,64,52,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,9,75,251,7,0,0,0,0,52,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,9,75,251,7,60,221,94,64,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,9,75,251,7,0,0,0,0,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,9,75,251,7,60,221,94,64,52,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,9,75,251,7,0,0,0,0,52,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,9,75,251,7,60,221,94,64,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,9,75,251,7,0,0,0,0,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,9,75,251,7,60,221,94,64,52,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,9,75,251,7,0,0,0,0,52,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,60,221,94,64,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,0,0,0,0,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,60,221,94,64,52,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,0,0,0,0,52,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,60,221,94,64,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,0,0,0,0,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,60,221,94,64,52,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,0,0,0,0,52,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,60,221,94,64,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,0,0,0,0,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,60,221,94,64,52,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,0,0,0,0,52,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,60,221,94,64,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,0,0,0,0,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,60,221,94,64,52,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,0,0,0,0,52,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,60,221,94,64,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,0,0,0,0,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,60,221,94,64,52] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,0,0,0,0,52] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,60,221,94,64] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,0,0,0,0] +[52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,60,221,94,64] /= [52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,52,9,75,251,7,0,0,0,0] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 17:20:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 17:20:15 -0000 Subject: [GHC] #15024: ghc: please switch to llvm-toolchain-6.0 In-Reply-To: <052.f8dd93d53607fec0aa24cccf11d14e57@haskell.org> References: <052.f8dd93d53607fec0aa24cccf11d14e57@haskell.org> Message-ID: <067.31b3ba2b474d3072a5d5141597d8386d@haskell.org> #15024: ghc: please switch to llvm-toolchain-6.0 -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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): I've validated against LLVM 6 on amd64/Linux (https://circleci.com/gh/ghc/ghc/5984). I observed numerous segmentation faulting tests in the `ext-interp` way, although I don't believe the situation is much different from LLVM 5 (e.g. https://circleci.com/gh/ghc/ghc/5991) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 17:23:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 17:23:22 -0000 Subject: [GHC] #15024: ghc: please switch to llvm-toolchain-6.0 In-Reply-To: <052.f8dd93d53607fec0aa24cccf11d14e57@haskell.org> References: <052.f8dd93d53607fec0aa24cccf11d14e57@haskell.org> Message-ID: <067.0df1b60365edb37f88e56f0aa4f6f101@haskell.org> #15024: ghc: please switch to llvm-toolchain-6.0 -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 17:58:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 17:58:47 -0000 Subject: [GHC] #15275: AArch64 validation fails with many invalid relocations In-Reply-To: <046.09db5dc304d31321bf750c17c4d53c7c@haskell.org> References: <046.09db5dc304d31321bf750c17c4d53c7c@haskell.org> Message-ID: <061.51f3a40397a03ac35058e79f32218006@haskell.org> #15275: AArch64 validation fails with many invalid relocations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Linking) | 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): Sadly just enabling `-fPIC` by default (using `DynFlags.default_PIC`) seems to make no difference. The problematic relocations are still generated. Linkers are truly awful creations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 18:03:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 18:03:21 -0000 Subject: [GHC] #13900: Core lint in BuildFlavour=perf-llvm In-Reply-To: <046.659e0b338788e413a5940905a0f91074@haskell.org> References: <046.659e0b338788e413a5940905a0f91074@haskell.org> Message-ID: <061.6637233be02c7080df1ed8433c5043b4@haskell.org> #13900: Core lint in BuildFlavour=perf-llvm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.3 Resolution: fixed | 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 bgamari): * status: new => closed * resolution: => fixed Comment: This indeed appears to be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 18:06:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 18:06:59 -0000 Subject: [GHC] #15269: Qualified Names in --show-iface output In-Reply-To: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> References: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> Message-ID: <061.c8f308f26b2e0d0e93bfee0fd5dd33c3@haskell.org> #15269: Qualified Names in --show-iface output -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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:D4852 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * status: new => patch * differential: => Phab:D4852 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 18:12:33 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 18:12:33 -0000 Subject: [GHC] #13833: Instances with GHC.TypeLits.Nat/Symbol should be possible without FlexibleInstances. In-Reply-To: <045.899fdc291fee22417bd4b56eb02e56da@haskell.org> References: <045.899fdc291fee22417bd4b56eb02e56da@haskell.org> Message-ID: <060.08c4adb629933b94070dae026d6657b2@haskell.org> #13833: Instances with GHC.TypeLits.Nat/Symbol should be possible without FlexibleInstances. -------------------------------------+------------------------------------- Reporter: Hjulle | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.0.2 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:D4823 Wiki Page: | -------------------------------------+------------------------------------- Comment (by qrilka): bgamari, should I do something else about my patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 18:58:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 18:58:36 -0000 Subject: [GHC] #15231: UndecidableInstances validity checking is wrong in the presence of QuantifiedConstraints In-Reply-To: <050.e69160ac4e3631edefda13f39672a247@haskell.org> References: <050.e69160ac4e3631edefda13f39672a247@haskell.org> Message-ID: <065.248769f4c2f9600aae8fc52392532704@haskell.org> #15231: UndecidableInstances validity checking is wrong in the presence of QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints 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:D4819 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"91822e4eee295a42f69489c7e9e878b296e897bc/ghc" 91822e4e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="91822e4eee295a42f69489c7e9e878b296e897bc" Add "quantified constraint" context in error message, fix #15231. This patch adds "quantified constraint" context in error message when UndecidableInstances checking fails for quantified constraints. See Trac #15231:comment#1. This patch also pretty-prints the instance head for better error messages. Test Plan: make test TEST="T15231" Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #15231 Differential Revision: https://phabricator.haskell.org/D4819 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 18:58:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 18:58:36 -0000 Subject: [GHC] #1: Implicit parameters cause strange behavi In-Reply-To: <045.dd635ef62f3ce1d5e8bfe2b4cd36b0de@haskell.org> References: <045.dd635ef62f3ce1d5e8bfe2b4cd36b0de@haskell.org> Message-ID: <060.255315744e2f2987fe784368492f0a2d@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:"91822e4eee295a42f69489c7e9e878b296e897bc/ghc" 91822e4e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="91822e4eee295a42f69489c7e9e878b296e897bc" Add "quantified constraint" context in error message, fix #15231. This patch adds "quantified constraint" context in error message when UndecidableInstances checking fails for quantified constraints. See Trac #15231:comment#1. This patch also pretty-prints the instance head for better error messages. Test Plan: make test TEST="T15231" Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #15231 Differential Revision: https://phabricator.haskell.org/D4819 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 18:58:37 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 18:58:37 -0000 Subject: [GHC] #15040: DTrace enabled GHC does not work as a bootstrap compiler on FreeBSD In-Reply-To: <046.4248b292a38cdda9701c70fc8d24c20a@haskell.org> References: <046.4248b292a38cdda9701c70fc8d24c20a@haskell.org> Message-ID: <061.ad87e490d025d9a836d6b13b8aa20ab6@haskell.org> #15040: DTrace enabled GHC does not work as a bootstrap compiler on FreeBSD -------------------------------------+------------------------------------- Reporter: raichoo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.4.1 Resolution: | Keywords: dtrace 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 Ben Gamari ): In [changeset:"9c89ef39f54943dd3fcd9d196ce1a5bdf7f5f94b/ghc" 9c89ef3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9c89ef39f54943dd3fcd9d196ce1a5bdf7f5f94b" Make dtrace enabled GHC work as a bootstrap compiler on FreeBSD Fixes #15040. Reviewers: bgamari, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4772 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 18:58:37 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 18:58:37 -0000 Subject: [GHC] #14747: DisambiguateRecordFields fails for PatternSynonyms In-Reply-To: <049.f08f8caee266cae142af76acb98feb02@haskell.org> References: <049.f08f8caee266cae142af76acb98feb02@haskell.org> Message-ID: <064.e2934c33b5ec0aaa64aaaaeca1a3af92@haskell.org> #14747: DisambiguateRecordFields fails for PatternSynonyms -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T14747 Blocked By: | Blocking: Related Tickets: #11283, #15149 | Differential Rev(s): Phab:D4821 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7100850eebb1c1aec0aaabca08915bac8b90e188/ghc" 7100850e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7100850eebb1c1aec0aaabca08915bac8b90e188" Use data con name instead of parent in lookupRecFieldOcc Test Plan: new tests rename/should_compile/{T14747,T15149} Reviewers: simonpj, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14747, #15149 Differential Revision: https://phabricator.haskell.org/D4821 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 18:58:37 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 18:58:37 -0000 Subject: [GHC] #15149: Identical distinct type family fields miscompiled In-Reply-To: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> References: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> Message-ID: <066.551df1ca7e15641f735a7fd2f129c8d7@haskell.org> #15149: Identical distinct type family fields miscompiled -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: adamgundry Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T15149 Blocked By: | Blocking: Related Tickets: #14747, #15277 | Differential Rev(s): Phab:D4821 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7100850eebb1c1aec0aaabca08915bac8b90e188/ghc" 7100850e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7100850eebb1c1aec0aaabca08915bac8b90e188" Use data con name instead of parent in lookupRecFieldOcc Test Plan: new tests rename/should_compile/{T14747,T15149} Reviewers: simonpj, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14747, #15149 Differential Revision: https://phabricator.haskell.org/D4821 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 18:58:37 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 18:58:37 -0000 Subject: [GHC] #13833: Instances with GHC.TypeLits.Nat/Symbol should be possible without FlexibleInstances. In-Reply-To: <045.899fdc291fee22417bd4b56eb02e56da@haskell.org> References: <045.899fdc291fee22417bd4b56eb02e56da@haskell.org> Message-ID: <060.2746320b5091e5682c1425ec0526855e@haskell.org> #13833: Instances with GHC.TypeLits.Nat/Symbol should be possible without FlexibleInstances. -------------------------------------+------------------------------------- Reporter: Hjulle | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.0.2 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:D4823 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"42f3b53b5bc4674e41f16de08094821fe1aaec00/ghc" 42f3b53b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="42f3b53b5bc4674e41f16de08094821fe1aaec00" Fix #13833: accept type literals with no FlexibleInstances Test Plan: ./validate Reviewers: bgamari, simonpj Reviewed By: bgamari, simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #13833 Differential Revision: https://phabricator.haskell.org/D4823 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 19:32:03 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 19:32:03 -0000 Subject: [GHC] #15040: DTrace enabled GHC does not work as a bootstrap compiler on FreeBSD In-Reply-To: <046.4248b292a38cdda9701c70fc8d24c20a@haskell.org> References: <046.4248b292a38cdda9701c70fc8d24c20a@haskell.org> Message-ID: <061.8186e771548743ff154d32f8336d6f20@haskell.org> #15040: DTrace enabled GHC does not work as a bootstrap compiler on FreeBSD -------------------------------------+------------------------------------- Reporter: raichoo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.4.1 Resolution: fixed | Keywords: dtrace Operating System: FreeBSD | 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: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 19:32:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 19:32:25 -0000 Subject: [GHC] #14747: DisambiguateRecordFields fails for PatternSynonyms In-Reply-To: <049.f08f8caee266cae142af76acb98feb02@haskell.org> References: <049.f08f8caee266cae142af76acb98feb02@haskell.org> Message-ID: <064.037781ea8fc64e7d3a919e90d094ff51@haskell.org> #14747: DisambiguateRecordFields fails for PatternSynonyms -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: fixed | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T14747 Blocked By: | Blocking: Related Tickets: #11283, #15149 | Differential Rev(s): Phab:D4821 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 19:32:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 19:32:36 -0000 Subject: [GHC] #13833: Instances with GHC.TypeLits.Nat/Symbol should be possible without FlexibleInstances. In-Reply-To: <045.899fdc291fee22417bd4b56eb02e56da@haskell.org> References: <045.899fdc291fee22417bd4b56eb02e56da@haskell.org> Message-ID: <060.53600de43f40ff571ba20e724f0f4f06@haskell.org> #13833: Instances with GHC.TypeLits.Nat/Symbol should be possible without FlexibleInstances. -------------------------------------+------------------------------------- Reporter: Hjulle | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.6.1 Component: Compiler | Version: 8.0.2 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:D4823 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 20:07:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 20:07:14 -0000 Subject: [GHC] #14170: 8.2.1 regression: GHC fails to simplify `natVal` In-Reply-To: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> References: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> Message-ID: <063.bbeb2b329aabd96a5144d10a61af5c94@haskell.org> #14170: 8.2.1 regression: GHC fails to simplify `natVal` -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Bodigrim Type: bug | Status: patch Priority: high | Milestone: 8.6.1 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:D4212 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Alright, given how long this patch has been in limbo I'm willing to merge it. Thanks for the rebase, hsyl20. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 21:01:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 21:01:11 -0000 Subject: [GHC] #14465: Performance of Natural In-Reply-To: <047.dbabb1127ee36a01bf1bf2eb91b6c532@haskell.org> References: <047.dbabb1127ee36a01bf1bf2eb91b6c532@haskell.org> Message-ID: <062.32df4644cb9e5b7c376994cf864b99e4@haskell.org> #14465: Performance of Natural -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14170 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fe770c211631e7b4c9b0b1e88ef9b6046c6585ef/ghc" fe770c21/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fe770c211631e7b4c9b0b1e88ef9b6046c6585ef" Built-in Natural literals in Core Add support for built-in Natural literals in Core. - Replace MachInt,MachWord, LitInteger, etc. with a single LitNumber constructor with a LitNumType field - Support built-in Natural literals - Add desugar warning for negative literals - Move Maybe(..) from GHC.Base to GHC.Maybe for module dependency reasons This patch introduces only a few rules for Natural literals (compared to Integer's rules). Factorization of the built-in rules for numeric literals will be done in another patch as this one is already big to review. Test Plan: validate test build with integer-simple Reviewers: hvr, bgamari, goldfire, Bodigrim, simonmar Reviewed By: bgamari Subscribers: phadej, simonpj, RyanGlScott, carter, hsyl20, rwbarton, thomie GHC Trac Issues: #14170, #14465 Differential Revision: https://phabricator.haskell.org/D4212 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 21:01:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 21:01:11 -0000 Subject: [GHC] #14170: 8.2.1 regression: GHC fails to simplify `natVal` In-Reply-To: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> References: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> Message-ID: <063.f494ee55e2475840fb3e91fb10b894e3@haskell.org> #14170: 8.2.1 regression: GHC fails to simplify `natVal` -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Bodigrim Type: bug | Status: patch Priority: high | Milestone: 8.6.1 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:D4212 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fe770c211631e7b4c9b0b1e88ef9b6046c6585ef/ghc" fe770c21/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fe770c211631e7b4c9b0b1e88ef9b6046c6585ef" Built-in Natural literals in Core Add support for built-in Natural literals in Core. - Replace MachInt,MachWord, LitInteger, etc. with a single LitNumber constructor with a LitNumType field - Support built-in Natural literals - Add desugar warning for negative literals - Move Maybe(..) from GHC.Base to GHC.Maybe for module dependency reasons This patch introduces only a few rules for Natural literals (compared to Integer's rules). Factorization of the built-in rules for numeric literals will be done in another patch as this one is already big to review. Test Plan: validate test build with integer-simple Reviewers: hvr, bgamari, goldfire, Bodigrim, simonmar Reviewed By: bgamari Subscribers: phadej, simonpj, RyanGlScott, carter, hsyl20, rwbarton, thomie GHC Trac Issues: #14170, #14465 Differential Revision: https://phabricator.haskell.org/D4212 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 21:08:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 21:08:38 -0000 Subject: [GHC] #15257: Broken symlinks in lndir build tree In-Reply-To: <049.f0b63926608607176eb8bb749ef67790@haskell.org> References: <049.f0b63926608607176eb8bb749ef67790@haskell.org> Message-ID: <064.0213b74643a5bacf2a1062983c9d0d8e@haskell.org> #15257: Broken symlinks in lndir build tree -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.5 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): Phab:D4853 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * status: new => patch * differential: => Phab:D4853 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 21:24:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 21:24:56 -0000 Subject: [GHC] #15062: num009 is incredibly platform-sensitive In-Reply-To: <046.fd26963ba1ba8046e379799dd9722c15@haskell.org> References: <046.fd26963ba1ba8046e379799dd9722c15@haskell.org> Message-ID: <061.a4644688009ec75e13082d6c1f2ee9af@haskell.org> #15062: num009 is incredibly platform-sensitive -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2370 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #2370 Comment: See also #2370. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 21:31:33 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 21:31:33 -0000 Subject: [GHC] #15062: num009 is incredibly platform-sensitive In-Reply-To: <046.fd26963ba1ba8046e379799dd9722c15@haskell.org> References: <046.fd26963ba1ba8046e379799dd9722c15@haskell.org> Message-ID: <061.89c55f7b5243de3fcf386c5d21d91729@haskell.org> #15062: num009 is incredibly platform-sensitive -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2370 | Differential Rev(s): Phab:D4854 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4854 Comment: I am going to disable this test on 32-bit platforms in the interest of getting 32-bit CircleCI green. See Phab:D4854. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 21:33:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 21:33:52 -0000 Subject: [GHC] #15274: Numerous validation failures when building GHC with LLVM In-Reply-To: <046.83a071bfa50c4ead83f977af9cb85f1c@haskell.org> References: <046.83a071bfa50c4ead83f977af9cb85f1c@haskell.org> Message-ID: <061.3db498d92c69b2a997c0d214d9b089aa@haskell.org> #15274: Numerous validation failures when building GHC with LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (LLVM) | Version: 8.4.3 Resolution: | Keywords: ci-breakage 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): * keywords: => ci-breakage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 21:34:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 21:34:04 -0000 Subject: [GHC] #15255: overflow1 breaks on i386 In-Reply-To: <046.ee165761a653c328cf797e94579d9139@haskell.org> References: <046.ee165761a653c328cf797e94579d9139@haskell.org> Message-ID: <061.421e70313a65b6c0963816c479960809@haskell.org> #15255: overflow1 breaks on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 Integration | Resolution: | Keywords: ci-breakage 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): * keywords: => ci-breakage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 21:36:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 21:36:00 -0000 Subject: [GHC] #15255: overflow1 breaks on i386 In-Reply-To: <046.ee165761a653c328cf797e94579d9139@haskell.org> References: <046.ee165761a653c328cf797e94579d9139@haskell.org> Message-ID: <061.62e827b8e53a948f309900e9d1e9a772@haskell.org> #15255: overflow1 breaks on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 Integration | Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4855 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4855 Comment: Marking as broken. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 23:43:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 23:43:59 -0000 Subject: [GHC] #15195: Merge -XPolyKinds with -XTypeInType In-Reply-To: <047.c44c81564ca3186b8f7d6c799db31ecf@haskell.org> References: <047.c44c81564ca3186b8f7d6c799db31ecf@haskell.org> Message-ID: <062.062f10991bbd6923c2cc75842031e770@haskell.org> #15195: Merge -XPolyKinds with -XTypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: int-index Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4748 Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * status: closed => merge Comment: This actually isn't in a stable branch yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 15 23:46:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Jun 2018 23:46:48 -0000 Subject: [GHC] #15264: Warn about implicit kind variables with -Wcompat In-Reply-To: <048.2758c96021df3e03a2c44fb779b75b19@haskell.org> References: <048.2758c96021df3e03a2c44fb779b75b19@haskell.org> Message-ID: <063.2fbd22636d784c14cce257ea4ff00227@haskell.org> #15264: Warn about implicit kind variables with -Wcompat -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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:D4834 Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * status: new => patch * differential: => Phab:D4834 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 01:25:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 01:25:47 -0000 Subject: [GHC] #15195: Merge -XPolyKinds with -XTypeInType In-Reply-To: <047.c44c81564ca3186b8f7d6c799db31ecf@haskell.org> References: <047.c44c81564ca3186b8f7d6c799db31ecf@haskell.org> Message-ID: <062.ee5bbe1730f70329b737023f3fee3358@haskell.org> #15195: Merge -XPolyKinds with -XTypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: int-index Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4748 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: merge => closed Comment: We don't actually need to merge this to a stable branch, as I don't believe the 8.6 branch has been cut yet. Ben, correct me if I'm wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 01:33:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 01:33:04 -0000 Subject: [GHC] #15273: Datatypes with CUSKs should quantify over unknown kinds In-Reply-To: <047.ec7ed2596e5045a5e66eba34c3a673fe@haskell.org> References: <047.ec7ed2596e5045a5e66eba34c3a673fe@haskell.org> Message-ID: <062.597a0cb55f562a78be37beb83e338eca@haskell.org> #15273: Datatypes with CUSKs should quantify over unknown kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4845 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"12794287174146f982257cdeffd491e3e23838dc/ghc" 1279428/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="12794287174146f982257cdeffd491e3e23838dc" Quantify unfixed kind variables in CUSKs This is a small change in user-facing behavior. When we have a unification variable left over in a CUSK, we previously would issue an error. But, we can just quantify. This also teaches kcLHsQTyVars to use quantifyTyVars instead of its own, ad-hoc quantification scheme. Fixes #15273. test case: polykinds/T11648b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 01:34:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 01:34:17 -0000 Subject: [GHC] #15195: Merge -XPolyKinds with -XTypeInType In-Reply-To: <047.c44c81564ca3186b8f7d6c799db31ecf@haskell.org> References: <047.c44c81564ca3186b8f7d6c799db31ecf@haskell.org> Message-ID: <062.76817954fd48c979864175ce8917fca9@haskell.org> #15195: Merge -XPolyKinds with -XTypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: int-index Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4748 Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): I might misunderstand how releases work, but the `ghc-8.6` branch already exists and does not include this commit. Ben was actually going to cut a release without this commit but we talked about it over IRC and he agreed to merge. The status I've set is described as: > fixed in GHC HEAD repo; please merge to GHC STABLE branch and I think it describes the current status perfectly. If not, when would I set it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 01:41:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 01:41:31 -0000 Subject: [GHC] #15195: Merge -XPolyKinds with -XTypeInType In-Reply-To: <047.c44c81564ca3186b8f7d6c799db31ecf@haskell.org> References: <047.c44c81564ca3186b8f7d6c799db31ecf@haskell.org> Message-ID: <062.2101e47ef020b7984787fe2b74e38ee0@haskell.org> #15195: Merge -XPolyKinds with -XTypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: int-index Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4748 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: closed => merge Comment: Oops! I didn't know that 8.6 had been cut. Normally, large commits like yours are not merged in the middle of a release cycle but wait around for the next major release. But it's appropriate to put yours in the 8.6 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 01:42:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 01:42:56 -0000 Subject: [GHC] #15273: Datatypes with CUSKs should quantify over unknown kinds In-Reply-To: <047.ec7ed2596e5045a5e66eba34c3a673fe@haskell.org> References: <047.ec7ed2596e5045a5e66eba34c3a673fe@haskell.org> Message-ID: <062.82cdce569cf6b860a63771d49f9d59aa@haskell.org> #15273: Datatypes with CUSKs should quantify over unknown kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T11648b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4845 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => polykinds/T11648b Comment: I see no reason not to merge for 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 05:07:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 05:07:21 -0000 Subject: [GHC] #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented In-Reply-To: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> References: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> Message-ID: <061.d31da0f9d77df19fa185f1a0452036cc@haskell.org> #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Azel Type: feature request | Status: merge Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.2 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:D4736 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Azel): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 15:24:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 15:24:58 -0000 Subject: [GHC] #14170: 8.2.1 regression: GHC fails to simplify `natVal` In-Reply-To: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> References: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> Message-ID: <063.9c12bff60ae15992c7709df4b5a74265@haskell.org> #14170: 8.2.1 regression: GHC fails to simplify `natVal` -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Bodigrim Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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:D4212 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 15:50:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 15:50:52 -0000 Subject: [GHC] #15195: Merge -XPolyKinds with -XTypeInType In-Reply-To: <047.c44c81564ca3186b8f7d6c799db31ecf@haskell.org> References: <047.c44c81564ca3186b8f7d6c799db31ecf@haskell.org> Message-ID: <062.a0d9c6462fa6ed35533afdb3d6eb13cd@haskell.org> #15195: Merge -XPolyKinds with -XTypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: int-index Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4748 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Well, to be clear, the `ghc-8.6` branch does exist but it's still tracking `master`. By the end of the day I suspect it will begin diverging. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 16:33:44 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 16:33:44 -0000 Subject: [GHC] #15221: failure to build pandoc on Debian armhf In-Reply-To: <044.c95e2449a6d05724dcf3491a30d3f9d3@haskell.org> References: <044.c95e2449a6d05724dcf3491a30d3f9d3@haskell.org> Message-ID: <059.f6bd9944ca8b4e89d3443d39d3270896@haskell.org> #15221: failure to build pandoc on Debian armhf ---------------------------------+---------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: Would it be possible to try reproducing this with 8.4.3 (or better, `master`)? I suspect that this is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 16:59:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 16:59:19 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF In-Reply-To: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> References: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> Message-ID: <060.715486953920018932bb6b52005487f1@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | perf/should_run/T15226, 15226a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4796 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This is in 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 17:03:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 17:03:02 -0000 Subject: [GHC] #14123: Figure out invariants surrounding ticks in Core In-Reply-To: <046.0308c769b363c5285c5969fe8d556b65@haskell.org> References: <046.0308c769b363c5285c5969fe8d556b65@haskell.org> Message-ID: <061.cb233662fc622e909dae9795e7c5814a@haskell.org> #14123: Figure out invariants surrounding ticks in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.8.1 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: #13233, #14122, | Differential Rev(s): #8472, #14406, #14779 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 Comment: I suspect there is a bit more documentation that could be written in this area but the major bugs are sorted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 17:03:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 17:03:29 -0000 Subject: [GHC] #14416: CI with CircleCI In-Reply-To: <043.af09c8504e7db798b11a186aefc2b2d5@haskell.org> References: <043.af09c8504e7db798b11a186aefc2b2d5@haskell.org> Message-ID: <058.81eb5261e31769f0c84cf52030bf9b21@haskell.org> #14416: CI with CircleCI -------------------------------------+------------------------------------- Reporter: chak | Owner: bgamari Type: task | Status: new Priority: highest | Milestone: Component: Continuous | Version: Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ContinuousIntegration | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => Comment: This isn't necessarily tied to any one GHC release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 17:05:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 17:05:27 -0000 Subject: [GHC] #12178: Allow inline pragmas on pattern synonyms In-Reply-To: <049.c0b5177720c745c7c76b88f1c76a960e@haskell.org> References: <049.c0b5177720c745c7c76b88f1c76a960e@haskell.org> Message-ID: <064.bd3dd09cdde0709f834743d0ce0b0675@haskell.org> #12178: Allow inline pragmas on pattern synonyms -------------------------------------+------------------------------------- Reporter: mpickering | Owner: osa1 Type: feature request | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms, 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 bgamari): * milestone: 8.6.1 => 8.8.1 Comment: This won't happen for 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 17:13:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 17:13: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.986d07a60c373a1ae94a45b78694db5e@haskell.org> #12970: Add default implementation for Bits.bitSize -------------------------------------+------------------------------------- Reporter: txnull | Owner: dfeuer Type: feature request | Status: patch Priority: high | Milestone: 8.6.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: | Phab:D4857 -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D3723 => Phab:D3723, Phab:D4857 Comment: Adding default implementation for 8.6 in D4857. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 17:15:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 17:15:05 -0000 Subject: [GHC] #15266: Add QuantifiedConstraints to release notes In-Reply-To: <047.7f8a75fae4aa9f1a651d946ac383dd49@haskell.org> References: <047.7f8a75fae4aa9f1a651d946ac383dd49@haskell.org> Message-ID: <062.8d989a05e59afba78eb28d407afc242d@haskell.org> #15266: Add QuantifiedConstraints to release notes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Fixed in 4672e2ebf040feffde4e7e2d79c479e4c0c3efaf. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 17:16:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 17:16:23 -0000 Subject: [GHC] Batch modify: #4012, #7411, #8228, #9370, #10946, #11126, ... In-Reply-To: <196.a376f0be6dfafc6418e1ad792e86796c@haskell.org> References: <196.a376f0be6dfafc6418e1ad792e86796c@haskell.org> Message-ID: <211.a6309fd1981b1b2156838b5dcd465879@haskell.org> Batch modification to #4012, #7411, #8228, #9370, #10946, #11126, #12758, #13233, #13426, #13535, #13576, #13624, #13763, #14013, #14069, #14226, #14230, #14980, #14994, #15071, #15267, #314, #605, #5620, #6087, #6132, #7353, #8634, #8763 by bgamari: milestone to 8.8.1 Comment: This won't be fixed in 8.6. Bumping to 8.8. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 17:21:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 17:21:38 -0000 Subject: [GHC] #12999: Investigate use of floating-point arithmetic in I/O Event-handler In-Reply-To: <042.d9e72583afa2ded1431f4a089ec3a9ba@haskell.org> References: <042.d9e72583afa2ded1431f4a089ec3a9ba@haskell.org> Message-ID: <057.398a87e9a88cf821ef720fb181d9252d@haskell.org> #12999: Investigate use of floating-point arithmetic in I/O Event-handler -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: libraries/base | 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: I fixed this in ab2dcb1c474d918efdc875f3cca7ef5b6ebdce1a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 17:27:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 17:27:01 -0000 Subject: [GHC] #15257: Broken symlinks in lndir build tree In-Reply-To: <049.f0b63926608607176eb8bb749ef67790@haskell.org> References: <049.f0b63926608607176eb8bb749ef67790@haskell.org> Message-ID: <064.2aaf8b325ed3fd59c3ed732c557ce300@haskell.org> #15257: Broken symlinks in lndir build tree -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.5 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): Phab:D4853 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8ee9c574a6d2105ace858f0fee31750acafe0a0f/ghc" 8ee9c57/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8ee9c574a6d2105ace858f0fee31750acafe0a0f" Amend configure script to support lndir build tree Test Plan: ./validate Reviewers: bgamari Subscribers: rwbarton, thomie, erikd, carter GHC Trac Issues: #15257 Differential Revision: https://phabricator.haskell.org/D4853 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 17:27:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 17:27:17 -0000 Subject: [GHC] #15062: num009 is incredibly platform-sensitive In-Reply-To: <046.fd26963ba1ba8046e379799dd9722c15@haskell.org> References: <046.fd26963ba1ba8046e379799dd9722c15@haskell.org> Message-ID: <061.637003a917510672074278978d9d411d@haskell.org> #15062: num009 is incredibly platform-sensitive -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2370 | Differential Rev(s): Phab:D4854 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1ab2dcb04d96e72b4e8e921efd19f8e70d19f8ba/ghc" 1ab2dcb0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1ab2dcb04d96e72b4e8e921efd19f8e70d19f8ba" testsuite: Mark num009 as broken due to #15062 Test Plan: Validate Reviewers: hvr Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15062 Differential Revision: https://phabricator.haskell.org/D4854 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 17:27:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 17:27:19 -0000 Subject: [GHC] #12951: Remove __USE_MINGW_ANSI_STDIO define from PosixSource.h In-Reply-To: <046.6a7aeb23ea1b9a4487131aaecfa8bac9@haskell.org> References: <046.6a7aeb23ea1b9a4487131aaecfa8bac9@haskell.org> Message-ID: <061.e803f5ff75225afa6a5cebba9e4e2987@haskell.org> #12951: Remove __USE_MINGW_ANSI_STDIO define from PosixSource.h -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.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:D2812 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 17:27:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 17:27:32 -0000 Subject: [GHC] #15255: overflow1 breaks on i386 In-Reply-To: <046.ee165761a653c328cf797e94579d9139@haskell.org> References: <046.ee165761a653c328cf797e94579d9139@haskell.org> Message-ID: <061.1c45525964974d8bb75d456793246c8d@haskell.org> #15255: overflow1 breaks on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 Integration | Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4855 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1f2ed994de558924e3acb7578b1dca2ee52f5b14/ghc" 1f2ed99/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1f2ed994de558924e3acb7578b1dca2ee52f5b14" testsuite: Mark overflow1 as broken on 32-bit platforms due to #15255 Test Plan: Validate on i386 Reviewers: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15255 Differential Revision: https://phabricator.haskell.org/D4855 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 17:27:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 17:27:46 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.872dac1b0bc3f44e6f58b74cc80d3bd4@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"86210b238b86d810874a2315d1715546a4006cea/ghc" 86210b23/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="86210b238b86d810874a2315d1715546a4006cea" rts: Use .cfi_{start|end}proc directives Test Plan: Validate using LLVM assembler Reviewers: carter, erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #15207 Differential Revision: https://phabricator.haskell.org/D4781 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 17:28:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 17:28:01 -0000 Subject: [GHC] #15242: Typechecker sometimes doesn't preserve HsPar in original source. In-Reply-To: <045.8e7aac9da580012b12f85623927a4ba7@haskell.org> References: <045.8e7aac9da580012b12f85623927a4ba7@haskell.org> Message-ID: <060.3f4359b15df975d577a373fd3eb3d388@haskell.org> #15242: Typechecker sometimes doesn't preserve HsPar in original source. -------------------------------------+------------------------------------- Reporter: wz1000 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: T15242 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4822 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"cd95c2ffdc5143acd3ae341ff6a19fc603b98db3/ghc" cd95c2ff/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cd95c2ffdc5143acd3ae341ff6a19fc603b98db3" Preserve parenthesis in function application in typechecker Preserve HsPars while typechecking Test Plan: T15242 Reviewers: bgamari, alanz, simonpj Reviewed By: alanz, simonpj Subscribers: simonpj, AndreasK, rwbarton, thomie, carter GHC Trac Issues: #15242 Differential Revision: https://phabricator.haskell.org/D4822 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 17:29:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 17:29:24 -0000 Subject: [GHC] #14656: Nofib: Ignore cr-lineendings in benchmarks In-Reply-To: <047.9bef567ea530bf2617132f7e80ca6f4e@haskell.org> References: <047.9bef567ea530bf2617132f7e80ca6f4e@haskell.org> Message-ID: <062.087ac43978f9404f12d8b14ec58644f5@haskell.org> #14656: Nofib: Ignore cr-lineendings in benchmarks -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: NoFib benchmark | Version: 8.2.2 suite | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4705 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3ef116aa7ed572b8ee32223a18bce8d61a635b02/nofib" 3ef116a/nofib]: {{{ #!CommitTicketReference repository="nofib" revision="3ef116aa7ed572b8ee32223a18bce8d61a635b02" Don't use binary output for real/eff. These use putStrLn so clearly we are not producing binary data. This caused failures on windows. Reviewers: O26 nofib, bgamari Reviewed By: bgamari Subscribers: bgamari GHC Trac Issues: #14656 Differential Revision: https://phabricator.haskell.org/D4705 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 17:32:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 17:32:04 -0000 Subject: [GHC] #13008: Cleanup backwards compatibility ifdefs due to stage1 external interpreter work In-Reply-To: <045.2ac2011cab453571e7594dd8ee92efe0@haskell.org> References: <045.2ac2011cab453571e7594dd8ee92efe0@haskell.org> Message-ID: <060.8fcb16a8ebff2d5b79581c6b582c4e4b@haskell.org> #13008: Cleanup backwards compatibility ifdefs due to stage1 external interpreter work -------------------------------------+------------------------------------- Reporter: shlevy | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: These have been removed in c13720c8c6047844f659ad4ce684946b80c99bee. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 17:32:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 17:32:55 -0000 Subject: [GHC] Batch modify: #9221, #9244, #9248, #9775, #9832, #10352, #10431, ... In-Reply-To: <493.ded7a1e7eae14ace86698e964ce2c353@haskell.org> References: <493.ded7a1e7eae14ace86698e964ce2c353@haskell.org> Message-ID: <508.0669e8d49205082e9e5d5db4ec4a7ee1@haskell.org> Batch modification to #9221, #9244, #9248, #9775, #9832, #10352, #10431, #10542, #10599, #10770, #10789, #10803, #10822, #10844, #10853, #10878, #10892, #10962, #10972, #11092, #11149, #11197, #11204, #11222, #11243, #11261, #11307, #11323, #11359, #11369, #11384, #11394, #11409, #11445, #11457, #11474, #11503, #11526, #11549, #11587, #11594, #11634, #11686, #11719, #11749, #11836, #11953, #11955, #12021, #12090, #12193, #12388, #12428, #12581, #12599, #12636, #12652, #12665, #12765, #12774, #12798, #12808, #12875, #12891, #12913, #12926, #12932, #12934, #12937, #12940, #12941, #12949, #12965, #13002, #13003, #13065, #13069 by bgamari: milestone to 8.8.1 Comment: These won't be fixed for 8.6, bumping to 8.8. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 18:37:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 18:37:58 -0000 Subject: [GHC] #15270: TH doesn't verify name types during conversion In-Reply-To: <046.884d12edfebb255ed830a85371c14d75@haskell.org> References: <046.884d12edfebb255ed830a85371c14d75@haskell.org> Message-ID: <061.adfa16afe589237fd25cc9065a77bdbc@haskell.org> #15270: TH doesn't verify name types during conversion -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.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 RyanGlScott): Actually, I think your hypothesis wasn't too far off, bgamari. Here's a minimal example which triggers the panic: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Bug where import Language.Haskell.TH.Lib import Language.Haskell.TH.Syntax main :: IO () main = print $(conE (mkNameG_v "ghc-prim" "GHC.Types" "True")) }}} {{{ $ ghc/inplace/bin/ghc-stage2 Bug2.hs [1 of 1] Compiling Bug ( Bug2.hs, Bug2.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180616 for x86_64-unknown-linux): ASSERT failed! True Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1223:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:655:67 in ghc:TcHsSyn }}} It turns out that I was using `conE (mkNameG_v "ghc-prim" "GHC.Types" "True")` in `deriving-compat`. Oops! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 18:53:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 18:53:46 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.b50848de42b885c14e64a81e04e01928@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => infoneeded Comment: I believe this should now be fixed. Carter, do you think you could test the final patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 18:54:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 18:54:47 -0000 Subject: [GHC] #14656: Nofib: Ignore cr-lineendings in benchmarks In-Reply-To: <047.9bef567ea530bf2617132f7e80ca6f4e@haskell.org> References: <047.9bef567ea530bf2617132f7e80ca6f4e@haskell.org> Message-ID: <062.44b1e67893c3f876472945a7f472968e@haskell.org> #14656: Nofib: Ignore cr-lineendings in benchmarks -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: NoFib benchmark | Version: 8.2.2 suite | 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:D4705 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 18:55:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 18:55:09 -0000 Subject: [GHC] #15242: Typechecker sometimes doesn't preserve HsPar in original source. In-Reply-To: <045.8e7aac9da580012b12f85623927a4ba7@haskell.org> References: <045.8e7aac9da580012b12f85623927a4ba7@haskell.org> Message-ID: <060.ed8ecf09264d51ed65c80118afaedad6@haskell.org> #15242: Typechecker sometimes doesn't preserve HsPar in original source. -------------------------------------+------------------------------------- Reporter: wz1000 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: T15242 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4822 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 18:56:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 18:56:30 -0000 Subject: [GHC] #15255: overflow1 breaks on i386 In-Reply-To: <046.ee165761a653c328cf797e94579d9139@haskell.org> References: <046.ee165761a653c328cf797e94579d9139@haskell.org> Message-ID: <061.de2119a571ff473e1734c0d8143eda9d@haskell.org> #15255: overflow1 breaks on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 Integration | Resolution: fixed | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4855 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 18:56:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 18:56:53 -0000 Subject: [GHC] #15257: Broken symlinks in lndir build tree In-Reply-To: <049.f0b63926608607176eb8bb749ef67790@haskell.org> References: <049.f0b63926608607176eb8bb749ef67790@haskell.org> Message-ID: <064.50bc23550a2ad8438ce9fbc29ed61027@haskell.org> #15257: Broken symlinks in lndir build tree -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.5 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): Phab:D4853 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 18:57:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 18:57:02 -0000 Subject: [GHC] #15062: num009 is incredibly platform-sensitive In-Reply-To: <046.fd26963ba1ba8046e379799dd9722c15@haskell.org> References: <046.fd26963ba1ba8046e379799dd9722c15@haskell.org> Message-ID: <061.8d079b645f5aa32b8843c39e579f5892@haskell.org> #15062: num009 is incredibly platform-sensitive -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.2 Resolution: fixed | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2370 | Differential Rev(s): Phab:D4854 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 18:57:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 18:57:14 -0000 Subject: [GHC] #14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: In-Reply-To: <045.3936f21bdd3848870db3bf9280c23e0a@haskell.org> References: <045.3936f21bdd3848870db3bf9280c23e0a@haskell.org> Message-ID: <060.09c550da9adfe519c666cab9dbd10052@haskell.org> #14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: -------------------------------------+------------------------------------- Reporter: slyfox | Owner: angerman Type: bug | Status: new Priority: normal | Milestone: 8.6.1 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 matthewbauer): Other missing triplets: - armv7a-unknown-linux-androideabi - armv5tel-unknown-linux-gnueabi - armv6l-unknown-linux-gnueabihf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 19:00:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 19:00:14 -0000 Subject: [GHC] #15270: TH doesn't verify name types during conversion In-Reply-To: <046.884d12edfebb255ed830a85371c14d75@haskell.org> References: <046.884d12edfebb255ed830a85371c14d75@haskell.org> Message-ID: <061.1ae242787e60f1ce8b650f7adead6694@haskell.org> #15270: TH doesn't verify name types during conversion -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.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): Interesting, I excluded my hypothesis after noticing that the following testcase indeed fails with a proper error: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module T10047A where import Language.Haskell.TH -- Passing var name to conE should fail. x = $(conE 'id) }}} I didn't look much farther after this. Quite interesting that `mkNameG_v` gets around the error. Are you going to continue looking into this or should I add it to my queue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 19:04:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 19:04:54 -0000 Subject: [GHC] #14475: Upload documentation dumps In-Reply-To: <046.875271090aacfb7d8f31943e1b69bd4b@haskell.org> References: <046.875271090aacfb7d8f31943e1b69bd4b@haskell.org> Message-ID: <061.68aeedbfa8d112f1db989e8afb60c943@haskell.org> #14475: Upload documentation dumps -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gander Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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): First, I suspect it would be best to build on top of the new Hadrian build system as we are nearly ready to phase-out the `make`-based build system. My vision for this is to upload tarballs containing the built documentation alongside the binary distribution that CI already produces. See `.circleci/config.yml` to see how we binary distribution upload works. The question then is what we do with the tarballs after they have been uploaded. If we just wanted to keep http://downloads.haskell.org/~ghc/latest/doc up-to-date then we could just have a cron job that periodically downloads and extracts the latest tarball. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 19:05:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 19:05:56 -0000 Subject: [GHC] #14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: In-Reply-To: <045.3936f21bdd3848870db3bf9280c23e0a@haskell.org> References: <045.3936f21bdd3848870db3bf9280c23e0a@haskell.org> Message-ID: <060.f72b30f82690f4fbcecd05dfa6f99085@haskell.org> #14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: -------------------------------------+------------------------------------- Reporter: slyfox | Owner: angerman Type: bug | Status: new Priority: normal | Milestone: 8.6.1 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): It would be great if someone could offer a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 19:14:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 19:14:07 -0000 Subject: [GHC] #15134: enumFrom... aren't really documented. In-Reply-To: <045.101e34e5570fe8f6e2839dfe4e91d13c@haskell.org> References: <045.101e34e5570fe8f6e2839dfe4e91d13c@haskell.org> Message-ID: <060.08a76a79e38fd915030a0fea59fbafd4@haskell.org> #15134: enumFrom... aren't really documented. -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Azel Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4737 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"dbc8c0f8a9a5c307a54f40b51819cc88c1377485/ghc" dbc8c0f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dbc8c0f8a9a5c307a54f40b51819cc88c1377485" base: Improve the documentation of the enumFrom series of functions Fixes #15134. Reviewers: dfeuer, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15134 Differential Revision: https://phabricator.haskell.org/D4737 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 19:14:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 19:14:22 -0000 Subject: [GHC] #12951: Remove __USE_MINGW_ANSI_STDIO define from PosixSource.h In-Reply-To: <046.6a7aeb23ea1b9a4487131aaecfa8bac9@haskell.org> References: <046.6a7aeb23ea1b9a4487131aaecfa8bac9@haskell.org> Message-ID: <061.66194f09bc266ab484bd8bdccd8384c7@haskell.org> #12951: Remove __USE_MINGW_ANSI_STDIO define from PosixSource.h -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.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:D2812 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"de34a71460a920e836b7057b4aac76d6202be890/ghc" de34a714/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="de34a71460a920e836b7057b4aac76d6202be890" rts: Remove use of __USE_MINGW_ANSI_STDIO As pointed out in #12951, this was a temporary measure to allow GHC to be bootstrapped on Windows with GHC 7.10. This release is now out of our bootstrap support window so let's remove it. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 19:15:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 19:15:43 -0000 Subject: [GHC] #15270: TH doesn't verify name types during conversion In-Reply-To: <046.884d12edfebb255ed830a85371c14d75@haskell.org> References: <046.884d12edfebb255ed830a85371c14d75@haskell.org> Message-ID: <061.1c69f6529f009d9b6fdf54a7c82006a8@haskell.org> #15270: TH doesn't verify name types during conversion -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.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 RyanGlScott): Indeed, this is an odd one. Some other observations: * `conE 'id` fails with: {{{ • Illegal data constructor name: ‘id’ When splicing a TH expression: GHC.Base.id • In the untyped splice: $(conE 'id) }}} * `varE 'True` fails with: {{{ • Illegal variable name: ‘True’ When splicing a TH expression: GHC.Types.True • In the untyped splice: $(varE 'True) }}} * Finally, `$(varE (mkNameG_d "base" "GHC.Base" "id"))` fails with: {{{ • Can't find interface-file declaration for data constructor GHC.Base.id 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 • In the expression: (GHC.Base.id) In an equation for ‘it’: it = (GHC.Base.id) }}} I suppose we want something like that last error if we try to use `$(conE (mkNameG_v "ghc-prim" "GHC.Types" "True"))` as in comment:4. That being said, I can't figure out why we don't //currently// get that error. After all, that error message is caused by looking up a `Name` in an EPS and failing, so if `$(conE (mkNameG_v "ghc-prim" "GHC.Types" "True"))` isn't erroring, does that mean that a value named `True` //is// located in the EPS? I'm afraid I don't know how to proceed at this point, so do you think you could look at this, Ben? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 19:18:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 19:18:52 -0000 Subject: [GHC] #15195: Merge -XPolyKinds with -XTypeInType In-Reply-To: <047.c44c81564ca3186b8f7d6c799db31ecf@haskell.org> References: <047.c44c81564ca3186b8f7d6c799db31ecf@haskell.org> Message-ID: <062.fc08eebaf9c419e6edbaff3052fe4e13@haskell.org> #15195: Merge -XPolyKinds with -XTypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: int-index Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4748 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Alright, I've pushed a bump of `ghc-8.6` including this patch. Closing. Thanks for doing this, int-index! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 19:35:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 19:35:07 -0000 Subject: [GHC] #13576: Runtime crashes on arm64 (iOS) In-Reply-To: <049.870e50852d766ed0e0b96a146b5b4e33@haskell.org> References: <049.870e50852d766ed0e0b96a146b5b4e33@haskell.org> Message-ID: <064.87a96af1986984a070a4f541e6e03305@haskell.org> #13576: Runtime crashes on arm64 (iOS) ----------------------------------+---------------------------------- Reporter: jp.rider63 | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.8.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: aarch64 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------- Comment (by jp.rider63): angerman, I can give you read access to the required repositories if you send me your bitbucket username. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 19:39:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 19:39:16 -0000 Subject: [GHC] #15134: enumFrom... aren't really documented. In-Reply-To: <045.101e34e5570fe8f6e2839dfe4e91d13c@haskell.org> References: <045.101e34e5570fe8f6e2839dfe4e91d13c@haskell.org> Message-ID: <060.49b9c8bc9c4a4b3ba201b9d884ec832b@haskell.org> #15134: enumFrom... aren't really documented. -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Azel Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4737 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 20:08:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 20:08:18 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.5cd93315fe16d929bee241796d7a0673@haskell.org> #9136: Constant folding in Core could be better -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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:D2858 Wiki Page: | -------------------------------------+------------------------------------- Comment (by klapaucius): reverted in https://github.com/ghc/ghc/commit/0e37361392a910ccbbb2719168f4e8d8272b2ae2 but still remains in the 8.6 release notes https://github.com/ghc/ghc/commit/09128f3a3d754abcef63480bc7e2e901d30b155a -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 20:19:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 20:19:05 -0000 Subject: [GHC] #15270: TH doesn't verify name types during conversion In-Reply-To: <046.884d12edfebb255ed830a85371c14d75@haskell.org> References: <046.884d12edfebb255ed830a85371c14d75@haskell.org> Message-ID: <061.59d25bf220bf252e87cfda67f00d8963@haskell.org> #15270: TH doesn't verify name types during conversion -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.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:D4859 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D4859 Comment: Have the beginning of some tests as Phab:D4859. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 16 23:41:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Jun 2018 23:41:05 -0000 Subject: [GHC] #14890: Make Linux slow validate green In-Reply-To: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> References: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> Message-ID: <061.4d90fe25177d02b0a358c518039268fe@haskell.org> #14890: Make Linux slow validate green -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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): D4546, D4636, Wiki Page: | D4712 -------------------------------------+------------------------------------- Changes (by alpmestan): * status: patch => closed * resolution: => fixed Comment: We've seen a green slow validate! We will be tracking/reporting/fixing any failure as appropriate but I'm closing this ticket as we will want to track individual problems separately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 00:35:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 00:35:12 -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.7cc1d17afbe0dd9126e2ddfbca02993e@haskell.org> #7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: abhir00p Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3557 | Differential Rev(s): Wiki Page: wiki:SIMD | -------------------------------------+------------------------------------- Comment (by newhoggy): Has any work been done to introduce the `VecFormat` type? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 00:41:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 00:41:11 -0000 Subject: [GHC] #15278: Add -Werror=compat, enable it in the testsuite Message-ID: <048.fbf132fc1c72e8f658fc554d15eaed54@haskell.org> #15278: Add -Werror=compat, enable it in the testsuite -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 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: -------------------------------------+------------------------------------- = Proposed change Add a flag `-Werror=compat` to GHC which would have the effect of `-Werror=x -Werror=y ...` where `x, y, ...` are warnings from `minusWcompatOpts`. Enable `-Wcompat -Werror=compat` in the testsuite. = Motivation 1. `-Werror=compat` would be a convenient shorthand to ensure forwards- compatibility of code. I can imagine Haskell libs enabling it on their CI. 2. Enabling `-Wcompat -Werror=compat` in the testsuite would allow us to easily see the impact that a new warning has on code. It also means that in the period between adding the warning and making the actual breaking change, all new test cases that are being added to the testsuite will be forwards-compatible. This is good because it will make the actual breaking change contain less irrelevant testsuite updates. The idea came up during my work on Phab:D4834 which defines a new warning and adds it to `-Wcompat`. Ryan Scott raised the following concern: > There are likely many tests in the testsuite that will now fail due to this change—I'm unclear if you're intending to fix them by explicitly quantifying their kind variables, or leaving the new error message as-is. My intention was to update the test cases, but it turned out that I couldn't even locate these test cases without `make EXTRA_HC_OPTS="-fwarn- implicit-kind-vars -Werror=implicit-kind-vars"`. And even if I updated the testsuite, nothing would prevent new test cases that are not forwards- compatible, because the warning isn't enabled by default (and without `-Werror=compat`, enabling `-Wcompat` would not cause test failures in all circumstances). = Implementation plan 1. Add new flags: `-Werror=compat`, `-Wno-error=compat`, `-Wwarn=compat`. 2. Document these flags in the User's Guide. 3. Enable `-Wcompat -Werror=compat` in the testsuite by default and fix all tests that break. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 01:30:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 01:30:36 -0000 Subject: [GHC] #15278: Add -Werror=compat, enable it in the testsuite In-Reply-To: <048.fbf132fc1c72e8f658fc554d15eaed54@haskell.org> References: <048.fbf132fc1c72e8f658fc554d15eaed54@haskell.org> Message-ID: <063.75eeebc01e9b1679f89469fd0059a39c@haskell.org> #15278: Add -Werror=compat, enable it in the testsuite -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 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: | -------------------------------------+------------------------------------- Description changed by int-index: Old description: > = Proposed change > > Add a flag `-Werror=compat` to GHC which would have the effect of > `-Werror=x -Werror=y ...` where `x, y, ...` are warnings from > `minusWcompatOpts`. Enable `-Wcompat -Werror=compat` in the testsuite. > > = Motivation > > 1. `-Werror=compat` would be a convenient shorthand to ensure forwards- > compatibility of code. I can imagine Haskell libs enabling it on their > CI. > > 2. Enabling `-Wcompat -Werror=compat` in the testsuite would allow us to > easily see the impact that a new warning has on code. It also means that > in the period between adding the warning and making the actual breaking > change, all new test cases that are being added to the testsuite will be > forwards-compatible. This is good because it will make the actual > breaking change contain less irrelevant testsuite updates. > > The idea came up during my work on Phab:D4834 which defines a new warning > and adds it to `-Wcompat`. Ryan Scott raised the following concern: > > > There are likely many tests in the testsuite that will now fail due to > this change—I'm unclear if you're intending to fix them by explicitly > quantifying their kind variables, or leaving the new error message as-is. > > My intention was to update the test cases, but it turned out that I > couldn't even locate these test cases without `make EXTRA_HC_OPTS > ="-fwarn-implicit-kind-vars -Werror=implicit-kind-vars"`. And even if I > updated the testsuite, nothing would prevent new test cases that are not > forwards-compatible, because the warning isn't enabled by default (and > without `-Werror=compat`, enabling `-Wcompat` would not cause test > failures in all circumstances). > > = Implementation plan > > 1. Add new flags: `-Werror=compat`, `-Wno-error=compat`, `-Wwarn=compat`. > 2. Document these flags in the User's Guide. > 3. Enable `-Wcompat -Werror=compat` in the testsuite by default and fix > all tests that break. New description: = Proposed change Add a flag `-Werror=compat` to GHC which would have the effect of `-Werror=x -Werror=y ...` where `x, y, ...` are warnings from `minusWcompatOpts`. Enable `-Werror=compat` in the testsuite. = Motivation 1. `-Werror=compat` would be a convenient shorthand to ensure forwards- compatibility of code. I can imagine Haskell libs enabling it on their CI. 2. Enabling `-Werror=compat` in the testsuite would allow us to easily see the impact that a new warning has on code. It also means that in the period between adding the warning and making the actual breaking change, all new test cases that are being added to the testsuite will be forwards- compatible. This is good because it will make the actual breaking change contain less irrelevant testsuite updates. The idea came up during my work on Phab:D4834 which defines a new warning and adds it to `-Wcompat`. Ryan Scott raised the following concern: > There are likely many tests in the testsuite that will now fail due to this change—I'm unclear if you're intending to fix them by explicitly quantifying their kind variables, or leaving the new error message as-is. My intention was to update the test cases, but it turned out that I couldn't even locate these test cases without `make EXTRA_HC_OPTS="-Werror =implicit-kind-vars"`. And even if I updated the testsuite, nothing would prevent new test cases that are not forwards-compatible, because the warning isn't enabled by default (and without `-Werror=compat`, enabling `-Wcompat` would not cause test failures in all circumstances). = Implementation plan 1. Add new flags: `-Werror=compat`, `-Wno-error=compat`, `-Wwarn=compat`. Document these flags in the User's Guide. 3. Enable `-Werror=compat` in the testsuite by default and fix all tests that break. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 02:36:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 02:36:45 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.4f40b2da211b8e8c5a02dea697d29d23@haskell.org> #9136: Constant folding in Core could be better -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.8.2 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:D2858 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: infoneeded => patch * milestone: => 8.6.1 Comment: Oh dear, yes, excellent point; I dropped the ball on this. I'll re-merge for 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 03:26:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 03:26:39 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.4533406b716c882513e9eeba6dbc06a9@haskell.org> #9136: Constant folding in Core could be better -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.8.2 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:D2858 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"60e4bb4d305bc1a65457ee79b1e69c11b9ed747d/ghc" 60e4bb4d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="60e4bb4d305bc1a65457ee79b1e69c11b9ed747d" Enhanced constant folding Until now GHC only supported basic constant folding (lit op lit, expr op 0, etc.). This patch uses laws of +/-/* (associativity, commutativity, distributivity) to support some constant folding into nested expressions. Examples of new transformations: - simple nesting: (10 + x) + 10 becomes 20 + x - deep nesting: 5 + x + (y + (z + (t + 5))) becomes 10 + (x + (y + (z + t))) - distribution: (5 + x) * 6 becomes 30 + 6*x - simple factorization: 5 + x + (x + (x + (x + 5))) becomes 10 + (4 *x) - siblings: (5 + 4*x) - (3*x + 2) becomes 3 + x Test Plan: validate Reviewers: simonpj, austin, bgamari Reviewed By: bgamari Subscribers: thomie GHC Trac Issues: #9136 Differential Revision: https://phabricator.haskell.org/D2858 (cherry picked from commit fea04defa64871caab6339ff3fc5511a272f37c7) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 03:34:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 03:34:47 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.46cf1a9865c57cb8610a17a3a1fff5ac@haskell.org> #9136: Constant folding in Core could be better -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.8.2 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:D2858 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged for 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 03:34:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 03:34:54 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.e96a6f5099c14a9075da429b6f82d0ee@haskell.org> #9136: Constant folding in Core could be better -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | 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:D2858 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 03:46:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 03:46:21 -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.adb5ca9f0c184cc8f1f8b735caf0896e@haskell.org> #12970: Add default implementation for Bits.bitSize -------------------------------------+------------------------------------- Reporter: txnull | Owner: dfeuer Type: feature request | Status: patch Priority: high | Milestone: 8.6.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: | Phab:D4857 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4cd552184cbc5bed33da21497537df4e400a1a2f/ghc" 4cd5521/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4cd552184cbc5bed33da21497537df4e400a1a2f" base: Add default implementation for Data.Bits.bitSize Fixes #12970 and will provide a reasonable migration path for the eventual remove of this function. Test Plan: Validate Reviewers: ekmett, hvr Subscribers: rwbarton, thomie, carter GHC Trac Issues: #12970 Differential Revision: https://phabricator.haskell.org/D4857 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 03:46:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 03:46:21 -0000 Subject: [GHC] #15264: Warn about implicit kind variables with -Wcompat In-Reply-To: <048.2758c96021df3e03a2c44fb779b75b19@haskell.org> References: <048.2758c96021df3e03a2c44fb779b75b19@haskell.org> Message-ID: <063.fa6a51bbf5ae1fd215b187a12e710341@haskell.org> #15264: Warn about implicit kind variables with -Wcompat -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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:D4834 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8df24474d0194d28b8273c1539af05793156e23f/ghc" 8df24474/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8df24474d0194d28b8273c1539af05793156e23f" Warn about implicit kind variables with -Wcompat According to an accepted proposal https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/002 4-no-kind-vars.rst With -Wcompat, warn if a kind variable is brought into scope implicitly in a type with an explicit forall. This applies to type signatures and to other contexts that allow a forall with the forall-or-nothing rule in effect (for example, class instances). Test Plan: Validate Reviewers: goldfire, hvr, bgamari, RyanGlScott Reviewed By: goldfire Subscribers: RyanGlScott, rwbarton, thomie, carter GHC Trac Issues: #15264 Differential Revision: https://phabricator.haskell.org/D4834 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 09:16:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 09:16:46 -0000 Subject: [GHC] #8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C-- In-Reply-To: <045.bc17add61e78f8a5d6d2200d15a0dca2@haskell.org> References: <045.bc17add61e78f8a5d6d2200d15a0dca2@haskell.org> Message-ID: <060.a895da7df853082061b632b3f2291ea6@haskell.org> #8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C-- -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 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 osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 09:17:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 09:17:47 -0000 Subject: [GHC] #8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C-- In-Reply-To: <045.bc17add61e78f8a5d6d2200d15a0dca2@haskell.org> References: <045.bc17add61e78f8a5d6d2200d15a0dca2@haskell.org> Message-ID: <060.d1694bd2352432a96e1b71a0715ef36b@haskell.org> #8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C-- -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 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: | -------------------------------------+------------------------------------- Comment (by osa1): This would be really helpful when debugging. Currently we have to use NULL for the location in `assertFail`, causing error messages like `ghc-stage2: internal error: ASSERTION FAILED: file (null), line 1302`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 10:52:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 10:52:53 -0000 Subject: [GHC] #8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C-- In-Reply-To: <045.bc17add61e78f8a5d6d2200d15a0dca2@haskell.org> References: <045.bc17add61e78f8a5d6d2200d15a0dca2@haskell.org> Message-ID: <060.0236ee7e80beee6a1718dd921870f720@haskell.org> #8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C-- -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 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: | -------------------------------------+------------------------------------- Comment (by osa1): It seems like we currently support string literals in Cmm. I have a patch but don't have time to validate it now, I'll submit it later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 10:53:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 10:53:11 -0000 Subject: [GHC] #10869: Option to dump preprocessed source In-Reply-To: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> References: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> Message-ID: <061.af30cc31c6986fb463777be974e2b2e1@haskell.org> #10869: Option to dump preprocessed source -------------------------------------+------------------------------------- Reporter: phischu | Owner: RolandSenn Type: feature request | Status: patch Priority: low | Milestone: Component: Driver | Version: 7.10.2 Resolution: | Keywords: easy 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 RolandSenn): * status: new => patch Comment: DRAFT patch uploaded to https://phabricator.haskell.org/D4861 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 13:05:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 13:05:25 -0000 Subject: [GHC] #15279: CPP #includes may result in nonsensical SrcSpans Message-ID: <045.4d706fecf4a6cf42667f6871be2d3572@haskell.org> #15279: CPP #includes may result in nonsensical SrcSpans -------------------------------------+------------------------------------- Reporter: wz1000 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Consider the following code in `compiler/prelude/PrimOp.hs` {{{#!hs primOpInfo :: PrimOp -> PrimOpInfo #include "primop-primop-info.hs-incl" primOpInfo _ = error "primOpInfo: unknown primop" -- line 175 in PrimOp.hs }}} The MatchGroup for primOpInfo includes the `SrcSpan` `compiler/stage2/build/primop-primop-info.hs-incl:(1,1)-(175,49)` Here is line 175 in `primop-primop-info.hs-incl` {{{#!hs primOpInfo IndexSmallArrayOp = mkGenPrimOp (fsLit "indexSmallArray#") [alphaTyVar] [mkSmallArrayPrimTy alphaTy, intPrimTy] ((mkTupleTy Unboxed [alphaTy])) }}} The `SrcSpan`s end is somewhere in the middle of that line. I guess this occurs because `combineSrcSpans` doesn't take the file into account. I can think of multiple ways to fix this: 1. Make `combineSrcSpans` output an `UnhelpfulSrcSpan` if the files don't match(quick and easy) 2. Extend SrcSpan to properly support things spanning multiple files 3. Don't fix: People who use CPP get what they deserve. Option 3 is not unreasonable as options 1 and 2 will incur some performance penalty. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 13:06:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 13:06:24 -0000 Subject: [GHC] #15279: CPP #includes may result in nonsensical SrcSpans In-Reply-To: <045.4d706fecf4a6cf42667f6871be2d3572@haskell.org> References: <045.4d706fecf4a6cf42667f6871be2d3572@haskell.org> Message-ID: <060.6f813acc18ad0644731ff2167a4f9fa7@haskell.org> #15279: CPP #includes may result in nonsensical SrcSpans -------------------------------------+------------------------------------- Reporter: wz1000 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.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 wz1000): * cc: bgamari, gbaz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 13:15:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 13:15:30 -0000 Subject: [GHC] #15279: CPP #includes may result in nonsensical SrcSpans In-Reply-To: <045.4d706fecf4a6cf42667f6871be2d3572@haskell.org> References: <045.4d706fecf4a6cf42667f6871be2d3572@haskell.org> Message-ID: <060.037dfef8d40473d638a8e5d14dc27d6e@haskell.org> #15279: CPP #includes may result in nonsensical SrcSpans -------------------------------------+------------------------------------- Reporter: wz1000 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: cpp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #14113 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => cpp * related: => #14113 Comment: See #14113 for another example of CPP ruining `SrcSpan`s. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 13:32:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 13:32:40 -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.1e0f77b3dc70e41b72e55be995e746c9@haskell.org> #12970: Add default implementation for Bits.bitSize -------------------------------------+------------------------------------- Reporter: txnull | Owner: dfeuer Type: feature request | Status: closed Priority: high | Milestone: 8.6.1 Component: libraries/base | 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:D3723, Wiki Page: | Phab:D4857 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: I've gone ahead with this for 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 13:39:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 13:39:14 -0000 Subject: [GHC] #15280: StgCmmEnv: variable not found Message-ID: <046.bcf0d62450445af435476edca8eeba79@haskell.org> #15280: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: wanjach | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ stack build warduino-0.1.0.0: build (lib + exe) Preprocessing library warduino-0.1.0.0... Preprocessing executable 'blink' for warduino-0.1.0.0... Preprocessing executable 'lcd' for warduino-0.1.0.0... [1 of 1] Compiling Main ( lcd/Main.hs, .stack-work/dist/x86_64 -linux-nix/Cabal-1.24.2.0/build/lcd/lcd-tmp/Main.o ) /home/user/src/warduino/lcd/Main.hs:31:5: warning: [-Wname-shadowing] This binding for `lcd' shadows the existing binding defined at lcd/Main.hs:30:1 /home/user/src/warduino/lcd/Main.hs:33:9: warning: [-Wname-shadowing] This binding for `print' shadows the existing binding imported from `Prelude' at lcd/Main.hs:2:8-11 (and originally defined in `System.IO') ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): StgCmmEnv: variable not found lcd_a3jG local binds for: delay_deep'1 $trModule1 $trModule2 delay lcdController $trModule lcd5 lcdController1 lcdController2 lcdController3 lcdController4 lcdController5 lcdController6 lcdController7 lcd6 lcd7 lvl_r9Ee lvl1_r9Ef lvl2_r9Eg lvl3_r9Eh lvl4_r9Ei lvl5_r9Ej lvl6_r9Ek lvl7_r9El delay_deep' ipv1_s9Ev addr#_s9Ew ds4_s9EA sat_s9EB sat_s9EC sat_s9ED Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building custom Setup.hs for package warduino-0.1.0.0 using: }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 13:41:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 13:41:28 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.f6409558d76a98739c5ff72c9be575bf@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Sigh; this is all just very unfortunate. It seems that there is something funny about Apple's clang (surprise surprise!) The patch as-merged breaks under standard Clang, which apparently inserts the necessary CFI directives into inline assembler, just as GCC does. I'm going to revert until we have a better understanding of what is going on here. Carter, can you look into precisely when this happens? Specifically which Clang version are you seeing break? Which Clang versions work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 13:43:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 13:43:10 -0000 Subject: [GHC] #15280: StgCmmEnv: variable not found In-Reply-To: <046.bcf0d62450445af435476edca8eeba79@haskell.org> References: <046.bcf0d62450445af435476edca8eeba79@haskell.org> Message-ID: <061.0678314d7321944f26afc97f4e5b3a60@haskell.org> #15280: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: wanjach | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | 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 wanjach): * Attachment "warduino_bugreport.tar.bz2" added. source -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 13:44:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 13:44:21 -0000 Subject: [GHC] #15280: StgCmmEnv: variable not found In-Reply-To: <046.bcf0d62450445af435476edca8eeba79@haskell.org> References: <046.bcf0d62450445af435476edca8eeba79@haskell.org> Message-ID: <061.d6031cc581d15f5e63084d4954b11761@haskell.org> #15280: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: wanjach | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | 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 wanjach): Project uses Haskino as a local dependency: https://github.com/ku- fpg/haskino -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 13:51:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 13:51:56 -0000 Subject: [GHC] #15281: GHC 8.6.1 can't be bootstrapped with GHC 8.2.1 Message-ID: <046.1f055b819ed7038e5e76ad844c8570c7@haskell.org> #15281: GHC 8.6.1 can't be bootstrapped with GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- 60e4bb4d305bc1a65457ee79b1e69c11b9ed747d (#9136) triggers a bug in GHC 8.2.1 which causes the build to fail with, {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): runtimeRepPrimRep typePrimRep (r_aqbE :: TYPE rep_aqbD) rep_aqbD 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/simplStg/RepType.hs:360:5 in ghc:RepType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This is a manifestation of #14393, which is fixed in 8.2.2 and later. We should probably add a `configure` check warning about this brokenness when the user tries to bootstrap with GHC 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 13:55:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 13:55:36 -0000 Subject: [GHC] #15281: GHC 8.6.1 can't be bootstrapped with GHC 8.2.1 In-Reply-To: <046.1f055b819ed7038e5e76ad844c8570c7@haskell.org> References: <046.1f055b819ed7038e5e76ad844c8570c7@haskell.org> Message-ID: <061.bfc04bdb9d512c0b184207726edcbcf9@haskell.org> #15281: GHC 8.6.1 can't be bootstrapped with GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4863 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4863 Comment: Phab:D4863 adds a `configure` check to avoid confusion due to this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 14:03:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 14:03:54 -0000 Subject: [GHC] #15269: Qualified Names in --show-iface output In-Reply-To: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> References: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> Message-ID: <061.bc16493f571f4d47e9224cf1db40785c@haskell.org> #15269: Qualified Names in --show-iface output -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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:D4852 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sjakobi): I realized that I don't know the right terminology for names from the current modules and names from other modules. Is there any? If not, are "local" and "non-local" names good words for this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 14:05:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 14:05:05 -0000 Subject: [GHC] #15279: CPP #includes may result in nonsensical SrcSpans In-Reply-To: <045.4d706fecf4a6cf42667f6871be2d3572@haskell.org> References: <045.4d706fecf4a6cf42667f6871be2d3572@haskell.org> Message-ID: <060.9e12d50b39704e295f88ccb4f17106dc@haskell.org> #15279: CPP #includes may result in nonsensical SrcSpans -------------------------------------+------------------------------------- Reporter: wz1000 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: cpp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #14113 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed (2) seems like it might be a bit more complexity than warranted by the severity of the issue. (1) on the other hand seems a bit unfortunate since it may lose useful (albeit also slightly misleading) information. Nevertheless, I agree that (3) is also unfortunately so yes, let's just move ahead with (1). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 14:30:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 14:30:25 -0000 Subject: [GHC] #15063: T3001-2 fails on i386 Linux In-Reply-To: <046.fa478fb40ce13bbb24172a958e864762@haskell.org> References: <046.fa478fb40ce13bbb24172a958e864762@haskell.org> Message-ID: <061.25ac5b3d5a023cc2aad531d1ad4ac25b@haskell.org> #15063: T3001-2 fails on i386 Linux -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Profiling | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15087, #15165, | Differential Rev(s): #7836 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 15:14:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 15:14:37 -0000 Subject: [GHC] #15280: StgCmmEnv: variable not found In-Reply-To: <046.bcf0d62450445af435476edca8eeba79@haskell.org> References: <046.bcf0d62450445af435476edca8eeba79@haskell.org> Message-ID: <061.19b193d968c08ec212706e103a4f5649@haskell.org> #15280: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: wanjach | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Linux | 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): * status: new => closed * resolution: => invalid Comment: It looks like this has been also filed against [[https://github.com/ku- fpg/haskino/issues/5|haskuino]]. I suspect this is a plugin bug so I'm going to close for now. Do feel free to re-open if this turns out not to be true. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 15:17:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 15:17:50 -0000 Subject: [GHC] #15281: GHC 8.6.1 can't be bootstrapped with GHC 8.2.1 In-Reply-To: <046.1f055b819ed7038e5e76ad844c8570c7@haskell.org> References: <046.1f055b819ed7038e5e76ad844c8570c7@haskell.org> Message-ID: <061.0073b7bec361abb8d400d2d908ac92cd@haskell.org> #15281: GHC 8.6.1 can't be bootstrapped with GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4863 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d1c7239c037e267873658160b5c290f08f0d6502/ghc" d1c7239/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d1c7239c037e267873658160b5c290f08f0d6502" configure: Fail when bootstrapping with GHC 8.2.1 See #15281 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 15:17:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 15:17:50 -0000 Subject: [GHC] #15063: T3001-2 fails on i386 Linux In-Reply-To: <046.fa478fb40ce13bbb24172a958e864762@haskell.org> References: <046.fa478fb40ce13bbb24172a958e864762@haskell.org> Message-ID: <061.1975916546ccf8b881bebdbf71e2bbf1@haskell.org> #15063: T3001-2 fails on i386 Linux -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Profiling | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15087, #15165, | Differential Rev(s): #7836 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"749bc1a0b08c75b69b5ea7d6faab3626b1d75c03/ghc" 749bc1a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="749bc1a0b08c75b69b5ea7d6faab3626b1d75c03" testsuite: Mark T3001-2 as broken on 32-bit platforms Due to #15063. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 15:17:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 15:17:50 -0000 Subject: [GHC] #15061: print022 testcase fails on i386 In-Reply-To: <046.070201c29a49dce5435517538bdcfad1@haskell.org> References: <046.070201c29a49dce5435517538bdcfad1@haskell.org> Message-ID: <061.c97f67d587365cc900a3a3c74f3f8cc7@haskell.org> #15061: print022 testcase fails on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: ci-breakage 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:"9897440ec9fbf17fb609e9a0d9456861c5f7f24a/ghc" 9897440/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9897440ec9fbf17fb609e9a0d9456861c5f7f24a" testsuite: Mark print022 as broken on 32-bit platforms Due to #15061. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 15:17:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 15:17:50 -0000 Subject: [GHC] #14487: Can't Hide Field When DuplicateRecordFields Is Enabled In-Reply-To: <052.55fcb5f24afe31abafd77e2adcf88ad5@haskell.org> References: <052.55fcb5f24afe31abafd77e2adcf88ad5@haskell.org> Message-ID: <067.8bad090afd31a71d871b06285b3931e4@haskell.org> #14487: Can't Hide Field When DuplicateRecordFields Is Enabled -------------------------------------+------------------------------------- Reporter: iansullivan88 | Owner: (none) Type: bug | Status: patch Priority: lowest | Milestone: 8.6.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: | DuplicateRecordFields ORF Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T14487 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4805 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ccd8ce405db89142932daea3fdace8814b110798/ghc" ccd8ce40/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ccd8ce405db89142932daea3fdace8814b110798" Handle DuplicateRecordFields correctly in filterImports (fixes #14487) filterImports needed a small adjustment to correctly handle record field definitions arising from modules with DuplicateRecordFields enabled. Previously hiding fields was not possible with DuplicateRecordFields enabled. Test Plan: new test rename/should_compile/T14487 Reviewers: bgamari Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #14487 Differential Revision: https://phabricator.haskell.org/D4805 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 15:42:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 15:42:50 -0000 Subject: [GHC] #8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C-- In-Reply-To: <045.bc17add61e78f8a5d6d2200d15a0dca2@haskell.org> References: <045.bc17add61e78f8a5d6d2200d15a0dca2@haskell.org> Message-ID: <060.c68b5a45d7d96bfb876e6370aa16a4c2@haskell.org> #8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C-- -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4862 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * differential: => Phab:D4862 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 15:42:59 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 15:42:59 -0000 Subject: [GHC] #8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C-- In-Reply-To: <045.bc17add61e78f8a5d6d2200d15a0dca2@haskell.org> References: <045.bc17add61e78f8a5d6d2200d15a0dca2@haskell.org> Message-ID: <060.149e8c94e241bf02e3291f3057e51d0b@haskell.org> #8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C-- -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4862 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 16:33:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 16:33:00 -0000 Subject: [GHC] #13080: Memory leak caused by nested monadic loops In-Reply-To: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> References: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> Message-ID: <063.c4784ac8250268eab55c0066263e722c@haskell.org> #13080: Memory leak caused by nested monadic loops -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 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): * milestone: 8.6.1 => 8.8.1 Comment: This won't be fixed in 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 16:34:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 16:34:24 -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.92cb65723653ec7f045ab0adc721142e@haskell.org> #14005: Explore moving from pretty to prettyprinter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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): Phab:D3650 Wiki Page: | wiki:PrettyErrors | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => Comment: Indeed I've recently rebased this and found that performance is even worse now than it was previously. I'm rather doubting that this is a direction that we will want to pursue further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 16:34:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 16:34:55 -0000 Subject: [GHC] #14295: tagToEnum# leads to some silly closures In-Reply-To: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> References: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> Message-ID: <060.c35757e6d303972b2bd350e5000daf46@haskell.org> #14295: tagToEnum# leads to some silly closures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags 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): * milestone: 8.6.1 => ⊥ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 16:38:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 16:38:25 -0000 Subject: [GHC] #15113: Do not make CAFs from literal strings In-Reply-To: <046.d042ad82da8658ea11bcd44bf2d86387@haskell.org> References: <046.d042ad82da8658ea11bcd44bf2d86387@haskell.org> Message-ID: <061.b25c33c6911d8f920a9bc18c2784dcee@haskell.org> #15113: Do not make CAFs from literal strings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4717 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4717 * milestone: 8.6.1 => 8.8.1 Comment: Phab:D4717 marks top-level strings as single-entry. I haven't yet had a chance to characterise the effect of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 16:42:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 16:42:07 -0000 Subject: [GHC] #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented In-Reply-To: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> References: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> Message-ID: <061.024d316a4f134744c4c6294e2cbcc1b9@haskell.org> #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Azel Type: feature request | Status: merge Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.2 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:D4736 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"793902e6891c30150fd3ac1e0e471269a4766780/ghc" 793902e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="793902e6891c30150fd3ac1e0e471269a4766780" Improve documentation of Eq, Ord instances for Float and Double Reviewers: sjakobi, dfeuer, bgamari, hvr Reviewed By: sjakobi, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15078 Differential Revision: https://phabricator.haskell.org/D4736 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 16:42:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 16:42:07 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.3a01de9b185bf114660724974e8c5c3b@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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:D4783 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"df0f148feae4c3b9653260edff843d561d6d5918/ghc" df0f148f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="df0f148feae4c3b9653260edff843d561d6d5918" Improve error message when importing an unusable package If a module cannot be found because it is ignored or from an unusable package, report this to the user and the reason it is unusable. Currently, GHC displays the standard "Cannot find module error". For example: ``` : error: Could not find module ‘Control.Monad.Random’ Perhaps you meant Control.Monad.Reader (from mtl-2.2.2) Control.Monad.Cont (from mtl-2.2.2) Control.Monad.Error (from mtl-2.2.2) ``` GHC does, however, indicate unusable/ignored packages with the -v flag: ``` package MonadRandom-0.5.1-1421RgpXdhC8e8UI7D3emA is unusable due to missing dependencies: fail-4.9.0.0-BAHmj60kS5K7NVhhKpm9J5 ``` With this change, I took that message and added it to the output of the "Cannot find module" message. Reviewers: bgamari, dfeuer Reviewed By: bgamari Subscribers: Phyx, dfeuer, rwbarton, thomie, carter GHC Trac Issues: #4806 Differential Revision: https://phabricator.haskell.org/D4783 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 16:43:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 16:43:57 -0000 Subject: [GHC] #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented In-Reply-To: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> References: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> Message-ID: <061.75493f40c2d5cabfc16d194ce8706c9a@haskell.org> #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Azel Type: feature request | Status: merge Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.2 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:D4736 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I suspect there is more work to be done here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 16:44:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 16:44:13 -0000 Subject: [GHC] #14487: Can't Hide Field When DuplicateRecordFields Is Enabled In-Reply-To: <052.55fcb5f24afe31abafd77e2adcf88ad5@haskell.org> References: <052.55fcb5f24afe31abafd77e2adcf88ad5@haskell.org> Message-ID: <067.63ad84d3ced3d9e78fd5328cee8fc59d@haskell.org> #14487: Can't Hide Field When DuplicateRecordFields Is Enabled -------------------------------------+------------------------------------- Reporter: iansullivan88 | Owner: (none) Type: bug | Status: closed Priority: lowest | Milestone: 8.6.1 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: | DuplicateRecordFields ORF Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T14487 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4805 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 16:44:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 16:44:36 -0000 Subject: [GHC] #15264: Warn about implicit kind variables with -Wcompat In-Reply-To: <048.2758c96021df3e03a2c44fb779b75b19@haskell.org> References: <048.2758c96021df3e03a2c44fb779b75b19@haskell.org> Message-ID: <063.9a7c400d0671ca9f1957addc8c234ca2@haskell.org> #15264: Warn about implicit kind variables with -Wcompat -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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:D4834 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 17:18:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 17:18:21 -0000 Subject: [GHC] #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented In-Reply-To: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> References: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> Message-ID: <061.3b5940181e78c13670bb9e7ad226bd13@haskell.org> #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Azel Type: feature request | Status: merge Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.2 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:D4736 Wiki Page: | -------------------------------------+------------------------------------- Description changed by sjakobi: Old description: > As beginning Haskellers regularly ask about these laws and instances I > think it would be good to have them documented where they are defined. > > Here's a first draft of what I have in mind for `Float`'s `Eq` and `Ord` > instances: > > {{{ > -- | Note that in the presence of @NaN@, this instance does not satisfy > -- reflexivity: > -- > -- >>> nan = 0/0 :: Float > -- >>> nan == nan > -- False > -- > -- Also note that this instance does not encode structural equality: > -- > -- >>> 0 == (-0 :: Float) > -- True > -- >>> recip 0 == recip (-0 :: Float) > -- False > instance Eq Float where > (==) = eqFloat > }}} > > {{{ > -- | Due to the peculiarities of @NaN@, this instance does not satisfy > totality: > -- > -- >>> nan = 0/0 :: Float > -- >>> nan <= nan > -- False > -- > -- Another special case with @NaN@ is: > -- > -- @ > -- 'compare' x y > -- | 'isNaN' x || 'isNaN' y = 'GT' > -- @ > -- > -- However > -- > -- @ > -- nan > _ = False > -- _ > nan = False > -- @ > -- > -- In consequence we also have: > -- > -- @ > -- 'max' x y | 'isNaN' x || 'isNaN' y = x > -- 'min' x y | 'isNaN' x || 'isNaN' y = y > -- @ > -- > -- Ignoring @NaN@, @Infinity@ and @-Infinity@ are the respective greatest > -- and least elements of 'Float'. > instance Ord Float where > (F# x) `compare` (F# y) > = if isTrue# (x `ltFloat#` y) then LT > else if isTrue# (x `eqFloat#` y) then EQ > else GT > > (F# x) < (F# y) = isTrue# (x `ltFloat#` y) > (F# x) <= (F# y) = isTrue# (x `leFloat#` y) > (F# x) >= (F# y) = isTrue# (x `geFloat#` y) > (F# x) > (F# y) = isTrue# (x `gtFloat#` y) > }}} New description: As beginning Haskellers regularly ask about these laws and instances I think it would be good to have them documented where they are defined. === Documented so far: (in 793902e6891c30150fd3ac1e0e471269a4766780) ==== Classes * `Eq` * `Floating` * `Fractional` * `Integral` * `Num` * `Ord` ==== Non-abiding instances * `CDouble` (shares `Double`'s deficiencies) * `CFloat` (shares `Float`'s deficiencies) * `Complex a` (inherits deficiencies) * `Double`: `Eq`, `Ord`, `Fractional`, `Num` * `Float`: `Eq`, `Ord`, `Fractional`, `Num` * `Ratio a` (inherits deficiencies) * `Natural`: `Num` === TODO: * `RealFrac` -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 17:21:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 17:21:25 -0000 Subject: [GHC] #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented In-Reply-To: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> References: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> Message-ID: <061.f926850fd54b33d61e4a0ff66614609b@haskell.org> #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Azel Type: feature request | Status: merge Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.2 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:D4736 Wiki Page: | -------------------------------------+------------------------------------- Description changed by sjakobi: Old description: > As beginning Haskellers regularly ask about these laws and instances I > think it would be good to have them documented where they are defined. > > === Documented so far: > > (in 793902e6891c30150fd3ac1e0e471269a4766780) > > ==== Classes > > * `Eq` > * `Floating` > * `Fractional` > * `Integral` > * `Num` > * `Ord` > > ==== Non-abiding instances > > * `CDouble` (shares `Double`'s deficiencies) > * `CFloat` (shares `Float`'s deficiencies) > * `Complex a` (inherits deficiencies) > * `Double`: `Eq`, `Ord`, `Fractional`, `Num` > * `Float`: `Eq`, `Ord`, `Fractional`, `Num` > * `Ratio a` (inherits deficiencies) > * `Natural`: `Num` > > === TODO: > > * `RealFrac` New description: As beginning Haskellers regularly ask about these laws and instances I think it would be good to have them documented where they are defined. === Documented so far: (in 793902e6891c30150fd3ac1e0e471269a4766780) ==== Classes * `Eq` * `Floating` * `Fractional` * `Integral` * `Num` * `Ord` ==== Non-abiding instances * `CDouble` (shares `Double`'s deficiencies) * `CFloat` (shares `Float`'s deficiencies) * `Complex a` (inherits deficiencies) * `Double`: `Eq`, `Ord`, `Fractional`, `Num` * `Float`: `Eq`, `Ord`, `Fractional`, `Num` * `Ratio a` (inherits deficiencies) * `Natural`: `Num` === TODO (This is not an exhaustive list, please add more) * `RealFrac` -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 17:37:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 17:37:47 -0000 Subject: [GHC] #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented In-Reply-To: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> References: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> Message-ID: <061.9959815c70891aed774a8bb979a7fd32@haskell.org> #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Azel Type: feature request | Status: merge Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.2 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:D4736 Wiki Page: | -------------------------------------+------------------------------------- Old description: > As beginning Haskellers regularly ask about these laws and instances I > think it would be good to have them documented where they are defined. > > === Documented so far: > > (in 793902e6891c30150fd3ac1e0e471269a4766780) > > ==== Classes > > * `Eq` > * `Floating` > * `Fractional` > * `Integral` > * `Num` > * `Ord` > > ==== Non-abiding instances > > * `CDouble` (shares `Double`'s deficiencies) > * `CFloat` (shares `Float`'s deficiencies) > * `Complex a` (inherits deficiencies) > * `Double`: `Eq`, `Ord`, `Fractional`, `Num` > * `Float`: `Eq`, `Ord`, `Fractional`, `Num` > * `Ratio a` (inherits deficiencies) > * `Natural`: `Num` > > === TODO > > (This is not an exhaustive list, please add more) > > * `RealFrac` New description: As beginning Haskellers regularly ask about these laws and instances I think it would be good to have them documented where they are defined. === Documented so far: (in 793902e6891c30150fd3ac1e0e471269a4766780) ==== Classes * `Eq` * `Floating` * `Fractional` * `Integral` * `Num` * `Ord` ==== Non-abiding instances * `CDouble` (shares `Double`'s deficiencies) * `CFloat` (shares `Float`'s deficiencies) * `Complex a` (inherits deficiencies) * `Double`: `Eq`, `Ord`, `Fractional`, `Num` * `Float`: `Eq`, `Ord`, `Fractional`, `Num` * `Ratio a` (inherits deficiencies) * `Natural`: `Num` === TODO (This is not an exhaustive list, please add more) * `RealFrac` * the Arrow classes * `Word` & co -- Comment (by Azel): What structure would `RealFrac` represent though? And do all instances of `Monad`, `Functor` and `Applicative` in base respect the relevant laws? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 18:01:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 18:01:28 -0000 Subject: [GHC] #15281: GHC 8.6.1 can't be bootstrapped with GHC 8.2.1 In-Reply-To: <046.1f055b819ed7038e5e76ad844c8570c7@haskell.org> References: <046.1f055b819ed7038e5e76ad844c8570c7@haskell.org> Message-ID: <061.ac2d9a647a9002b0a22992f6c662b69d@haskell.org> #15281: GHC 8.6.1 can't be bootstrapped with GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4863 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 18:01:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 18:01:35 -0000 Subject: [GHC] #15281: GHC 8.6.1 can't be bootstrapped with GHC 8.2.1 In-Reply-To: <046.1f055b819ed7038e5e76ad844c8570c7@haskell.org> References: <046.1f055b819ed7038e5e76ad844c8570c7@haskell.org> Message-ID: <061.1b392f38395165f4565b347399be32e0@haskell.org> #15281: GHC 8.6.1 can't be bootstrapped with GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4863 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 18:01:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 18:01:42 -0000 Subject: [GHC] #15281: GHC 8.6.1 can't be bootstrapped with GHC 8.2.1 In-Reply-To: <046.1f055b819ed7038e5e76ad844c8570c7@haskell.org> References: <046.1f055b819ed7038e5e76ad844c8570c7@haskell.org> Message-ID: <061.a1bbf225602144781b1b6e0b96c23c9f@haskell.org> #15281: GHC 8.6.1 can't be bootstrapped with GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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:D4863 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 18:40:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 18:40:42 -0000 Subject: [GHC] #14845: TypeInType, index GADT by constraint witness In-Reply-To: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> References: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> Message-ID: <066.3aa031500e84ccfeeaeedd67a71890b8@haskell.org> #14845: TypeInType, index GADT by constraint witness -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13895, #15215 | Differential Rev(s): Phab:D4728 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c63754118cf6c3d0947d0c611f1db39c78acf1b7/ghc" c637541/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c63754118cf6c3d0947d0c611f1db39c78acf1b7" Provide a better error message for unpromotable data constructor contexts Trac #14845 brought to light a corner case where a data constructor could not be promoted (even with `-XTypeInType`) due to an unpromotable constraint in its context. However, the error message was less than helpful, so this patch adds an additional check to `tcTyVar` catch unpromotable data constructors like these //before// they're promoted, and to give a sensible error message in such cases. Test Plan: make test TEST="T13895 T14845" Reviewers: simonpj, goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #13895, #14845 Differential Revision: https://phabricator.haskell.org/D4728 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 18:40:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 18:40:42 -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.6c3b002e211391c066f0a1d398bf367f@haskell.org> #13895: "Illegal constraint in a type" error - is it fixable? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12045, #14845, | Differential Rev(s): Phab:D4728 #14859 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c63754118cf6c3d0947d0c611f1db39c78acf1b7/ghc" c637541/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c63754118cf6c3d0947d0c611f1db39c78acf1b7" Provide a better error message for unpromotable data constructor contexts Trac #14845 brought to light a corner case where a data constructor could not be promoted (even with `-XTypeInType`) due to an unpromotable constraint in its context. However, the error message was less than helpful, so this patch adds an additional check to `tcTyVar` catch unpromotable data constructors like these //before// they're promoted, and to give a sensible error message in such cases. Test Plan: make test TEST="T13895 T14845" Reviewers: simonpj, goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #13895, #14845 Differential Revision: https://phabricator.haskell.org/D4728 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 18:40:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 18:40:42 -0000 Subject: [GHC] #8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C-- In-Reply-To: <045.bc17add61e78f8a5d6d2200d15a0dca2@haskell.org> References: <045.bc17add61e78f8a5d6d2200d15a0dca2@haskell.org> Message-ID: <060.a01219ed168494ce4f6177d65e6d5aa3@haskell.org> #8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C-- -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4862 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"008ea12dd93b9f9104f0b532b278a31b719bafb8/ghc" 008ea12d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="008ea12dd93b9f9104f0b532b278a31b719bafb8" Use __FILE__ for Cmm assertion locations, fix #8619 It seems like we currently support string literals in Cmm, so we can use __LINE__ CPP macro in assertion macros. This improves error messages that previously looked like ASSERTION FAILED: file (null), line 1302 (null) part now shows the actual file name. Also inline some single-use string literals in PrimOps.cmm. Reviewers: bgamari, simonmar, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4862 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 18:40:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 18:40:42 -0000 Subject: [GHC] #15278: Add -Werror=compat, enable it in the testsuite In-Reply-To: <048.fbf132fc1c72e8f658fc554d15eaed54@haskell.org> References: <048.fbf132fc1c72e8f658fc554d15eaed54@haskell.org> Message-ID: <063.1c605065e86e9dfe53c58f05667bb815@haskell.org> #15278: Add -Werror=compat, enable it in the testsuite -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"04e9fe5c7d3c2bac46933e3d647e561cb741edf4/ghc" 04e9fe5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="04e9fe5c7d3c2bac46933e3d647e561cb741edf4" Add -Werror=compat Add a flag `-Werror=compat` to GHC which has the effect of `-Werror=x -Werror=y ...`, where `x, y, ...` are warnings from the `-Wcompat` option group. Test Plan: ./validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15278 Differential Revision: https://phabricator.haskell.org/D4860 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 18:46:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 18:46:10 -0000 Subject: [GHC] #8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C-- In-Reply-To: <045.bc17add61e78f8a5d6d2200d15a0dca2@haskell.org> References: <045.bc17add61e78f8a5d6d2200d15a0dca2@haskell.org> Message-ID: <060.3f77847201309dad6d1cd018d1c98164@haskell.org> #8619: Support anonymous string literals in C-- (OR) give better ASSERT failure messages in C-- -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.7 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:D4862 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 18:52:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 18:52: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.378c3d8aee817415645b44311bbf0a35@haskell.org> #13895: "Illegal constraint in a type" error - is it fixable? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: duplicate | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12045, #14845, | Differential Rev(s): Phab:D4728 #14859 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => duplicate Comment: This ticket is essentially a dual feature request for explicit impredicativity and visible kind application, which are being tracked separately in #14859 and #12045, respectively. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 18:58:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 18:58:47 -0000 Subject: [GHC] #15051: -split-objs generates excessively many files on Windows In-Reply-To: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> References: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> Message-ID: <060.9cb01be18579cc349f3bb17063046ea5@haskell.org> #15051: -split-objs generates excessively many files on Windows ---------------------------------+-------------------------------------- Reporter: kanetw | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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 bgamari): It looks like the source of the symbols is the `Typeable` `KindRep`s generated for the tuple types. However, I'm rather surprised that we are just seeing this now; this logic has been present since 8.2. Are you sure this is a new problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 18:59:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 18:59:35 -0000 Subject: [GHC] #15282: Document how equality-bearing constructors are promoted in Core Message-ID: <050.090e2292f6620e97635bea0372f57c50@haskell.org> #15282: Document how equality-bearing constructors are promoted in Core -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14845 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In Phab:D4728, Simon was utterly baffled as to how one could promote the `MkT` constructor in: {{{#!hs data T a where MkT :: (a ~ Int) => T a }}} Richard knows the inner machinations of how this works (including what coercions are used in the Core that `'MkT` desugars to), but not many others do. Simon requested that Richard document this knowledge in a Note somewhere. This ticket exists to keep track of this request. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 18:59:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 18:59:45 -0000 Subject: [GHC] #15282: Document how equality-bearing constructors are promoted in Core In-Reply-To: <050.090e2292f6620e97635bea0372f57c50@haskell.org> References: <050.090e2292f6620e97635bea0372f57c50@haskell.org> Message-ID: <065.7e537e9bfd4268c0467871bc29d84d22@haskell.org> #15282: Document how equality-bearing constructors are promoted in Core -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14845 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: (none) => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 19:02:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 19:02:27 -0000 Subject: [GHC] #14845: TypeInType, index GADT by constraint witness In-Reply-To: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> References: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> Message-ID: <066.25b6984aa48b5ad0f961fbcd1ac98668@haskell.org> #14845: TypeInType, index GADT by constraint witness -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_fail/T14845_fail1, | dependent/should_fail/T14845_fail2 Blocked By: | Blocking: Related Tickets: #13895, #15215, | Differential Rev(s): Phab:D4728 #15282 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => dependent/should_fail/T14845_fail1, dependent/should_fail/T14845_fail2 * resolution: => fixed * related: #13895, #15215 => #13895, #15215, #15282 * milestone: => 8.6.1 Comment: Commit c63754118cf6c3d0947d0c611f1db39c78acf1b7 improves the error message substantially. As mentioned in comment:4, we can't actually allow this program until dependent types are available. The remaining task from this ticket is to document how a program like the one in comment:16 desugars into coercions at the Core Level. I've opened #15282 for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 19:03:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 19:03:22 -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.d7d0bc1ccd7cfb479bc5f9cbf079b225@haskell.org> #13895: "Illegal constraint in a type" error - is it fixable? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: duplicate | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_fail/T13895 Blocked By: | Blocking: Related Tickets: #12045, #14845, | Differential Rev(s): Phab:D4728 #14859 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => dependent/should_fail/T13895 * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 19:06:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 19:06:40 -0000 Subject: [GHC] #14890: Make Linux slow validate green In-Reply-To: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> References: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> Message-ID: <061.b29fcfcb773d5d5a8874b864db1bba91@haskell.org> #14890: Make Linux slow validate green -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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): D4546, D4636, Wiki Page: | D4712 -------------------------------------+------------------------------------- Comment (by osa1): What settings/command are you using to test this? I just validated on my x86_64 Linux laptop, and got 38 failures. Here's the summary file: {{{ Unexpected results from: TEST="CPUTime001 T10962 T12087 T12733 T13168 T13350 T14052 T14304 T14904b T14936 T2851 T3007 T4334 T7175 T7919 bkpcabal01 bkpcabal02 bkpcabal03 bkpcabal04 bkpcabal05 bkpcabal06 bkpcabal07 bug1465 cabal01 cabal03 cabal04 cabal05 cabal06 cabal08 cabal09 deriving-via-compile gadt11 haddock.Cabal haddock.compiler hpc_fork recomp007 safePkg01 space_leak_001 tcfail155 tcfail176" SUMMARY for test run started at Sun Jun 17 19:56:38 2018 +03 0:56:57 spent to go through 6441 total tests, which gave rise to 28995 test cases, of which 5703 were skipped 117 had missing libraries 22862 expected passes 262 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 38 unexpected failures 13 unexpected stat failures Unexpected failures: /tmp/ghctest-y99057f2/test spaces/./backpack/cabal/bkpcabal02/bkpcabal02.run bkpcabal02 [bad stderr] (normal) /tmp/ghctest-y99057f2/test spaces/./backpack/cabal/T14304/T14304.run T14304 [bad stderr] (normal) /tmp/ghctest-y99057f2/test spaces/./backpack/cabal/bkpcabal03/bkpcabal03.run bkpcabal03 [bad stderr] (normal) /tmp/ghctest-y99057f2/test spaces/./backpack/cabal/bkpcabal05/bkpcabal05.run bkpcabal05 [bad stderr] (normal) /tmp/ghctest-y99057f2/test spaces/./backpack/cabal/bkpcabal04/bkpcabal04.run bkpcabal04 [bad stderr] (normal) /tmp/ghctest-y99057f2/test spaces/./backpack/cabal/bkpcabal01/bkpcabal01.run bkpcabal01 [bad stderr] (normal) /tmp/ghctest-y99057f2/test spaces/./backpack/cabal/bkpcabal07/bkpcabal07.run bkpcabal07 [bad stderr] (normal) /tmp/ghctest-y99057f2/test spaces/./backpack/cabal/bkpcabal06/bkpcabal06.run bkpcabal06 [bad stderr] (normal) /tmp/ghctest-y99057f2/test spaces/./cabal/cabal04/cabal04.run cabal04 [bad stderr] (normal) /tmp/ghctest-y99057f2/test spaces/./cabal/T12733/T12733.run T12733 [bad stderr] (normal) /tmp/ghctest-y99057f2/test spaces/./cabal/cabal03/cabal03.run cabal03 [bad stderr] (normal) /tmp/ghctest-y99057f2/test spaces/./cabal/cabal01/cabal01.run cabal01 [bad stderr] (normal) /tmp/ghctest-y99057f2/test spaces/./cabal/cabal09/cabal09.run cabal09 [bad stderr] (normal) /tmp/ghctest-y99057f2/test spaces/./cabal/cabal08/cabal08.run cabal08 [bad stderr] (normal) /tmp/ghctest-y99057f2/test spaces/./cabal/cabal05/cabal05.run cabal05 [bad stderr] (normal) /tmp/ghctest-y99057f2/test spaces/./cabal/cabal06/cabal06.run cabal06 [bad stderr] (normal) /tmp/ghctest-y99057f2/test spaces/./deriving/should_compile/deriving- via-compile.run deriving-via-compile [exit code non-0] (normal) /tmp/ghctest-y99057f2/test spaces/./deriving/should_compile/deriving- via-compile.run deriving-via-compile [exit code non-0] (hpc) /tmp/ghctest-y99057f2/test spaces/./deriving/should_compile/deriving- via-compile.run deriving-via-compile [exit code non-0] (optasm) /tmp/ghctest-y99057f2/test spaces/./deriving/should_compile/deriving- via-compile.run deriving-via-compile [exit code non-0] (profasm) /tmp/ghctest-y99057f2/test spaces/./deriving/should_compile/deriving- via-compile.run deriving-via-compile [exit code non-0] (optllvm) /tmp/ghctest-y99057f2/test spaces/./deriving/should_fail/T2851.run T2851 [stderr mismatch] (normal) /tmp/ghctest-y99057f2/test spaces/./driver/T3007/T3007.run T3007 [bad stderr] (normal) /tmp/ghctest-y99057f2/test spaces/./driver/recomp007/recomp007.run recomp007 [bad stderr] (normal) /tmp/ghctest-y99057f2/test spaces/./gadt/gadt11.run gadt11 [stderr mismatch] (normal) /tmp/ghctest-y99057f2/test spaces/./gadt/T12087.run T12087 [stderr mismatch] (normal) /tmp/ghctest-y99057f2/test spaces/./numeric/should_run/T10962.run T10962 [bad stdout] (optllvm) /tmp/ghctest-y99057f2/test spaces/./patsyn/should_compile/T13350/T13350.run T13350 [bad stderr] (normal) /tmp/ghctest-y99057f2/test spaces/./safeHaskell/check/pkg01/safePkg01.run safePkg01 [bad stderr] (normal) /tmp/ghctest-y99057f2/test spaces/./typecheck/T13168/T13168.run T13168 [bad stderr] (normal) /tmp/ghctest-y99057f2/test spaces/./typecheck/bug1465/bug1465.run bug1465 [bad stderr] (normal) /tmp/ghctest-y99057f2/test spaces/./rts/T7919.run T7919 [bad exit code] (ghci) /tmp/ghctest-y99057f2/test spaces/./typecheck/should_fail/tcfail155.run tcfail155 [stderr mismatch] (normal) /tmp/ghctest-y99057f2/test spaces/./typecheck/should_fail/tcfail176.run tcfail176 [stderr mismatch] (normal) /tmp/ghctest-y99057f2/test spaces/./typecheck/should_fail/T7175.run T7175 [stderr mismatch] (normal) /tmp/ghctest-y99057f2/test spaces/./typecheck/should_fail/T14904b.run T14904b [stderr mismatch] (normal) /tmp/ghctest-y99057f2/test spaces/../../libraries/base/tests/CPUTime001.run CPUTime001 [bad stdout] (threaded2) /tmp/ghctest-y99057f2/test spaces/../../libraries/hpc/tests/fork/hpc_fork.run hpc_fork [bad heap profile] (profasm) Unexpected stat failures: /tmp/ghctest-y99057f2/test spaces/./perf/haddock/haddock.Cabal.run haddock.Cabal [stat not good enough] (normal) /tmp/ghctest-y99057f2/test spaces/./perf/haddock/haddock.compiler.run haddock.compiler [stat not good enough] (normal) /tmp/ghctest-y99057f2/test spaces/./perf/should_run/T14936.run T14936 [stat not good enough] (hpc) /tmp/ghctest-y99057f2/test spaces/./perf/should_run/T14052.run T14052 [stat not good enough] (ghci) /tmp/ghctest-y99057f2/test spaces/./perf/should_run/T14936.run T14936 [stat not good enough] (profasm) /tmp/ghctest-y99057f2/test spaces/./perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (hpc) /tmp/ghctest-y99057f2/test spaces/./perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (optasm) /tmp/ghctest-y99057f2/test spaces/./perf/space_leaks/T4334.run T4334 [stat not good enough] (threaded2) /tmp/ghctest-y99057f2/test spaces/./perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (dyn) /tmp/ghctest-y99057f2/test spaces/./perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (optllvm) /tmp/ghctest-y99057f2/test spaces/./perf/should_run/T14936.run T14936 [stat not good enough] (threaded1) /tmp/ghctest-y99057f2/test spaces/./perf/should_run/T14936.run T14936 [stat not good enough] (threaded2) /tmp/ghctest-y99057f2/test spaces/./perf/should_run/T14936.run T14936 [stat not good enough] (profthreaded) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 19:23:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 19:23:51 -0000 Subject: [GHC] #15283: Locale issue in the testsuite Message-ID: <045.dffad18a78b227771753ebab7a4c89b6@haskell.org> #15283: Locale issue in the testsuite -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Test Suite | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With a French locale (LANG=fr_FR.utf-8), `make TEST=T14999` fails with: {{{#!patch End of assembler dump. -Contents of the .debug_frame section: +Contenu de la section .debug_frame : 00000000 0000000000000014 ffffffff CIE "" cf=1 df=-8 ra=16 LOC CFA rbp rsp ra }}} But it passes with `LANG=C make TEST=T14999`. Should we enforce the locale for the whole testsuite or only for this test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 19:34:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 19:34:55 -0000 Subject: [GHC] #14529: Refactor ConDecl In-Reply-To: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> References: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> Message-ID: <061.6b5260bd1b2db6dfea387bb32e9a7a32@haskell.org> #14529: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.6.1 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 19:38:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 19:38:16 -0000 Subject: [GHC] #15095: pretty-show's literate haskell Setup.lhs failed on 32-bit windows In-Reply-To: <047.ddb6b51a929af36b051e0a4d3e1515c5@haskell.org> References: <047.ddb6b51a929af36b051e0a4d3e1515c5@haskell.org> Message-ID: <062.9a8e66f2a3f181e1579904cc4b467567@haskell.org> #15095: pretty-show's literate haskell Setup.lhs failed on 32-bit windows -------------------------------------+------------------------------------- Reporter: simonmic | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: #15154 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: infoneeded => closed * resolution: => duplicate * related: => #15154 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 19:40:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 19:40:51 -0000 Subject: [GHC] #15284: Can't parse ''(*) in GHC HEAD Message-ID: <050.03b110b67b5942be75741107963042b4@haskell.org> #15284: Can't parse ''(*) in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (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: -------------------------------------+------------------------------------- I can't build the `reflection` library on GHC HEAD since the `''(*)` Template Haskell name no longer parses. Here is a smaller example which compares GHC 8.4.3 (what should happens) with HEAD (which fails): {{{ $ /opt/ghc/8.4.3/bin/ghci -XTemplateHaskell GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> import GHC.TypeNats λ> ''(*) GHC.TypeNats.* }}} {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive -XTemplateHaskell GHCi, version 8.5.20180617: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> import GHC.TypeNats λ> ''(*) :2:4: error: parse error on input ‘*’ }}} int-index, I believe this was caused by your commit d650729f9a0f3b6aa5e6ef2d5fba337f6f70fa60 (`Embrace -XTypeInType, add -XStarIsType`). Do you know what is going on here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 19:46:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 19:46:38 -0000 Subject: [GHC] #15284: Can't parse ''(*) in GHC HEAD In-Reply-To: <050.03b110b67b5942be75741107963042b4@haskell.org> References: <050.03b110b67b5942be75741107963042b4@haskell.org> Message-ID: <065.952878388c21464d74a87917d98707da@haskell.org> #15284: Can't parse ''(*) in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (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 RyanGlScott): * version: 8.4.3 => 8.5 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 19:52:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 19:52:00 -0000 Subject: [GHC] #15284: Can't parse ''(*) in GHC HEAD In-Reply-To: <050.03b110b67b5942be75741107963042b4@haskell.org> References: <050.03b110b67b5942be75741107963042b4@haskell.org> Message-ID: <065.295af1afc89df1a136b7b79d23d5214b@haskell.org> #15284: Can't parse ''(*) in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (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 goldfire): Do you have `-XTypeOperators` on? It looks like you don't, but I'd expect you to need that extension for this to work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 19:54:59 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 19:54:59 -0000 Subject: [GHC] #15284: Can't parse ''(*) in GHC HEAD In-Reply-To: <050.03b110b67b5942be75741107963042b4@haskell.org> References: <050.03b110b67b5942be75741107963042b4@haskell.org> Message-ID: <065.ee959555aa2490ecc78f80b6d09bdd9f@haskell.org> #15284: Can't parse ''(*) in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (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 RyanGlScott): True, enabling `TypeOperators` (or more specifically, `NoStarIsType`, which `TypeOperators` implies) works around the issue. But why is that extension required for this to work? Note that I'm not using `*` as a synonym for `Type` here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 20:04:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 20:04:09 -0000 Subject: [GHC] #15284: Can't parse ''(*) in GHC HEAD In-Reply-To: <050.03b110b67b5942be75741107963042b4@haskell.org> References: <050.03b110b67b5942be75741107963042b4@haskell.org> Message-ID: <065.a0f7ea60624dd414817e9decd0fa0406@haskell.org> #15284: Can't parse ''(*) in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (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 goldfire): If that was ever accepted without `-XTypeOperators`, regardless of `-XStarIsType`, it's a bug. After all, you are quoting a type operator. Note, however, that `-XStarIsType` is on by default, and therefore `*` is not considered an infix operator in types (by default). So it's as if you wrote `''(Type)`, which indeed is an error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 20:05:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 20:05:19 -0000 Subject: [GHC] #15284: Can't parse ''(*) in GHC HEAD In-Reply-To: <050.03b110b67b5942be75741107963042b4@haskell.org> References: <050.03b110b67b5942be75741107963042b4@haskell.org> Message-ID: <065.22f46e1f4e6064c00f9fb3fe01acf506@haskell.org> #15284: Can't parse ''(*) in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (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 int-index): That is because with `-XStarIsType`, `*` is treated as an alphanumeric identifier. You wouldn't expect something like this to work? {{{ $ ghci -XTemplateHaskell GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Prelude> ''(Maybe) }}} What you write instead is: {{{ Prelude> ''Maybe GHC.Base.Maybe }}} Treating it as an alphanumeric identifier is the correct thing to do, for instance it allows the following declaration which wasn't possible before (without parentheses): {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 8.5.20180616: http://www.haskell.org/ghc/ :? for help Prelude> data T = MkT * * }}} Now, you might argue that in this case it should be accepted without parentheses, `''*`, but it's not: {{{ Prelude> ''* :4:1: error: Parser error on `''` Character literals may not be empty Or perhaps you intended to use quotation syntax of TemplateHaskell, but the type variable or constructor is missing }}} This one does look like a bug to me. What I would expect instead is: {{{ Prelude Data.Kind> ''Type GHC.Types.Type }}} I will fix if you agree that it's the way forward. In any case, you can workaround by full qualification: {{{ Prelude GHC.TypeNats> ''(GHC.TypeNats.*) GHC.TypeNats.* }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 21:04:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 21:04:18 -0000 Subject: [GHC] #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented In-Reply-To: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> References: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> Message-ID: <061.7dba39d29144616895394b7b11f8a5f8@haskell.org> #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Azel Type: feature request | Status: merge Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.2 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:D4736 Wiki Page: | -------------------------------------+------------------------------------- Old description: > As beginning Haskellers regularly ask about these laws and instances I > think it would be good to have them documented where they are defined. > > === Documented so far: > > (in 793902e6891c30150fd3ac1e0e471269a4766780) > > ==== Classes > > * `Eq` > * `Floating` > * `Fractional` > * `Integral` > * `Num` > * `Ord` > > ==== Non-abiding instances > > * `CDouble` (shares `Double`'s deficiencies) > * `CFloat` (shares `Float`'s deficiencies) > * `Complex a` (inherits deficiencies) > * `Double`: `Eq`, `Ord`, `Fractional`, `Num` > * `Float`: `Eq`, `Ord`, `Fractional`, `Num` > * `Ratio a` (inherits deficiencies) > * `Natural`: `Num` > > === TODO > > (This is not an exhaustive list, please add more) > > * `RealFrac` > * the Arrow classes > * `Word` & co New description: As beginning Haskellers regularly ask about these laws and instances I think it would be good to have them documented where they are defined. === Documented so far: (in 793902e6891c30150fd3ac1e0e471269a4766780) ==== Classes * `Eq` * `Floating` * `Fractional` * `Integral` * `Num` * `Ord` ==== Non-abiding instances * `CDouble` (shares `Double`'s deficiencies) * `CFloat` (shares `Float`'s deficiencies) * `Complex a` (inherits deficiencies) * `Double`: `Eq`, `Ord`, `Fractional`, `Num` * `Float`: `Eq`, `Ord`, `Fractional`, `Num` * `Ratio a` (inherits deficiencies) * `Natural`: `Num` === TODO (This is not an exhaustive list, please add more) * the Arrow classes * Document non-abiding instances for the types from `Data.Word` and `Data.Int`. -- Comment (by sjakobi): > What structure would RealFrac represent though? Not sure if there's any fitting structure, but I guess you could say that `RealFrac`'s are already documented on the methods. I'm removing it from the TODO list. > And do all instances of Monad, Functor and Applicative in base respect the relevant laws? I think this is question for a different ticket. I'd like to keep this ticket about classes whose laws haven't been documented so far. > * the Arrow classes What about them? Their laws seem to be well documented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 21:45:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 21:45:18 -0000 Subject: [GHC] #15284: Can't parse ''(*) in GHC HEAD In-Reply-To: <050.03b110b67b5942be75741107963042b4@haskell.org> References: <050.03b110b67b5942be75741107963042b4@haskell.org> Message-ID: <065.b110eb0e45c9c27bac23817a7a68b8d3@haskell.org> #15284: Can't parse ''(*) in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Parser) | 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 int-index): * status: new => closed * resolution: => invalid Comment: Now that I thought a bit more about it, the current error is the correct behavior: {{{ Prelude> ''* :4:1: error: Parser error on `''` Character literals may not be empty Or perhaps you intended to use quotation syntax of TemplateHaskell, but the type variable or constructor is missing }}} After all, `*` is not a name, it is built-in syntax. There's no corresponding name. If we simply treated it as `GHC.Types.Type` here, then we couldn't distinguish between `''Type` and `''*`, meaning we'd lose the parse/pretty-print roundtrip property. Thus I'm closing as "invalid". Reopen if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 17 22:17:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Jun 2018 22:17:23 -0000 Subject: [GHC] #15284: Can't parse ''(*) in GHC HEAD In-Reply-To: <050.03b110b67b5942be75741107963042b4@haskell.org> References: <050.03b110b67b5942be75741107963042b4@haskell.org> Message-ID: <065.51c37e8d93ad7ce29235e875c3805c1e@haskell.org> #15284: Can't parse ''(*) in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Parser) | 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 goldfire): This is tough. I guess `''*` (with `-XStarIsType`) is a bit like `''(=>)`. There really is no `*` -- there is now only `Type`. `*` is merely a syntactic gubbin that means `Type`. At first, this was an implementation decision that we thought was internal, but it seems that this decision is leaking via TH. That said, I'm OK with this behavior, but I could convinced if others thought this was poor form. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 04:51:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 04:51:33 -0000 Subject: [GHC] #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented In-Reply-To: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> References: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> Message-ID: <061.cd9fd08ae72a228fe94256e19e80c2cd@haskell.org> #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Azel Type: feature request | Status: merge Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.2 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:D4736 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Azel): I guess that's a fair point about `Monad` & co. And about the Arrow classes, they are but only by reference to an external paper. I guess that just means we need to make sure the links to the papers stay live. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 05:03:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 05:03:26 -0000 Subject: [GHC] #13165: Speed up the RTS hash table In-Reply-To: <047.5597063b110123c6100b4b707918365d@haskell.org> References: <047.5597063b110123c6100b4b707918365d@haskell.org> Message-ID: <062.de3488aa814b51e2fe5b78c0cb6a60b9@haskell.org> #13165: Speed up the RTS hash table -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.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 Crazycolorz5): I'd be interested in helping in resolving this ticket. I'm just a bit unclear as to what needs to be altered / what it's used for. I see the previous changes improve string hashing, but word hashing seems fairly swift (no library calls, just bit-level manipulations) as-is? Are there specific examples that may illustrate the suboptimal performance? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 06:20:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 06:20:05 -0000 Subject: [GHC] #15103: Speed optimizations for elimCommonBlocks In-Reply-To: <047.9c0ab9c0febb7c3619c049fda5d8f884@haskell.org> References: <047.9c0ab9c0febb7c3619c049fda5d8f884@haskell.org> Message-ID: <062.3ad864553ab5e05fbfff694a614784bf@haskell.org> #15103: Speed optimizations for elimCommonBlocks -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4597 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * status: patch => closed * resolution: => fixed Comment: This has been merged -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 06:34:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 06:34:35 -0000 Subject: [GHC] #15279: CPP #includes may result in nonsensical SrcSpans In-Reply-To: <045.4d706fecf4a6cf42667f6871be2d3572@haskell.org> References: <045.4d706fecf4a6cf42667f6871be2d3572@haskell.org> Message-ID: <060.6251c67a0b28e636c0a84555ae8273b9@haskell.org> #15279: CPP #includes may result in nonsensical SrcSpans -------------------------------------+------------------------------------- Reporter: wz1000 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: cpp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #14113 | Differential Rev(s): Phab:D4866 Wiki Page: | -------------------------------------+------------------------------------- Changes (by wz1000): * differential: => Phab:D4866 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 07:23:44 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 07:23:44 -0000 Subject: [GHC] #9106: GHC Panic related to functional dependencies - kindFunResult In-Reply-To: <044.0aafcc9fc1a20555c529d9fed2d8ec4a@haskell.org> References: <044.0aafcc9fc1a20555c529d9fed2d8ec4a@haskell.org> Message-ID: <059.953ee84c1dabbb167afcef6f0498e312@haskell.org> #9106: GHC Panic related to functional dependencies - kindFunResult ---------------------------------------+-------------------------------- Reporter: yuriy | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Test Case: polykinds/T9106 Blocked By: | Blocking: Related Tickets: | ---------------------------------------+-------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"d6216443c61cee94d8ffc31ca8510a534d9406b9/ghc" d6216443/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d6216443c61cee94d8ffc31ca8510a534d9406b9" Fix an infinite loop in niFixTCvSubst Trac #14164 made GHC loop, a pretty serious error. It turned out that Unify.niFixTCvSubst was looping forever, because we had a substitution like a :-> ....(b :: (c :: d)).... d :-> ... We correctly recognised that d was free in the range of the substitution, but then failed to apply it "deeeply enough" to the range of the substiuttion, so d was /still/ free in the range, and we kept on going. Trac #9106 was caused by a similar problem, but alas my fix to Trac #9106 was inadequate when the offending type variable is more deeply buried. Urk. This time I think I've fixed it! It's much more subtle than I though, and it took most of a long train journey to figure it out. I wrote a long note to explain: Note [Finding the substitution fixpoint] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 07:23:44 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 07:23:44 -0000 Subject: [GHC] #14164: GHC hangs on type family dependency In-Reply-To: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> References: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> Message-ID: <066.30f00158bbe25c0c1677b908d2011b06@haskell.org> #14164: GHC hangs on type family dependency -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | InjectiveFamilies 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:"d6216443c61cee94d8ffc31ca8510a534d9406b9/ghc" d6216443/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d6216443c61cee94d8ffc31ca8510a534d9406b9" Fix an infinite loop in niFixTCvSubst Trac #14164 made GHC loop, a pretty serious error. It turned out that Unify.niFixTCvSubst was looping forever, because we had a substitution like a :-> ....(b :: (c :: d)).... d :-> ... We correctly recognised that d was free in the range of the substitution, but then failed to apply it "deeeply enough" to the range of the substiuttion, so d was /still/ free in the range, and we kept on going. Trac #9106 was caused by a similar problem, but alas my fix to Trac #9106 was inadequate when the offending type variable is more deeply buried. Urk. This time I think I've fixed it! It's much more subtle than I though, and it took most of a long train journey to figure it out. I wrote a long note to explain: Note [Finding the substitution fixpoint] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 07:23:44 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 07:23:44 -0000 Subject: [GHC] #14904: Compiler panic (piResultTy) In-Reply-To: <047.da803a71fb92b792256c7a85e0a6a6bc@haskell.org> References: <047.da803a71fb92b792256c7a85e0a6a6bc@haskell.org> Message-ID: <062.5ee6ab83cc9decf8936596d5786ecde3@haskell.org> #14904: Compiler panic (piResultTy) -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T14904a, | typecheck/should_fail/T14904b Blocked By: | Blocking: Related Tickets: #14873 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"30b029bea9abe1f5f2855d9e7f0ae26a18cf049b/ghc" 30b029be/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="30b029bea9abe1f5f2855d9e7f0ae26a18cf049b" Fix typechecking of kind signatures When typechecking a type like Maybe (a :: ) with a kind signature, we were using tc_lhs_kind to typecheck the signature. But that's utterly wrong; we need the signature to be fully solid (non unresolved equalities) before using it. In the case of Trac #14904 we went on to instantiate the kind signature, when it still had embedded unsolved constraints. This tripped the level-checking assertion when unifying a variable. The fix looks pretty easy to me: just call tcLHsKind instead. I had to add KindSigCtxt to }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 07:30:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 07:30:27 -0000 Subject: [GHC] #13165: Speed up the RTS hash table In-Reply-To: <047.5597063b110123c6100b4b707918365d@haskell.org> References: <047.5597063b110123c6100b4b707918365d@haskell.org> Message-ID: <062.c1de2a642308543e4ebecb26cd6f4677@haskell.org> #13165: Speed up the RTS hash table -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.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 simonmar): @Crazycolorz5 for a benchmark, try compacting a large data structure with `Data.Compact.compactWithSharing`. A good way to get some sample data is to take a large JSON and decode it using Aeson. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 07:38:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 07:38:45 -0000 Subject: [GHC] #15280: StgCmmEnv: variable not found In-Reply-To: <046.bcf0d62450445af435476edca8eeba79@haskell.org> References: <046.bcf0d62450445af435476edca8eeba79@haskell.org> Message-ID: <061.64a2b4ef2bde06190d5048214a42ee44@haskell.org> #15280: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: wanjach | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Linux | 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): You'll probably get more precise error info from `-dcore-lint` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 07:47:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 07:47:04 -0000 Subject: [GHC] #15269: Qualified Names in --show-iface output In-Reply-To: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> References: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> Message-ID: <061.2b51757554291b29defea45a36dc0115@haskell.org> #15269: Qualified Names in --show-iface output -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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:D4852 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I realized that I don't know the right terminology for names from the current module and names from other modules. Is there any? If not, are "local" and "non-local" names good words for this? A difficulty is that being "from the current module" is not a property of a `Name`; it's a property of the `Name` plus the module being compiled; see `nameIsLocalOrFrom`. See also `Var.hs`: {{{ Note [GlobalId/LocalId] ~~~~~~~~~~~~~~~~~~~~~~~ A GlobalId is * always a constant (top-level) * imported, or data constructor, or primop, or record selector * has a Unique that is globally unique across the whole GHC invocation (a single invocation may compile multiple modules) * never treated as a candidate by the free-variable finder; it's a constant! A LocalId is * bound within an expression (lambda, case, local let(rec)) * or defined at top level in the module being compiled * always treated as a candidate by the free-variable finder After CoreTidy, top-level LocalIds are turned into GlobalIds }}} So `isLocalId` will reply `True` to a name defined in the current module up to `CoreTidy`, but not after. And all the interface stuff is after. Because of this contextual complexity, I suggest you spell out what you mean when you say it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 07:58:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 07:58:39 -0000 Subject: [GHC] #12420: Users guide link for hsc2hs has bitrotten In-Reply-To: <045.2ba362e1b9578cb50ac2c29c5bb4b687@haskell.org> References: <045.2ba362e1b9578cb50ac2c29c5bb4b687@haskell.org> Message-ID: <060.817a3c96398496bfcbdcc7550a40161c@haskell.org> #12420: Users guide link for hsc2hs has bitrotten -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: hsc2hs | 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 RolandSenn): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 08:00:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 08:00:09 -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.087f975f34a46d9fab122f8ba41a2a32@haskell.org> #14005: Explore moving from pretty to prettyprinter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) 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): Phab:D3650 Wiki Page: | wiki:PrettyErrors | -------------------------------------+------------------------------------- Comment (by simonpj): Worth adding data? Just saying "perf is worse" doesn't tell us much. Indeed, standing back a bit, it's strange that pretty-printer perf has ''any'' impact on normal compilation. What do we pretty-print? Assembly code perhaps? That can't be hard! Perhaps we could * Improve perf (perhaps a lot) by using a no-op pretty printer for the fast path * And improve modularity by using an existing library for the slow path -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 08:15:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 08:15:51 -0000 Subject: [GHC] #15113: Do not make CAFs from literal strings In-Reply-To: <046.d042ad82da8658ea11bcd44bf2d86387@haskell.org> References: <046.d042ad82da8658ea11bcd44bf2d86387@haskell.org> Message-ID: <061.3d2c376d07e74e8f9eaf1b556603d6ed@haskell.org> #15113: Do not make CAFs from literal strings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4717 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I like the idea of trying this out. It might actually make programs allocate more (because we start using call-by-name), but it's usually very short-lived allocation. To judge the effect, you might want to add a way to show the total SRT table sizes (statically); and the number of SRT links traversed by the garbage collector (dynamically). Reducing these two is the main point, so we should measure them. For the latter, perhaps add to the `-ticky` stats? Variants to explore * Broaden scope: do this for non-top-level bindings as well as top-level ones. (The Phab patch has bug on this point; it does it only for the non-top-level ones!) * Broaden scope: do this for any function marked CONLIKE. Currently those functions (in `libraries/`) are {{{ ./ghc-prim/GHC/CString.hs:74:{-# NOINLINE CONLIKE unpackCString# #-} ./ghc-prim/GHC/CString.hs:124:{-# NOINLINE CONLIKE unpackCStringUtf8# #-} ./bytestring/Data/ByteString/Builder/Prim/Internal.hs:74:#define CONLIKE ./bytestring/Data/ByteString/Builder/Prim/Internal.hs:157:{-# INLINE CONLIKE size #-} ./bytestring/Data/ByteString/Builder/Prim/Internal.hs:161:{-# INLINE CONLIKE runF #-} ./bytestring/Data/ByteString/Builder/Prim/Internal.hs:166:{-# INLINE CONLIKE emptyF #-} ./bytestring/Data/ByteString/Builder/Prim/Internal.hs:171:{-# INLINE CONLIKE pairF #-} ./bytestring/Data/ByteString/Builder/Prim/Internal.hs:185:{-# INLINE CONLIKE contramapF #-} ./bytestring/Data/ByteString/Builder/Prim/Internal.hs:190:{-# INLINE CONLIKE toB #-} ./bytestring/Data/ByteString/Builder/Prim/Internal.hs:195:{-# INLINE CONLIKE liftFixedToBounded #-} ./bytestring/Data/ByteString/Builder/Prim/Internal.hs:199:{-# INLINE CONLIKE storableToF #-} ./bytestring/Data/ByteString/Builder/Prim/Internal.hs:204:{-# INLINE CONLIKE liftIOF #-} ./bytestring/Data/ByteString/Builder/Prim/Internal.hs:218:{-# INLINE CONLIKE sizeBound #-} ./bytestring/Data/ByteString/Builder/Prim/Internal.hs:225:{-# INLINE CONLIKE runB #-} ./bytestring/Data/ByteString/Builder/Prim/Internal.hs:238:{-# INLINE CONLIKE contramapB #-} ./bytestring/Data/ByteString/Builder/Prim/Internal.hs:243:{-# INLINE CONLIKE emptyB #-} ./bytestring/Data/ByteString/Builder/Prim/Internal.hs:248:{-# INLINE CONLIKE pairB #-} ./bytestring/Data/ByteString/Builder/Prim/Internal.hs:264:{-# INLINE CONLIKE eitherB #-} ./bytestring/Data/ByteString/Builder/Prim/Internal.hs:277:{-# INLINE CONLIKE condB #-} }}} I have no idea if this idea would be a good one for those functions in `bytestring`; maybe not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 08:16:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 08:16:51 -0000 Subject: [GHC] #15264: Warn about implicit kind variables with -Wcompat In-Reply-To: <048.2758c96021df3e03a2c44fb779b75b19@haskell.org> References: <048.2758c96021df3e03a2c44fb779b75b19@haskell.org> Message-ID: <063.8c68d1f0225858818b55c0df1a6d750a@haskell.org> #15264: Warn about implicit kind variables with -Wcompat -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | dependent/should_compile/T15264 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4834 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => dependent/should_compile/T15264 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 08:17:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 08:17:50 -0000 Subject: [GHC] #14487: Can't Hide Field When DuplicateRecordFields Is Enabled In-Reply-To: <052.55fcb5f24afe31abafd77e2adcf88ad5@haskell.org> References: <052.55fcb5f24afe31abafd77e2adcf88ad5@haskell.org> Message-ID: <067.1562bc9f5ba30792bbd88563fff0c083@haskell.org> #14487: Can't Hide Field When DuplicateRecordFields Is Enabled -------------------------------------+------------------------------------- Reporter: iansullivan88 | Owner: (none) Type: bug | Status: closed Priority: lowest | Milestone: 8.6.1 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: | DuplicateRecordFields ORF Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T14487, | 14487A, | overloadedrecflds/should_fail/DuplicateExports Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4805 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: rename/should_compile/T14487 => rename/should_compile/T14487, 14487A, overloadedrecflds/should_fail/DuplicateExports -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 08:19:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 08:19:43 -0000 Subject: [GHC] #14845: TypeInType, index GADT by constraint witness In-Reply-To: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> References: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> Message-ID: <066.e0ad525f8486fbb8fd1309299be6ad6d@haskell.org> #14845: TypeInType, index GADT by constraint witness -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_fail/T14845_fail1,T14845_fail2 Blocked By: | Blocking: Related Tickets: #13895, #15215, | Differential Rev(s): Phab:D4728 #15282 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: dependent/should_fail/T14845_fail1, dependent/should_fail/T14845_fail2 => dependent/should_fail/T14845_fail1,T14845_fail2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 08:31:16 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 08:31:16 -0000 Subject: [GHC] #14164: GHC hangs on type family dependency In-Reply-To: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> References: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> Message-ID: <066.86a38c5b2ef2d0c6f306425d62e57cb1@haskell.org> #14164: GHC hangs on type family dependency -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T14164 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => indexed-types/should_compile/T14164 Comment: Well that was harder than I thought. I've committed the change, but I'd welcome any review (eg Richard). It fixes an outright bug, so I suggest merging to 8.6 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 08:33:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 08:33:29 -0000 Subject: [GHC] #14904: Compiler panic (piResultTy) In-Reply-To: <047.da803a71fb92b792256c7a85e0a6a6bc@haskell.org> References: <047.da803a71fb92b792256c7a85e0a6a6bc@haskell.org> Message-ID: <062.05029c839a9e328e53ae94384ed021f0@haskell.org> #14904: Compiler panic (piResultTy) -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T14904a, | typecheck/should_fail/T14904b, | indexed-types/should_fail/T14904 Blocked By: | Blocking: Related Tickets: #14873 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: typecheck/should_fail/T14904a, typecheck/should_fail/T14904b => typecheck/should_fail/T14904a, typecheck/should_fail/T14904b, indexed- types/should_fail/T14904 Comment: I can't predict all the consequences of this bug, so even though it doesn't seem to cause problems in a non-DEBUG-enabled compiler, I suggest merging to 8.6. Again, Richard might you check my work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 08:40:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 08:40:09 -0000 Subject: [GHC] #10789: Notify user when a kind mismatch holds up a type family reduction In-Reply-To: <047.282dd8bb976bc76373d556a5e980ac6e@haskell.org> References: <047.282dd8bb976bc76373d556a5e980ac6e@haskell.org> Message-ID: <062.126f93ea68eedc0841817f8aa327a37b@haskell.org> #10789: Notify user when a kind mismatch holds up a type family reduction -------------------------------------+------------------------------------- Reporter: goldfire | Owner: v0d1ch Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomer, | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13192 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Sasa asks (on ghc-devs) With the help of @int_index I found the place in TcErrors.hs where the error printing occurs and I think the check that I need to add will look similar to this one https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcErrors.hs#L1935. So I guess that we need to check if one of the kinds of two types we are comparing defaults to * (or Type if you will) and then add new warning that will be more descriptive as to why the failure happened. Maybe there is a way to check if what we are comparing are actually type families so that would make the job easier I guess. Richard replies I don't think the problem is particular to `Type` or defaulting. Instead, the problem is when * one of the two mismatched types is a type family application * and the type family has equations that pattern-match on an invisible parameter, * and it's that invisible-parameter matching that's gone awry. Now that I think about it, detecting these particular conditions might be tricky: you might need to edit code in `FamInstEnv` that does type family equation lookup to return diagnostic information if a match fails. (I would look at `reduceTyFamApp_maybe`, and perhaps it can return something more interesting than Nothing in the failure case.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 08:56:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 08:56:53 -0000 Subject: [GHC] #14164: GHC hangs on type family dependency In-Reply-To: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> References: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> Message-ID: <066.15de65d5e8961aa4639ce52bd9b714b2@haskell.org> #14164: GHC hangs on type family dependency -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T14164 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): PS: Thank you Iceland Jack and Ryan for an excellent bug report. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 09:32:23 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 09:32:23 -0000 Subject: [GHC] #14025: Object file is put in wrong directory when any source has absolute path In-Reply-To: <046.48759c75ff80de33ebc22ad9a6eaaf3e@haskell.org> References: <046.48759c75ff80de33ebc22ad9a6eaaf3e@haskell.org> Message-ID: <061.6ba06d2e7febb80cae737aca13739bca@haskell.org> #14025: Object file is put in wrong directory when any source has absolute path -------------------------------------+------------------------------------- Reporter: literon | Owner: RolandSenn 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 RolandSenn): * owner: (none) => RolandSenn Comment: With 8.4.2 this error can be reproduced. I'll try to fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 11:09:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 11:09:08 -0000 Subject: [GHC] #2168: ghci should show haddock comments for identifier In-Reply-To: <049.47be5fa91ec9885f4a8847376f7f589a@haskell.org> References: <049.47be5fa91ec9885f4a8847376f7f589a@haskell.org> Message-ID: <064.e66119782112212ab0b33b76cdc7c0ed@haskell.org> #2168: ghci should show haddock comments for identifier -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 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 sjakobi): * status: new => closed * resolution: => fixed Comment: The `:doc` command introduced in 85309a3cda367425cca727dfa45e5e6c63b47391 is somewhat limited – it doesn't show docs for function arguments for example. But I to improve it further for GHC-8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 11:50:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 11:50:03 -0000 Subject: [GHC] #15225: `-fno-state-hack` produces incorrect results in nofib In-Reply-To: <047.20e2da7aa2a2e4221951af3d8807d250@haskell.org> References: <047.20e2da7aa2a2e4221951af3d8807d250@haskell.org> Message-ID: <062.14d2a7b9f54cdd65f2ef9e6f482e7882@haskell.org> #15225: `-fno-state-hack` produces incorrect results in nofib -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7411 | Differential Rev(s): Phab:D4868 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * differential: => Phab:D4868 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 13:08:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 13:08:02 -0000 Subject: [GHC] #15272: Handle implied flags more intuitively In-Reply-To: <047.07f59a904afd8a010ee2318a873a6b9c@haskell.org> References: <047.07f59a904afd8a010ee2318a873a6b9c@haskell.org> Message-ID: <062.cf93bf9d971dcf96b813e69dd8974411@haskell.org> #15272: Handle implied flags more intuitively -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #14963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 Comment: This won't happen for 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 13:09:23 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 13:09:23 -0000 Subject: [GHC] #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented In-Reply-To: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> References: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> Message-ID: <061.eb9225c49c2a49ba103ccb5d36295e6f@haskell.org> #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Azel Type: feature request | Status: merge Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.2 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:D4736 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sjakobi): Replying to [comment:17 Azel]: > I guess that's a fair point about `Monad` & co. And about the Arrow classes, they are but only by reference to external papers. I guess that just means we need to make sure the links to the papers stay live. Are we looking at the same docs? The haddocks for `Arrow`, `ArrowPlus`, `ArrowChoice` all have their laws spelled out right there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 13:48:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 13:48:50 -0000 Subject: [GHC] #15043: Expand type synonym In-Reply-To: <049.9abaaa942352e202b2dd29770eb6c2c3@haskell.org> References: <049.9abaaa942352e202b2dd29770eb6c2c3@haskell.org> Message-ID: <064.6c2a9bf8216762a853c3536817dea278@haskell.org> #15043: Expand type synonym -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.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 RyanGlScott): * status: new => infoneeded Comment: Domen, would a variant of `-fprint-expanded-synonyms` that expanded all type synonyms work for your use case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 14:00:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 14:00:06 -0000 Subject: [GHC] #15043: Expand type synonym In-Reply-To: <049.9abaaa942352e202b2dd29770eb6c2c3@haskell.org> References: <049.9abaaa942352e202b2dd29770eb6c2c3@haskell.org> Message-ID: <064.e57dd831c5c1620255da8cb36727be7e@haskell.org> #15043: Expand type synonym -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.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: | -------------------------------------+------------------------------------- Comment (by domenkozar): I'm not entirely sure as I don't have enough experience. I do think having a way to expand all type synonyms means to at least see what's going on, but I don't think it is the best solution (as per osa1 concern that errors will get verbose). Maybe worth a try and see how it behaves in servant - something that many haskell devs will face. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 14:01:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 14:01:51 -0000 Subject: [GHC] #15043: A more aggressive version of -fprint-expanded-synonyms that prints all type synonyms (was: Expand type synonym) In-Reply-To: <049.9abaaa942352e202b2dd29770eb6c2c3@haskell.org> References: <049.9abaaa942352e202b2dd29770eb6c2c3@haskell.org> Message-ID: <064.a8a1e6e5a167cd0df4d84f7f9ca08c22@haskell.org> #15043: A more aggressive version of -fprint-expanded-synonyms that prints all type synonyms -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.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 RyanGlScott): * status: infoneeded => new * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 14:06:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 14:06:24 -0000 Subject: [GHC] #15285: "strange closure type" in T7919 with the threaded2 way Message-ID: <048.67a85438785d72c47b85ee0ad004eab2@haskell.org> #15285: "strange closure type" in T7919 with the threaded2 way ----------------------------------------+---------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.5 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: T7919 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- Last night's `./validate --slow` run on Circle CI revealed the following failure: {{{ Wrong exit code for T7919(threaded2)(expected 0 , actual 134 ) Stderr ( T7919 ): T7919: internal error: evacuate: strange closure type 32554624 (GHC version 8.5.20180617 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted *** unexpected failure for T7919(threaded2) }}} The full log is available [https://circleci.com/api/v1.1/project/github/ghc/ghc/6205/output/107/0?file=true here]. Among other things, you can see that it indeed only fails in the threaded2 way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 14:41:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 14:41:26 -0000 Subject: [GHC] #15286: "Can't use Natural in base" when compiling GHC.Natural with -O0 Message-ID: <048.cfab6e6ea21d7113a33d736cfa0133f3@haskell.org> #15286: "Can't use Natural in base" when compiling GHC.Natural with -O0 -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.5 libraries/base | 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: -------------------------------------+------------------------------------- {{{ _build/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all- packages -no-user-package-db '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id base-4.12.0.0' '-package- id ghc-prim-0.5.3' '-package-id integer-simple-0.1.1.1' '-package-id rts-1.0' -i -i_build/stage1/libraries/base/build -i_build/stage1/libraries/base/build/autogen -ilibraries/base/. -Iincludes -I_build/generated -I_build/stage1/libraries/base/build -I_build/stage1/libraries/base/build/include -Ilibraries/base/include -I/home/travis/build/snowleopard/hadrian/ghc/_build/stage1/lib/x86_64 -linux-ghc-8.5.20180617/rts-1.0/include -I_build/generated -optc- I_build/generated -optP-include -optP_build/stage1/libraries/base/build/autogen/cabal_macros.h -optc- std=gnu99 -optc-fno-stack-protector -optP-std=gnu99 -odir _build/stage1/libraries/base/build -hidir _build/stage1/libraries/base/build -stubdir _build/stage1/libraries/base/build -Wnoncanonical-monad-instances -optc- Werror=unused-but-set-variable -optc-Wno-error=inline -c libraries/base/GHC/Num.hs -o _build/stage1/libraries/base/build/GHC/Num.o -O0 -H64m -this-unit-id base -Wcompat -Wnoncanonical-monad-instances -XHaskell2010 -ghcversion- file=/home/travis/build/snowleopard/hadrian/ghc/_build/generated/ghcversion.h -Wno-deprecated-flags -Wno-trustworthy-safe Exit code: 1 Stderr: ghc: panic! (the 'impossible' happened) (GHC version 8.5.20180617 for x86_64-unknown-linux): Can't use Natural in base }}} We noticed this in hadrian land (in [https://github.com/snowleopard/hadrian/issues/499 this PR] and [https://github.com/snowleopard/hadrian/issues/629]), and noticed that this happens: - with 8.4.2 as the boot compiler but not 8.2.2 - with integer-simple as the integer library - only with the quickest flavour (or more generally when we build GHC.Natural with -O0) Some optimisation seems critical to making any trace of `Natural` disappear, but this seems rather fragile. The code that throws the error got introduced in fe770c211631e7b4c9b0b1e88ef9b6046c6585ef. The full build log is available [https://travis- ci.org/snowleopard/hadrian/jobs/393259151#L4209 here], anchored to where the error appears. An example of hadrian command to reproduce the problem, assuming a configured build tree: `hadrian/build.sh --flavour=quickest --integer- simple -j4`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 14:52:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 14:52:52 -0000 Subject: [GHC] #15272: Handle implied flags more intuitively In-Reply-To: <047.07f59a904afd8a010ee2318a873a6b9c@haskell.org> References: <047.07f59a904afd8a010ee2318a873a6b9c@haskell.org> Message-ID: <062.1a22331e02bbcfe03ad43896dd841096@haskell.org> #15272: Handle implied flags more intuitively -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #14963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:1 nomeata]: > Hmm, would that still lead to the desired outcome if the user specifies `-fdefer-type-errors -fno-defer-type-holes`? > > Currently, I expect that after this, `defer-type-holes` is disabled. > > Under your scheme, it seems that `-fno-defered-type-holes` does not actually affect the list of ''explicit flags'' (because there is no `Opt_DeferTypeHoles` to undo), but then when we calculate the set of ''explicit flags'' `Opt_DeferTypeErrors` will imply `Opt_DeferTypeHoles`, and that flag will be enabled – against the user’s intention, I presume? Ah, you're right, that would still be a problem. Essentially though, asking for `-fdefer-type-errors -fno-defer-type-holes` is kind of an impossible request. Hmm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 15:11:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 15:11:24 -0000 Subject: [GHC] #15051: -split-objs generates excessively many files on Windows In-Reply-To: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> References: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> Message-ID: <060.303ebbb7a0cdcf3449f9af5cfd74ccb7@haskell.org> #15051: -split-objs generates excessively many files on Windows ---------------------------------+-------------------------------------- Reporter: kanetw | Owner: Phyx- Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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): * owner: (none) => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 15:11:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 15:11:46 -0000 Subject: [GHC] #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented In-Reply-To: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> References: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> Message-ID: <061.0148fd88e2d046dcced572f5393d84a9@haskell.org> #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Azel Type: feature request | Status: merge Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.2 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:D4736 Wiki Page: | -------------------------------------+------------------------------------- Old description: > As beginning Haskellers regularly ask about these laws and instances I > think it would be good to have them documented where they are defined. > > === Documented so far: > > (in 793902e6891c30150fd3ac1e0e471269a4766780) > > ==== Classes > > * `Eq` > * `Floating` > * `Fractional` > * `Integral` > * `Num` > * `Ord` > > ==== Non-abiding instances > > * `CDouble` (shares `Double`'s deficiencies) > * `CFloat` (shares `Float`'s deficiencies) > * `Complex a` (inherits deficiencies) > * `Double`: `Eq`, `Ord`, `Fractional`, `Num` > * `Float`: `Eq`, `Ord`, `Fractional`, `Num` > * `Ratio a` (inherits deficiencies) > * `Natural`: `Num` > > === TODO > > (This is not an exhaustive list, please add more) > > * the Arrow classes > * Document non-abiding instances for the types from `Data.Word` and > `Data.Int`. New description: As beginning Haskellers regularly ask about these laws and instances I think it would be good to have them documented where they are defined. === Documented so far: (in 793902e6891c30150fd3ac1e0e471269a4766780) ==== Classes * `Eq` * `Floating` * `Fractional` * `Integral` * `Num` * `Ord` ==== Non-abiding instances * `CDouble` (shares `Double`'s deficiencies) * `CFloat` (shares `Float`'s deficiencies) * `Complex a` (inherits deficiencies) * `Double`: `Eq`, `Ord`, `Fractional`, `Num` * `Float`: `Eq`, `Ord`, `Fractional`, `Num` * `Ratio a` (inherits deficiencies) * `Natural`: `Num` === TODO (This is not an exhaustive list, please add more) * Document non-abiding instances for the types from `Data.Word` and `Data.Int`. -- Comment (by Azel): Ah yes my bad: I was looking at the wrong version of base's documentation. I'll remove it from the TODO list. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 15:12:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 15:12:15 -0000 Subject: [GHC] #14529: Refactor ConDecl In-Reply-To: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> References: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> Message-ID: <061.f60ee41b2a9f86e6fa2b9445331dd7e9@haskell.org> #14529: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 15:19:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 15:19:42 -0000 Subject: [GHC] #14904: Compiler panic (piResultTy) In-Reply-To: <047.da803a71fb92b792256c7a85e0a6a6bc@haskell.org> References: <047.da803a71fb92b792256c7a85e0a6a6bc@haskell.org> Message-ID: <062.84acb6bfeaf91f7d3812214479593130@haskell.org> #14904: Compiler panic (piResultTy) -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T14904a, | typecheck/should_fail/T14904b, | indexed-types/should_fail/T14904 Blocked By: | Blocking: Related Tickets: #14873 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Checked. Looks good, except for the typo fix I pushed. Yes, this was an oversight. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 15:21:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 15:21:53 -0000 Subject: [GHC] #15274: Numerous validation failures when building GHC with LLVM In-Reply-To: <046.83a071bfa50c4ead83f977af9cb85f1c@haskell.org> References: <046.83a071bfa50c4ead83f977af9cb85f1c@haskell.org> Message-ID: <061.1b12a9c0cd947fc9db3c16c7e62296ff@haskell.org> #15274: Numerous validation failures when building GHC with LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (LLVM) | Version: 8.4.3 Resolution: | Keywords: ci-breakage 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: > The CircleCI x86_64/Linux LLVM way exhibits numerous testsuite failures: > {{{ > TEST="ClosedFam1TH T10508_api T10828 T10891 T11341 T11345 T11463 > T11721_TH T11797 T12403 T12478_1 T12646 T12962 T13642 T13887 T14060 T1835 > T2222 T2552 T2700 T3920 T4135 T4188 T5037 T5358 T5362 T5363 T5559 T680 > T7477 T8761 T8884 T8953 T9064 T9262 T9692 TH_PromotedList TH_RichKinds > TH_RichKinds2 TH_Roles3 TH_TyInstWhere2 TH_foreignCallingConventions > TH_reifyDecl1 TH_reifyDecl2 TH_reifyInstances TH_repGuard TH_repPrim > TH_repPrim2 TH_repUnboxedTuples posix002 prof-doc-fib prof-doc-last > profinline001 prog001 scc001 scc002 scc003 scc005" > }}} > > Unfortunately, most of these appear to be segmentation faults and > similar, suggesting miscompilation. New description: The CircleCI x86_64/Linux LLVM way exhibits numerous testsuite failures: {{{ Unexpected results from: TEST="CPUTime001 ClosedFam1TH T10828 T10891 T11341 T11345 T11463 T11721_TH T11797 T12403 T12646 T12962 T13642 T13887 T14060 T1835 T2222 T2552 T2700 T3920 T4135 T4188 T5037 T5358 T5362 T5363 T5559 T680 T7477 T8761 T8884 T8953 T9064 T9262 T9692 TH_PromotedList TH_RichKinds TH_RichKinds2 TH_Roles3 TH_TyInstWhere2 TH_foreignCallingConventions TH_reifyDecl1 TH_reifyDecl2 TH_reifyInstances TH_repE2 TH_repGuard TH_repPrim TH_repPrim2 TH_repUnboxedTuples posix002 prof-doc-fib prof-doc-last profinline001 scc001 scc002 scc003 scc005" SUMMARY for test run started at Mon Jun 18 08:57:25 2018 UTC 1:18:58 spent to go through 6443 total tests, which gave rise to 25148 test cases, of which 4810 were skipped 229 had missing libraries 19825 expected passes 227 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 57 unexpected failures 0 unexpected stat failures Unexpected failures: profiling/should_run/scc001.run scc001 [bad exit code] (ghci-ext-prof) profiling/should_run/scc002.run scc002 [bad exit code] (ghci-ext-prof) profiling/should_run/scc003.run scc003 [bad exit code] (ghci-ext-prof) profiling/should_run/scc005.run scc005 [bad exit code] (ghci-ext-prof) profiling/should_run/T680.run T680 [bad exit code] (ghci-ext-prof) profiling/should_run/T2552.run T2552 [bad exit code] (ghci-ext-prof) profiling/should_run/prof-doc-fib.run prof-doc-fib [bad exit code] (ghci-ext-prof) profiling/should_run/T5559.run T5559 [bad exit code] (ghci-ext-prof) profiling/should_run/prof-doc-last.run prof-doc-last [bad exit code] (ghci-ext-prof) profiling/should_run/profinline001.run profinline001 [bad exit code] (ghci-ext-prof) profiling/should_run/T5363.run T5363 [bad exit code] (ghci-ext-prof) profiling/should_run/T12962.run T12962 [bad exit code] (ghci-ext-prof) th/TH_repPrim.run TH_repPrim [exit code non-0] (ext-interp) th/TH_repPrim2.run TH_repPrim2 [exit code non-0] (ext-interp) th/TH_repUnboxedTuples.run TH_repUnboxedTuples [exit code non-0] (ext-interp) th/TH_repGuard.run TH_repGuard [exit code non-0] (ext-interp) th/TH_repE2.run TH_repE2 [exit code non-0] (ext-interp) th/TH_reifyDecl1.run TH_reifyDecl1 [exit code non-0] (ext-interp) th/TH_reifyDecl2.run TH_reifyDecl2 [exit code non-0] (ext-interp) th/TH_reifyInstances.run TH_reifyInstances [exit code non-0] (ext-interp) th/T2700.run T2700 [exit code non-0] (ext-interp) th/TH_foreignCallingConventions.run TH_foreignCallingConventions [exit code non-0] (ext-interp) th/T4188.run T4188 [exit code non-0] (ext-interp) th/T3920.run T3920 [exit code non-0] (ext-interp) th/T5037.run T5037 [exit code non-0] (ext-interp) th/T5362.run T5362 [exit code non-0] (ext-interp) th/T1835.run T1835 [exit code non-0] (ext-interp) th/T5358.run T5358 [stderr mismatch] (ext-interp) th/TH_PromotedList.run TH_PromotedList [exit code non-0] (ext-interp) th/TH_RichKinds.run TH_RichKinds [exit code non-0] (ext-interp) th/TH_RichKinds2.run TH_RichKinds2 [exit code non-0] (ext-interp) th/T4135.run T4135 [exit code non-0] (ext-interp) th/TH_TyInstWhere2.run TH_TyInstWhere2 [exit code non-0] (ext-interp) th/T2222.run T2222 [exit code non-0] (ext-interp) th/ClosedFam1TH.run ClosedFam1TH [exit code non-0] (ext-interp) th/TH_Roles3.run TH_Roles3 [exit code non-0] (ext-interp) th/T7477.run T7477 [exit code non-0] (ext-interp) th/T8884.run T8884 [exit code non-0] (ext-interp) th/T9262.run T9262 [exit code non-0] (ext-interp) th/T9692.run T9692 [exit code non-0] (ext-interp) th/T8953.run T8953 [exit code non-0] (ext-interp) th/T9064.run T9064 [exit code non-0] (ext-interp) th/T10828.run T10828 [exit code non-0] (ext-interp) th/T10891.run T10891 [exit code non-0] (ext-interp) th/T11341.run T11341 [exit code non-0] (ext-interp) th/T11345.run T11345 [exit code non-0] (ext-interp) th/T11721_TH.run T11721_TH [exit code non-0] (ext-interp) th/T11797.run T11797 [exit code non-0] (ext-interp) th/T11463.run T11463 [exit code non-0] (ext-interp) th/T8761.run T8761 [exit code non-0] (ext-interp) th/T12403.run T12403 [exit code non-0] (ext-interp) th/T12646.run T12646 [exit code non-0] (ext-interp) th/T13642.run T13642 [exit code non-0] (ext-interp) th/T13887.run T13887 [exit code non-0] (ext-interp) th/T14060.run T14060 [exit code non-0] (ext-interp) ../../libraries/base/tests/CPUTime001.run CPUTime001 [bad stdout] (threaded2) ../../libraries/unix/tests/libposix/posix002.run posix002 [bad exit code] (threaded2) }}} Unfortunately, most of these appear to be segmentation faults and similar, suggesting miscompilation. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 15:30:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 15:30:01 -0000 Subject: [GHC] #15286: "Can't use Natural in base" when compiling GHC.Natural with -O0 In-Reply-To: <048.cfab6e6ea21d7113a33d736cfa0133f3@haskell.org> References: <048.cfab6e6ea21d7113a33d736cfa0133f3@haskell.org> Message-ID: <063.1d10238ed49d3ded1a3d4b14e80f87ef@haskell.org> #15286: "Can't use Natural in base" when compiling GHC.Natural with -O0 -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.5 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: | -------------------------------------+------------------------------------- Comment (by sighingnow): If we build the `GHC.Natural` with `-O0 -fno-omit-interface-pragmas` and build `GHC.Num` with `-O0 -fno-ignore-interface-pragmas`, the panic disappears. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 15:30:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 15:30:38 -0000 Subject: [GHC] #15286: "Can't use Natural in base" when compiling GHC.Natural with -O0 In-Reply-To: <048.cfab6e6ea21d7113a33d736cfa0133f3@haskell.org> References: <048.cfab6e6ea21d7113a33d736cfa0133f3@haskell.org> Message-ID: <063.6fac2459b6d6b056bc3208ba7a9c197f@haskell.org> #15286: "Can't use Natural in base" when compiling GHC.Natural with -O0 -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.5 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: | -------------------------------------+------------------------------------- Comment (by sighingnow): These two flags are only enabled with `-O0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 15:32:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 15:32:41 -0000 Subject: [GHC] #14529: Refactor ConDecl In-Reply-To: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> References: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> Message-ID: <061.5d26c8de09af8634b849c2238eb3dc6d@haskell.org> #14529: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Great. But where is the patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 15:33:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 15:33:20 -0000 Subject: [GHC] #14978: GADTs don't seem to unpack properly In-Reply-To: <045.8a53d57116a1e8f00d002cf33ac61964@haskell.org> References: <045.8a53d57116a1e8f00d002cf33ac61964@haskell.org> Message-ID: <060.17d3d39da5ff4ea284d207296893d78e@haskell.org> #14978: GADTs don't seem to unpack properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T14978 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: It looks like this is resolved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 15:34:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 15:34:20 -0000 Subject: [GHC] #13279: Check known-key lists In-Reply-To: <045.27ffb78b0e00a0c6dcfe02a64352aaa4@haskell.org> References: <045.27ffb78b0e00a0c6dcfe02a64352aaa4@haskell.org> Message-ID: <060.baf5b2b6c2a742b2135fac5d5bd2fbd9@haskell.org> #13279: Check known-key lists -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: newcomer 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): * keywords: => newcomer * milestone: 8.6.1 => 8.8.1 Comment: This won't happen for 8.8 but it would be nice to quickly sort it out for 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 15:38:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 15:38:29 -0000 Subject: [GHC] #14529: Refactor ConDecl In-Reply-To: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> References: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> Message-ID: <061.c47d36f58bd0b1b2d9c40c2f3c8b750a@haskell.org> #14529: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 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:D4867 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D4867 Comment: Oops, updated the ticket -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 15:43:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 15:43:53 -0000 Subject: [GHC] #15286: "Can't use Natural in base" when compiling GHC.Natural with -O0 In-Reply-To: <048.cfab6e6ea21d7113a33d736cfa0133f3@haskell.org> References: <048.cfab6e6ea21d7113a33d736cfa0133f3@haskell.org> Message-ID: <063.eaa41cbd9001b7ce95fadebae95a43f8@haskell.org> #15286: "Can't use Natural in base" when compiling GHC.Natural with -O0 -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.5 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: | -------------------------------------+------------------------------------- Comment (by sighingnow): With `-O0`, if we remove the methods `+` and `-` from the `instance Num Natural` then everything works well. Link: https://git.haskell.org/ghc.git/blob/fe770c211631e7b4c9b0b1e88ef9b6046c6585ef:/libraries/base/GHC/Num.hs#l127 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 16:22:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 16:22:31 -0000 Subject: [GHC] #15272: Handle implied flags more intuitively In-Reply-To: <047.07f59a904afd8a010ee2318a873a6b9c@haskell.org> References: <047.07f59a904afd8a010ee2318a873a6b9c@haskell.org> Message-ID: <062.06a747b895143978008e073c11c659bb@haskell.org> #15272: Handle implied flags more intuitively -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #14963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): OK, simpler plan, as discussed in today's meeting: Just make disabling a flag also disable the implied flags. This can still lead to mildly surprising behavior, but it is consistent, easy to implement, and easy to document. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 16:23:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 16:23:06 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.5ee14b9043c95777906ff81ed97d5f6d@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): To do: - turn on core linter - see if it still crashes when compiling with the stage1 compiler - compile nofib with -fno-state-hack, but with the "clean" compiler (compiled with state hack) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 16:23:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 16:23:57 -0000 Subject: [GHC] #15286: "Can't use Natural in base" when compiling GHC.Natural with -O0 In-Reply-To: <048.cfab6e6ea21d7113a33d736cfa0133f3@haskell.org> References: <048.cfab6e6ea21d7113a33d736cfa0133f3@haskell.org> Message-ID: <063.d5ca039fb4d4a059729df7c03bf1c67a@haskell.org> #15286: "Can't use Natural in base" when compiling GHC.Natural with -O0 -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.5 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: | -------------------------------------+------------------------------------- Comment (by bgamari): That is quite helpful. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 16:51:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 16:51:07 -0000 Subject: [GHC] #15234: WARNING in hptSomeThingsBelowUs when using a source plugin In-Reply-To: <049.15722b69a2f4eb74d7898931a7d1b55a@haskell.org> References: <049.15722b69a2f4eb74d7898931a7d1b55a@haskell.org> Message-ID: <064.3cba0a8a9b8c13d0f1efe7b04b844a31@haskell.org> #15234: WARNING in hptSomeThingsBelowUs when using a source plugin -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | SourcePlugins, plugins 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): Can you provide a testcase? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 16:52:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 16:52:11 -0000 Subject: [GHC] #13280: Consider deriving more Foldable methods In-Reply-To: <045.4e89b22a152ae432b77c074f237899bb@haskell.org> References: <045.4e89b22a152ae432b77c074f237899bb@haskell.org> Message-ID: <060.af8c2d93408ec090b4730c7e36701ea3@haskell.org> #13280: Consider deriving more Foldable methods -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: deriving-perf 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): * milestone: 8.6.1 => 8.8.1 Comment: Is there anything else to be done here? Perhaps `length`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 16:52:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 16:52:33 -0000 Subject: [GHC] #13362: GHC first generation of GC to be as large as largest cache size by default In-Reply-To: <045.9df30bf1acd19df01317b133116e51f6@haskell.org> References: <045.9df30bf1acd19df01317b133116e51f6@haskell.org> Message-ID: <060.02c6f8c6df0ce9c36c153c465a64403b@haskell.org> #13362: GHC first generation of GC to be as large as largest cache size by default -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: numa cache gc | newcomers Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4679 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 16:54:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 16:54:02 -0000 Subject: [GHC] #13709: Drop GCC Driver In-Reply-To: <044.530378a7ad6f5c3b791a9c874c84177d@haskell.org> References: <044.530378a7ad6f5c3b791a9c874c84177d@haskell.org> Message-ID: <059.77c2dba106cf8aad683f9e1b1b47abfd@haskell.org> #13709: Drop GCC Driver ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: wontfix | 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 bgamari): * status: new => closed * resolution: => wontfix * milestone: 8.6.1 => Comment: The reverting commit is: {{{ commit 58c781da4861faab11e4c5804e07e6892908ef72 Author: Simon Peyton Jones Date: Thu Jun 29 15:34:39 2017 +0100 Revert "Remove the Windows GCC driver." This reverts commit d6cecde585b0980ed8e0050c5a1d315789fb6356. The patch broke Simon PJ's Windows build, becuase he didn't have (and should not need) a separate msys2 gcc. Following an exchange on the ghc-devs list, Tamar wrote Oops, sorry, didn’t notice it because both mine and harbormaster’s msys2 have separate GCCs installed as well. I don’t see an easy fix that would also work for end user Configure based cabal installs. So I think I’ll have to go back to the drawing board for this one. You can just leave it reverted. }}} It looks like we won't be acting on this ticket any further. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 16:54:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 16:54:24 -0000 Subject: [GHC] #13944: Introduce synchronized FFI In-Reply-To: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> References: <045.0f0f1cc788221d39db9f9d0e51b5232b@haskell.org> Message-ID: <060.0a96e0258e4a5b886021f911950ed686@haskell.org> #13944: Introduce synchronized FFI -------------------------------------+------------------------------------- Reporter: winter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.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: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 Comment: Won't happen for 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 16:54:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 16:54:41 -0000 Subject: [GHC] #14023: Split up glasgow_exts.rst In-Reply-To: <046.00c07fe5ce6492eaedacdeae3c6ea07a@haskell.org> References: <046.00c07fe5ce6492eaedacdeae3c6ea07a@haskell.org> Message-ID: <061.28b3afa8eeaaa4f0dba4f8f8b1921ade@haskell.org> #14023: Split up glasgow_exts.rst -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Documentation | 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 bgamari): * keywords: newcomers => newcomer * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 16:55:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 16:55:24 -0000 Subject: [GHC] #14283: Remove the special case for tagToEnum# in the code generator? In-Reply-To: <045.8ba2def23565b96372814e1341ba709b@haskell.org> References: <045.8ba2def23565b96372814e1341ba709b@haskell.org> Message-ID: <060.8b8966c57517feee327c9089d2fab405@haskell.org> #14283: Remove the special case for tagToEnum# in the code generator? -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: infoneeded Priority: normal | Milestone: 8.6.1 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: David, perhaps you could summarise what you meant here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 17:56:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 17:56: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.ba9239a6934f95ed56f539606312096e@haskell.org> #7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: abhir00p Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3557 | Differential Rev(s): Wiki Page: wiki:SIMD | -------------------------------------+------------------------------------- Comment (by abhir00p): Some work has been done to add the `VecFormat` although we have restructured the data representation and instead of creating a new `VecFormat` type added an additional constructor in the `Format` data type. The new representation is also likely to change depending on the use cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 18:15:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 18:15:42 -0000 Subject: [GHC] #15287: T11627[ab] fail on some Darwin environments Message-ID: <046.b4a6b2737b3c1fbfc1faf99f30e4d4f9@haskell.org> #15287: T11627[ab] fail on some Darwin environments -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 d6216443c61cee94d8ffc31ca8510a534d9406b9 I am seeing `T11627a` and `T11627b` fail in the `prof_hr` way on Darwin under CircleCI (but not Harbormaster!): {{{ Wrong exit code for T11627b(prof_hr)(expected 0 , actual 139 ) Stderr ( T11627b ): /bin/sh: line 1: 73247 Segmentation fault: 11 ./T11627b +RTS -hr -RTS +RTS -i0 -RTS *** unexpected failure for T11627b(prof_hr) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 18:30:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 18:30:35 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.4fda0abaa072da3d02ebbd59e1e934c0@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): the issue is when using GCC on OSX with the system assembler, "as", which is a wrapper around llvm's assembler. aka GCC for C code, llvm's AS(sembler) for assembling -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 18:40:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 18:40:31 -0000 Subject: [GHC] #10869: Option to dump preprocessed source In-Reply-To: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> References: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> Message-ID: <061.e19e3cccb5068e695b2a38c147504ca9@haskell.org> #10869: Option to dump preprocessed source -------------------------------------+------------------------------------- Reporter: phischu | Owner: RolandSenn Type: feature request | Status: patch Priority: low | Milestone: Component: Driver | Version: 7.10.2 Resolution: | Keywords: easy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D4861 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * differential: => Phab: D4861 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 18:40:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 18:40:36 -0000 Subject: [GHC] #15098: Missing instances for Down In-Reply-To: <045.d367dfe3c3f3b98fcc231593185ffd4d@haskell.org> References: <045.d367dfe3c3f3b98fcc231593185ffd4d@haskell.org> Message-ID: <060.d9c43b7149d8fccbd68fcd7ee64ed509@haskell.org> #15098: Missing instances for Down -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.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:D4870 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4870 Comment: I quickly tapped these out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 18:42:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 18:42:52 -0000 Subject: [GHC] #15056: Wrappers inlined too late In-Reply-To: <046.72ddd11c72df8f69c83b0458132d883b@haskell.org> References: <046.72ddd11c72df8f69c83b0458132d883b@haskell.org> Message-ID: <061.585fba334b2516d34b8ae2517109b0b5@haskell.org> #15056: Wrappers inlined too late -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.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): * milestone: 8.6.1 => 8.8.1 Comment: It looks like you intend to continue pondering the regressions, simonpj, so I'll leave this open. However, it's unlikely much else will happen for 8.6 so I'm bumping the milestone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 18:43:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 18:43:33 -0000 Subject: [GHC] #13362: GHC first generation of GC to be as large as largest cache size by default In-Reply-To: <045.9df30bf1acd19df01317b133116e51f6@haskell.org> References: <045.9df30bf1acd19df01317b133116e51f6@haskell.org> Message-ID: <060.0534e01c1d5d9156e29a7be3a8abfe62@haskell.org> #13362: GHC first generation of GC to be as large as largest cache size by default -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: numa cache gc | newcomers Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4679 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 Comment: We won't be doing this for 8.6. Bumping to 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 18:47:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 18:47:32 -0000 Subject: [GHC] #15126: Opportunity to compress common info table representation. In-Reply-To: <047.6c1989d395bea7068f3a9a80b2222326@haskell.org> References: <047.6c1989d395bea7068f3a9a80b2222326@haskell.org> Message-ID: <062.c4afa322b5022bdb2f89a5848bf0b1eb@haskell.org> #15126: Opportunity to compress common info table representation. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4632 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 19:47:28 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 19:47:28 -0000 Subject: [GHC] #15287: T11627[ab] fail on some Darwin environments In-Reply-To: <046.b4a6b2737b3c1fbfc1faf99f30e4d4f9@haskell.org> References: <046.b4a6b2737b3c1fbfc1faf99f30e4d4f9@haskell.org> Message-ID: <061.b115c9048eeb0286cd199f2d8710d129@haskell.org> #15287: T11627[ab] fail on some Darwin environments -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): {{{ $ lldb -- testsuite/tests/profiling/should_run/T11627a +RTS -hr (lldb) target create "testsuite/tests/profiling/should_run/T11627a" Current executable set to 'testsuite/tests/profiling/should_run/T11627a' (x86_64). (lldb) settings set -- target.run-args "+RTS" "-hr" (lldb) run Process 6687 launched: '/Users/distiller/project/testsuite/tests/profiling/should_run/T11627a' (x86_64) T11627a was compiled with optimization - stepping may behave oddly; variables may not be available. Process 6687 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xfffffffffffffff8) frame #0: 0x00000001000d538b T11627a`retainClosure(c0=, cp0=0x000000010012f550, r0=0x000000010012dab0) at RetainerProfile.c:1409 [opt] 1406 // if cp is not a retainer, r belongs to RSET(cp). 1407 // if cp is a retainer, r == cp. 1408 -> 1409 typeOfc = get_itbl(c)->type; 1410 1411 #if defined(DEBUG_RETAINER) 1412 switch (typeOfc) { Target 0: (T11627a) stopped. (lldb) print c (StgClosure *) $0 = 0x00007fff5fbff0b8 (lldb) x/x 0x00007fff5fbff0b8 0x7fff5fbff0b8: 0x00000000 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 20:28:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 20:28:42 -0000 Subject: [GHC] #15288: Figure out what to do about retainer profiling debugging code Message-ID: <046.635868eb934793530aa87e6e051acfdd@haskell.org> #15288: Figure out what to do about retainer profiling debugging code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- `rts/RetainerProfile.c` has a hope pile of code guarded by the unset-by- default `DEBUG_RETAINER` macro. I tried to resuscitate it while debugging #15287, but it seems like a bit of a lost cause. In particular, the `cost()` function which seems to be critical to the accounting done by in this code was removed in dbef766ce79e37a74468a07a93b15ba1f06fe8f8. While I can't tell for certain, it's possible that this "cost" notion coincides with the value currently computed by `closure_sizeW`. Regardless, we should either drop this code if it's beyond saving or fix it to do something useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 20:38:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 20:38:55 -0000 Subject: [GHC] #15287: T11627[ab] fail on some Darwin environments In-Reply-To: <046.b4a6b2737b3c1fbfc1faf99f30e4d4f9@haskell.org> References: <046.b4a6b2737b3c1fbfc1faf99f30e4d4f9@haskell.org> Message-ID: <061.44cdd883dc4be451ad5ff6bc662f0aaf@haskell.org> #15287: T11627[ab] fail on some Darwin environments -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): A backtrace from another run (which inexplicably has no debug symbols in `RetainerProfile.c`): {{{ (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xfffffffffffffff8) * frame #0: 0x00000001000d538b T11627a`retainClosure + 123 frame #1: 0x00000001000dcdef T11627a`markStableTables at Stable.c:474 [opt] frame #2: 0x00000001000dcdaf T11627a`markStableTables(evac=(T11627a`retainRoot), user=0x0000000000000000) at Stable.c:492 [opt] frame #3: 0x00000001000d5155 T11627a`retainerProfile + 277 frame #4: 0x00000001000d016b T11627a`heapCensus(t=) at ProfHeap.c:1174 [opt] frame #5: 0x00000001000ea029 T11627a`GarbageCollect(collect_gen=, do_heap_census=, gc_type=, cap=0x0000000100142500, idle_cap=0x0000000000000001) at GC.c:771 [opt] frame #6: 0x00000001000dc360 T11627a`scheduleDoGC(pcap=, task=, force_major=) at Schedule.c:1799 [opt] frame #7: 0x00000001000dc08e T11627a`scheduleWaitThread [inlined] schedule(initialCapability=, task=) at Schedule.c:545 [opt] frame #8: 0x00000001000db7eb T11627a`scheduleWaitThread(tso=, ret=, pcap=0x00007fff5fbff2f8) at Schedule.c:2533 [opt] frame #9: 0x00000001000d98ab T11627a`hs_main(argc=1, argv=0x00007fff5fbff458, main_closure=, rts_config=RtsConfig @ 0x00007fff5fbff320) at RtsMain.c:72 [opt] frame #10: 0x0000000100001b16 T11627a`main + 166 frame #11: 0x00007fff8e844235 libdyld.dylib`start + 1 frame #12: 0x00007fff8e844235 libdyld.dylib`start + 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 20:52:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 20:52:08 -0000 Subject: [GHC] #15287: T11627[ab] fail on some Darwin environments In-Reply-To: <046.b4a6b2737b3c1fbfc1faf99f30e4d4f9@haskell.org> References: <046.b4a6b2737b3c1fbfc1faf99f30e4d4f9@haskell.org> Message-ID: <061.c4c9ede41b9c36849057f48fca1acfbe@haskell.org> #15287: T11627[ab] fail on some Darwin environments -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): Another run, this this with `DEBUG_RETAINER` set: {{{ pop() to the previous stack. stackSize = 0 retainClosure() ends: oldStackTop = 0x200000, stackTop = 0x200000 retainClosure() called: c0 = 0x1345c0, cp0 = 0x1345c0, r0 = 0x13f7e0 push(): stackTop = 0x200000, currentStackBoundary = 0x200000 stackSize = 1 push(): stackTop = 0x1fffd8, currentStackBoundary = 0x200000 stackSize = 2 pop(): stackTop = 0x1fffb0, currentStackBoundary = 0x200000 popOff(): stackTop = 0x1fffb0, currentStackBoundary = 0x200000 stackSize = 1 popOff(): stackTop = 0x1fffd8, currentStackBoundary = 0x200000 pop() to the previous stack. stackSize = 0 retainClosure() ends: oldStackTop = 0x200000, stackTop = 0x200000 retainClosure() called: c0 = 0x133ee0, cp0 = 0x133ee0, r0 = 0x13f7e0 push(): stackTop = 0x200000, currentStackBoundary = 0x200000 stackSize = 1 push(): stackTop = 0x1fffd8, currentStackBoundary = 0x200000 stackSize = 2 pop(): stackTop = 0x1fffb0, currentStackBoundary = 0x200000 pop(): stackTop = 0x1fffb0, currentStackBoundary = 0x200000 popOff(): stackTop = 0x1fffb0, currentStackBoundary = 0x200000 stackSize = 1 popOff(): stackTop = 0x1fffd8, currentStackBoundary = 0x200000 pop() to the previous stack. stackSize = 0 retainClosure() ends: oldStackTop = 0x200000, stackTop = 0x200000 retainClosure() called: c0 = 0x134a80, cp0 = 0x134a80, r0 = 0x13f7e0 pop(): stackTop = 0x200000, currentStackBoundary = 0x200000 retainClosure() ends: oldStackTop = 0x200000, stackTop = 0x200000 retainClosure() called: c0 = 0x12f550, cp0 = 0x12f550, r0 = 0x12dab0 push(): stackTop = 0x200000, currentStackBoundary = 0x200000 T11627a was compiled with optimization - stepping may behave oddly; variables may not be available. Process 36053 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.3 frame #0: 0x00000001000d5cff T11627a`retainClosure [inlined] isRetainer(c=) at RetainerProfile.c:1057 [opt] 1054 case IND: 1055 case INVALID_OBJECT: 1056 default: -> 1057 barf("Invalid object in isRetainer(): %p, type=%d", c, get_itbl(c)->type); 1058 return false; 1059 } 1060 } Target 0: (T11627a) stopped. (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.3 * frame #0: 0x00000001000d5cff T11627a`retainClosure [inlined] isRetainer(c=) at RetainerProfile.c:1057 [opt] frame #1: 0x00000001000d5cff T11627a`retainClosure(c0=, cp0=0x000000010012f550, r0=0x000000010012dab0) at RetainerProfile.c:1517 [opt] frame #2: 0x00000042001fcec8 (lldb) }}} Given that the backtrace is truncated it looks rather like someone has smashed the C callstack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 20:52:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 20:52:51 -0000 Subject: [GHC] #15287: T11627[ab] fail on some Darwin environments In-Reply-To: <046.b4a6b2737b3c1fbfc1faf99f30e4d4f9@haskell.org> References: <046.b4a6b2737b3c1fbfc1faf99f30e4d4f9@haskell.org> Message-ID: <061.f031474a6463a894912d2643c62b859d@haskell.org> #15287: T11627[ab] fail on some Darwin environments -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14758 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #14758 Comment: I rather suspect that this is another manifestation of #14758. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 20:53:16 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 20:53:16 -0000 Subject: [GHC] #14758: Retainer profiler can overflow the C stack In-Reply-To: <046.e63d54b73cd1d189e95bd3a35572589a@haskell.org> References: <046.e63d54b73cd1d189e95bd3a35572589a@haskell.org> Message-ID: <061.82525dea220a7a97de95e3d4900f7e06@haskell.org> #14758: Retainer profiler can overflow the C stack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Profiling | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15287 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #15287 Comment: I suspect that #15287 is another manifestation of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 22:00:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 22:00:56 -0000 Subject: [GHC] #15289: isUnliftedType GHC panic on pattern with True :: Maybe Message-ID: <043.406dc7510cae6790ee47421c68dfc69f@haskell.org> #15289: isUnliftedType GHC panic on pattern with True :: Maybe -------------------------------------+------------------------------------- Reporter: Remi | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: aarch64 | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ScopedTypeVariables #-} module Oops where pattern What = True :: Maybe }}} Fails on 8.4.3 with: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): isUnliftedType (Maybe |> {co_a1Dg3}) :: TYPE t_a1Dg9[tau:1] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1939:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I'm currently cloning from git, and will try to get around to check it with HEAD over the next days. BTW, it's not a show-stopper for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 22:05:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 22:05:06 -0000 Subject: [GHC] #15289: isUnliftedType GHC panic on pattern with True :: Maybe In-Reply-To: <043.406dc7510cae6790ee47421c68dfc69f@haskell.org> References: <043.406dc7510cae6790ee47421c68dfc69f@haskell.org> Message-ID: <058.3d088ef8f71a9d4ec0a01ee3c8d92ec9@haskell.org> #15289: isUnliftedType GHC panic on pattern with True :: Maybe -------------------------------------+------------------------------------- Reporter: Remi | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 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 Remi): * architecture: aarch64 => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 22:30:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 22:30:34 -0000 Subject: [GHC] #15289: isUnliftedType GHC panic on pattern with True :: Maybe In-Reply-To: <043.406dc7510cae6790ee47421c68dfc69f@haskell.org> References: <043.406dc7510cae6790ee47421c68dfc69f@haskell.org> Message-ID: <058.bc320e93ebcfea8bacea7e4f1cd64baa@haskell.org> #15289: isUnliftedType GHC panic on pattern with True :: Maybe -------------------------------------+------------------------------------- Reporter: Remi | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: Resolution: | PatternSynonyms 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): * keywords: => PatternSynonyms Comment: This also panics on GHC HEAD: {{{ $ /opt/ghc/head/bin/ghc Bug2.hs [1 of 1] Compiling Oops ( Bug2.hs, Bug2.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.5.20180616 for x86_64-unknown-linux): isUnliftedType (Maybe |> {co_aWy}) :: TYPE t_aWE[tau:0] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1934:10 in ghc:Type }}} This appears to be a regression from GHC 8.2.2, in which the same program simply gives an error message: {{{ $ /opt/ghc/8.2.2/bin/ghc Bug2.hs [1 of 1] Compiling Oops ( Bug2.hs, Bug2.o ) Bug2.hs:5:16: error: • Couldn't match expected type ‘Maybe’ with actual type ‘Bool’ • In the pattern: True In the pattern: True :: Maybe In the declaration for pattern synonym ‘What’ | 5 | pattern What = True :: Maybe | ^^^^ Bug2.hs:5:16: error: • Couldn't match expected type ‘Maybe’ with actual type ‘Bool’ • In the expression: True In an equation for ‘What’: What = True | 5 | pattern What = True :: Maybe | ^^^^^^^^^^^^^ Bug2.hs:5:24: error: • Expecting one more argument to ‘Maybe’ Expected a type, but ‘Maybe’ has kind ‘* -> *’ • In the type ‘Maybe’ In a pattern type signature: Maybe In the pattern: True :: Maybe | 5 | pattern What = True :: Maybe | ^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 23:07:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 23:07:22 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.03700a9ee407cd9ca43caee380ab151d@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13122 Related Tickets: | Differential Rev(s): #8809,#10073,#10179,#12906,#13670 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, Richard has a student looking at error messages this summer; one of the later tasks on their list is the sort of rich error message AST described in comment:3. We discussed the design during my visit a few weeks ago and generally agree on this plan: * Decouple the choice of pretty-printer library (#14005) from the error message design as the former has proven to be rather tricky. Note that this might mean that we have to give up a little bit of the progress that we've made on unify our `pretty` fork with upstream, but IMHO the user- facing goal of improving error messages takes precedence to this internal engineering goal. * Don't introduce a type argument to the `SDoc` type; rather define it as it's defined today but against an annotated `Doc` type (e.g. using `pretty`'s annotated `Doc` instantiated at a concrete type of error message items: {{{#!hs type SDoc = DynFlags -> Doc GhcErrItem }}} * Start by defining only a small set of error message items. For instance, perhaps we start with only, {{{#!hs data GhcErrItem = SuggestLangExt [LangExt] -- ^ A suggestion to enable a language extension | AnIdent Id -- ^ An identifier | AType Type -- ^ A type }}} The point here is that the design of this sum should be very much driven by what down-stream consumers need. By starting small we avoid getting bogged down in these tricky design details. Anyways, I suspect that, if defined this narrowly, this project should be quite manageable and will allow us to finally make some progress on this goal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 23:07:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 23:07:34 -0000 Subject: [GHC] #15043: A more aggressive version of -fprint-expanded-synonyms that prints all type synonyms In-Reply-To: <049.9abaaa942352e202b2dd29770eb6c2c3@haskell.org> References: <049.9abaaa942352e202b2dd29770eb6c2c3@haskell.org> Message-ID: <064.e3610de3cfcfc43422cc864dea48374e@haskell.org> #15043: A more aggressive version of -fprint-expanded-synonyms that prints all type synonyms -------------------------------------+------------------------------------- Reporter: domenkozar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.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: | -------------------------------------+------------------------------------- Comment (by bgamari): As osa1 mentioned, it seems that the UI design here is quite thorny. Frankly, this is an area where I think more interactive errors (e.g. ticket:8809#comment: will help immensely and may be the only satisfactory solution (#8809). Richard has a student working on laying the groundwork for this over the summer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 18 23:44:10 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Jun 2018 23:44:10 -0000 Subject: [GHC] #15124: Improve block layout for the NCG In-Reply-To: <047.b2a760b384d29a2bc137285a934c2d79@haskell.org> References: <047.b2a760b384d29a2bc137285a934c2d79@haskell.org> Message-ID: <062.43e1b2678c13a17470d6dc1d5818515f@haskell.org> #15124: Improve block layout for the NCG -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (NCG) | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8082 #14672 | Differential Rev(s): Phab:D4726 Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): Replying to [comment:5 AndreasK]: > I've wrote up a patch implementing an experimental code layout algorithm, which hopefully is easy to adjust to take advantage of additional information about control flow. > > Code is at Phab:D4726. As it stands: > > * It works (only) on x64. > * Performance is around the same. (Better but within the margin of error). > * Compiler performance is slightly worse. > > There are a lot of knobs to tune this approach further but verifying any results is tedious so I stopped eventually. > > For now I hope to use this eventually as a substrate for the work on #14672. > > I've also created a wiki page here https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/CodeLayout with more details. I've came over a comment here: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/NCG#Redundantreconstructionofthecontrolflowgraph > The allocator goes to considerable computational expense to construct all the flow edges in the group of instructions it's allocating for, by using the insnFuture function in the Instr pseudo-abstract type. Since my patch already constructs and maintains a CFG maybe we can reuse this. Although currently it's on the basic block not instruction level and I haven't checked if the comment is still relevant either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 00:07:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 00:07:15 -0000 Subject: [GHC] #14023: Split up glasgow_exts.rst In-Reply-To: <046.00c07fe5ce6492eaedacdeae3c6ea07a@haskell.org> References: <046.00c07fe5ce6492eaedacdeae3c6ea07a@haskell.org> Message-ID: <061.d80a76a190aff6c845824cdec7106593@haskell.org> #14023: Split up glasgow_exts.rst -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Documentation | 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 AntC): I support splitting up the file: It is nerve-wracking to edit it for fear of mucking up a section you never intended to touch. Previewing it to see your edits takes a long wait for rendering. And it's too easy to mess up the formatting with result that the contents/index turns to custard. OTOH there are many cross-references amongst different subsections. Is `.rst` clever enought to stitch togethere the labels? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 00:17:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 00:17:23 -0000 Subject: [GHC] #15289: isUnliftedType GHC panic on pattern with True :: Maybe In-Reply-To: <043.406dc7510cae6790ee47421c68dfc69f@haskell.org> References: <043.406dc7510cae6790ee47421c68dfc69f@haskell.org> Message-ID: <058.5051e0bc186ae359b5535845b8cac57a@haskell.org> #15289: isUnliftedType GHC panic on pattern with True :: Maybe -------------------------------------+------------------------------------- Reporter: Remi | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: Resolution: | PatternSynonyms 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: simonpj (added) Comment: This was introduced in commit 594879dcb2fd5421d5f6ce5341442de32a4aac0a (`Fix floating of equalities`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 01:09:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 01:09:01 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.7b97a65ed1beee9f75ee2b9b1de090b1@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13122 Related Tickets: | Differential Rev(s): #8809,#10073,#10179,#12906,#13670 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Thanks for writing this up, Ben! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 01:24:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 01:24:53 -0000 Subject: [GHC] #14164: GHC hangs on type family dependency In-Reply-To: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> References: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> Message-ID: <066.a4bdcd0f6f3b0811a215f45f0e769bb2@haskell.org> #14164: GHC hangs on type family dependency -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T14164 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I've commented on the [https://phabricator.haskell.org/rGHCd6216443c61cee94d8ffc31ca8510a534d9406b9 commit]. I think the fix is right, but I'm worried about other related scenarios. I suppose I'll repeat my worry here: How do we know when performing a subst over an open type that we're not forgetting to subst in kinds? The in-scope set of a subst is always closed over kinds. But we need the (in-scope set) - (the subst domain), using set subtraction, to ''also'' be closed over kinds. Otherwise, we're substing a kind variable without substing the type variable, leading to problems like the ones here. So I propose adding this to the substitution invariants and checking it appropriately. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 03:09:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 03:09:41 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails In-Reply-To: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> References: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> Message-ID: <065.dddcde0061af0e10c431646cc6a1d1a4@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, CUSKs 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): Some thoughts have been written up [https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference#SimplifyinggetInitialKinds15142 here]. But there's no real progress on what the right answer is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 03:21:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 03:21:26 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" Message-ID: <047.0224facf758b89c9000b13f48465854c@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I wanted to see if we're ready to put `join` into `Monad`. So I typed this in: {{{#!hs {-# LANGUAGE QuantifiedConstraints, StandaloneDeriving, GeneralizedNewtypeDeriving #-} module Bug where import Prelude hiding ( Monad(..) ) import Data.Coerce ( Coercible ) class Monad m where (>>=) :: m a -> (a -> m b) -> m b join :: m (m a) -> m a newtype StateT s m a = StateT { runStateT :: s -> m (s, a) } instance Monad m => Monad (StateT s m) where ma >>= fmb = StateT $ \s -> runStateT ma s >>= \(s1, a) -> runStateT (fmb a) s1 join ssa = StateT $ \s -> runStateT ssa s >>= \(s, sa) -> runStateT sa s newtype IntStateT m a = IntStateT { runIntStateT :: StateT Int m a } deriving instance (Monad m, forall p q. Coercible p q => Coercible (m p) (m q)) => Monad (IntStateT m) }}} This looks like it should be accepted. But I get {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180617 for x86_64-apple-darwin): addTcEvBind NoEvBindsVar [G] df_a67k = \ (@ p_a62C) (@ q_a62D) (v_B1 :: Coercible p_a62C q_a62D) -> coercible_sel @ * @ (m_a64Z[ssk:1] p_a62C) @ (m_a64Z[ssk:1] q_a62D) (df_a651 @ p_a62C @ q_a62D v_B1) a67c Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcRnMonad.hs:1404:5 in ghc:TcRnMonad }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 03:25:00 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 03:25:00 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.658d015227ef1acdaa03e86c577655a8@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints 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): Simpler test case: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving, StandaloneDeriving, QuantifiedConstraints #-} module Bug where import Data.Coerce class C m where join :: m (m a) -> m a newtype T m a = MkT (m a) deriving instance (C m, forall p q. Coercible p q => Coercible (m p) (m q)) => C (T m) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 03:26:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 03:26:39 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.0610adfd9d2e574eca5bdaa10dfaecb5@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Roles, Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T9123{,a} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: goldfire => (none) * status: closed => new * resolution: fixed => Comment: We cannot yet accept the program in the original post, due to (at least) #15290. I also think that, in the case of inferring the constraints in a `deriving` clause, we ''should'' sometimes infer a quantified constraint. I'd like to keep this ticket open until we can safely put `join` into `Monad`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 03:27:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 03:27:27 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.b2ced73975b8931aae685027c5674ab7@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints 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): This is blocking #9123. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 03:27:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 03:27:42 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.11bc268ce8760e94e2189d0fd47c15de@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9123 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * blocking: => 9123 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 05:50:00 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 05:50:00 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.3c89d51231952d3b519b4b1a356702c9@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13122 Related Tickets: | Differential Rev(s): #8809,#10073,#10179,#12906,#13670 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by gracjan): * cc: gracjan (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 06:57:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 06:57:35 -0000 Subject: [GHC] #14502: Build Alpine Linux binary distributions In-Reply-To: <046.7faa39537281abdbe7789c4ce9416be8@haskell.org> References: <046.7faa39537281abdbe7789c4ce9416be8@haskell.org> Message-ID: <061.465ab75aec33791bc988c4c756c87bee@haskell.org> #14502: Build Alpine Linux binary distributions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Continuous | Version: 8.2.1 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14057 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gidyn): Alpine users tend to be very space-conscience. Could we have a build with just the vanilla libraries, no profiling, shared or docs? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 06:57:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 06:57:57 -0000 Subject: [GHC] #14502: Build Alpine Linux binary distributions In-Reply-To: <046.7faa39537281abdbe7789c4ce9416be8@haskell.org> References: <046.7faa39537281abdbe7789c4ce9416be8@haskell.org> Message-ID: <061.8574b8d6d4995a1428143fb6b0a5cdff@haskell.org> #14502: Build Alpine Linux binary distributions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Continuous | Version: 8.2.1 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14057 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 07:58:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 07:58:37 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.d646ee6229f005b46be1a167dd510fcb@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Did 4 full runs of compiling GHC from scratch and then compiling and running nofib, with different configurations. Here's what happened. 1. "vanilla": compile everything normally (the `prof` build that comes with GHC). Everything works as expected. 2. "nsh": compile everything with `-fno-state-hack` (GHC itself, libraries, nofib). Everything works as expected. 3. "stage1": compile GHC normally, nofib with `-fno-state-hack`, but use stage1 compiler instead of stage2. Everything works as expected. 4. "nofib-nsh": compile GHC normally, nofib with `-fno-state-hack`. GHC segfaults while compiling `Main.hs` from the bernouilli program (which simply happens to be the first one it encounters). Despite passing `-dcore-lint`, I get no linter output. Here's the log: {{{ ------------------------------------------------------------------------ == Recursively making `all' in runstdtest nofib-analyse imaginary spectral real shootout ... PWD = /home/tobias/well-typed/devel/ghc/HEAD/nofib ------------------------------------------------------------------------ ------------------------------------------------------------------------ == make all ; in /home/tobias/well-typed/devel/ghc/HEAD/nofib/runstdtest ------------------------------------------------------------------------ rm -f -f runstdtest echo '#!/usr/bin/perl' >> runstdtest echo '$RM = "rm -f";' >> runstdtest echo '$CONTEXT_DIFF = "diff -U 1";' >> runstdtest cat runstdtest.prl >> runstdtest chmod +x runstdtest Finished making all in runstdtest: 0 ------------------------------------------------------------------------ == make all ; in /home/tobias/well-typed/devel/ghc/HEAD/nofib/nofib-analyse ------------------------------------------------------------------------ make[1]: Nothing to be done for 'all'. Finished making all in nofib-analyse: 0 ------------------------------------------------------------------------ == make all ; in /home/tobias/well-typed/devel/ghc/HEAD/nofib/imaginary ------------------------------------------------------------------------ ------------------------------------------------------------------------ == Recursively making `all' in bernouilli digits-of-e1 digits-of-e2 exp3_8 gen_regexps integrate paraffins primes queens rfib tak wheel-sieve1 wheel- sieve2 x2n1 kahan ... PWD = /home/tobias/well-typed/devel/ghc/HEAD/nofib/imaginary ------------------------------------------------------------------------ ------------------------------------------------------------------------ == make all --no-print-directory; in /home/tobias/well-typed/devel/ghc/HEAD/nofib/imaginary/bernouilli ------------------------------------------------------------------------ HC = /home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2 HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fno-state-hack -O2 -dcore-lint -rtsopts RUNTEST_OPTS = -ghc-timing ==nofib== bernouilli: time to compile Main follows... /home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2 -O2 -Rghc- timing -H32m -hisuf hi -fno-state-hack -O2 -dcore-lint -rtsopts -c Main.hs -o Main.o ../../mk/suffix.mk:23: recipe for target 'Main.o' failed make[2]: *** [Main.o] Segmentation fault (core dumped) Failed making all in bernouilli: 1 ../mk/ghc-recurse.mk:65: recipe for target 'all' failed make[1]: *** [all] Error 1 Failed making all in imaginary: 1 mk/ghc-recurse.mk:65: recipe for target 'all' failed make: *** [all] Error 1 }}} Unfortunately I hadn't done a run with GHC stage1 compiled with `-fno- state-hack`; I'll do that next. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 08:07:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 08:07:28 -0000 Subject: [GHC] #15291: Incorrect SCC name parsing according to user manual Message-ID: <043.d376bb82d74d734daa2fcf489eac39fe@haskell.org> #15291: Incorrect SCC name parsing according to user manual -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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 user manual says this about SCC names: > The syntax of a cost centre annotation for expressions is > > {-# SCC "name" #-} > > where "name" is an arbitrary string, that will become the name of your cost centre as it appears in the profiling output, and is any Haskell expression. However GHC is actually more strict about SCC strings, for example, it doesn't accept spaces: {{{ $ cat test.hs main = {-# SCC "test test" #-} return () $ ghc test.hs [1 of 1] Compiling Main ( test.hs, test.o ) test.hs:1:16: error: Spaces are not allowed in SCCs | 1 | main = {-# SCC "test test" #-} return () | ^^^^^^^^^^^ }}} It's also possible that GHC is right and user manual is wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 08:21:04 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 08:21:04 -0000 Subject: [GHC] #15292: ghc_ticker loops if permission denied on timerfd Message-ID: <065.2e3eba2da7777347cf476e1f6c4c64cc@haskell.org> #15292: ghc_ticker loops if permission denied on timerfd ---------------------------------------+---------------------------------- Reporter: jon.fairbairn@… | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+---------------------------------- Using stack with lts-11.6 to compile a cgi programme, I got something that runs OK from the command line, but which goes into a busy loop when run from httpd. This is caused by selinux preventing read on the timer. Changing the selunix permissions solves the problems, but ghc-ticker ought to check whether the read succeeded and not try again if it fails. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 08:22:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 08:22:13 -0000 Subject: [GHC] #15292: ghc_ticker loops if permission denied on timerfd In-Reply-To: <065.2e3eba2da7777347cf476e1f6c4c64cc@haskell.org> References: <065.2e3eba2da7777347cf476e1f6c4c64cc@haskell.org> Message-ID: <080.d34ab8f4a2bd88c8b2ed5069a783719d@haskell.org> #15292: ghc_ticker loops if permission denied on timerfd ------------------------------------+-------------------------------------- Reporter: jon.fairbairn@… | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Changes (by jon.fairbairn@…): * Attachment "al3" added. Three lines from selinux audit log (shows successive attempts to read timer within same millisecond) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 08:51:40 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 08:51:40 -0000 Subject: [GHC] #15291: Incorrect SCC name parsing according to user manual In-Reply-To: <043.d376bb82d74d734daa2fcf489eac39fe@haskell.org> References: <043.d376bb82d74d734daa2fcf489eac39fe@haskell.org> Message-ID: <058.0efd491c8bbf46cc2cbee2b820043eb6@haskell.org> #15291: Incorrect SCC name parsing according to user manual -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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 osa1): FWIW, here's a 10-years-old program that uses SCC names with spaces: https://github.com/haskell/bytestring/blob/master/tests/Bench.hs It seems like GHC used to accept this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 09:41:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 09:41:06 -0000 Subject: [GHC] #14164: GHC hangs on type family dependency In-Reply-To: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> References: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> Message-ID: <066.45593515da04be467b1acb3b8f18c1ba@haskell.org> #14164: GHC hangs on type family dependency -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T14164 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Can you give an example? One thing to remember: normal substitution is (carefully designed to be) one-shot. That is, it's fine to substitute `a :-> [a]`, say. Even if they happen to have the same unique, we think of the range and the domain as coming from different address spaces. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 09:43:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 09:43:27 -0000 Subject: [GHC] #14164: GHC hangs on type family dependency In-Reply-To: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> References: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> Message-ID: <066.defc19c07a3c03f6240dc1aa96a257de@haskell.org> #14164: GHC hangs on type family dependency -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T14164 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"83a7b1cf5f24eccc54016034d8a6d31dbbc2c263/ghc" 83a7b1c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="83a7b1cf5f24eccc54016034d8a6d31dbbc2c263" Adjust comments (Trac #14164) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 11:19:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 11:19:35 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.cb81df39523054586ad39586aa443779@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Additional runs: - stage1 GHC without state hack and nofib without state hack -> succeeds - stage2 GHC without state hack and nofib with state hack -> succeeds So either there is something strange going on with the combination GHC + libs with state hack, nofib without state hack; or my testing leaves artifacts somehow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 11:22:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 11:22:38 -0000 Subject: [GHC] #14529: Refactor ConDecl In-Reply-To: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> References: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> Message-ID: <061.e624acb692669d21db044eb66a0bd13d@haskell.org> #14529: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 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:D4867 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"676c5754e3f9e1beeb5f01e0265ffbdc0e6f49e9/ghc" 676c575/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="676c5754e3f9e1beeb5f01e0265ffbdc0e6f49e9" Fix API Annotations for GADT constructors Summary: This patch completes the work for #14529 by making sure that all API Annotations end up attached to a SrcSpan that appears in the final ParsedSource. Updates Haddock submodule Test Plan: ./validate Reviewers: goldfire, bgamari Subscribers: rwbarton, thomie, mpickering, carter GHC Trac Issues: #14529 Differential Revision: https://phabricator.haskell.org/D4867 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 12:11:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 12:11:19 -0000 Subject: [GHC] #15291: Incorrect SCC name parsing according to user manual In-Reply-To: <043.d376bb82d74d734daa2fcf489eac39fe@haskell.org> References: <043.d376bb82d74d734daa2fcf489eac39fe@haskell.org> Message-ID: <058.4b0c0ba530b6e7073b6bd74c968a06a4@haskell.org> #15291: Incorrect SCC name parsing according to user manual -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2071 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * related: => #2071 Comment: The restriction was add 10 years ago to fix #2071. See: https://github.com/ghc/ghc/commit/82a7cebaea5dce16fc9658cc6a5ec037348075d1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 12:42:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 12:42:26 -0000 Subject: [GHC] #14164: GHC hangs on type family dependency In-Reply-To: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> References: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> Message-ID: <066.5f198a66d2994024f85c5098d5a02050@haskell.org> #14164: GHC hangs on type family dependency -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T14164 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Suppose `a :: k` and we substitute `[k |-> Type]` in `Proxy k a`. We end up with `Proxy Type a`, but the `k` in `a`'s kind is not substituted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 12:55:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 12:55:23 -0000 Subject: [GHC] #14164: GHC hangs on type family dependency In-Reply-To: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> References: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> Message-ID: <066.095f4343380cfe6f8b3f491758a2f588@haskell.org> #14164: GHC hangs on type family dependency -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T14164 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah I see. So the underlying invariant is * Applying a substitution S to a type t should result in a ''well-kinded'' type S(t). What do we need for that to be true? Perhaps this? If a is in fv(t)\dom(S) then fv(kind(a)) is disjoint from dom(S)? That is, if there is free variable in t that we aren't substituting, then we aren't substituting in its kind either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 13:30:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 13:30:08 -0000 Subject: [GHC] #9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving (was: Need for higher kinded roles) In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.0af975bc4ed16f22a7b777dd51f8b676@haskell.org> #9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Roles, Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T9123{,a} Blocked By: 15290 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah, quite right. Since we have "higher kinded roles" currently (in some sense) due to `QuantifiedConstraints`, I'll change the title of this ticket to reflect its new goal. Speaking of which, let's talk about what it would take to actually accomplish this. I've been inclined to try implementing this myself, but every time I get started, I quickly get lost in the weeds. Assuming that #15290 were fixed, what would it take to train the constraint solver to spit out quantified `Coercible` constraints? My understanding of GHC's constraint solver (which, admittedly, is quite limited) is that it will //never// emit a quantified constraint under any circumstances. Would we have to change this invariant somewhere? Also, would we be feeding a constraint like `forall p q. Coercible p q => Coercible (m p) (m q)` as an input to the constraint solver? Or would it only be an output? I'm afraid I don't really know where to look to answer these questions, so advice would be greatly appreciated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 13:42:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 13:42:52 -0000 Subject: [GHC] #14645: Allow type family in data family return kind In-Reply-To: <047.3515b5078f2cb34cf2db81ba3af73423@haskell.org> References: <047.3515b5078f2cb34cf2db81ba3af73423@haskell.org> Message-ID: <062.fb3fb4252bb1adfffd23530d04b5efc5@haskell.org> #14645: Allow type family in data family return kind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: TypeInType, | TypeFamilies 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 tried giving this a go, but quickly became stuck. I'll dump my progress here in case anyone finds it useful. * The first step is revising a validity check to allow type families to appear in data family return kinds. You'll need a predicate which checks if a type is a type family application: {{{#!hs -- | Returns @'Just' (fam_tc, args)@ if the argument 'Type' is a type family -- constructor @fam_tc@ applied to some arguments @args at . Otherwise, returns -- @Nothing at . tcGetTyFamTyConApp_maybe :: Type -> Maybe (TyCon, [Type]) tcGetTyFamTyConApp_maybe ty | Just ty' <- tcView ty = tcGetTyFamTyConApp_maybe ty' tcGetTyFamTyConApp_maybe (TyConApp fam_tc args) | isTypeFamilyTyCon fam_tc = Just (fam_tc, args) tcGetTyFamTyConApp_maybe _ = Nothing }}} Then you'll need to change `tcFamDecl1` to use this: {{{#!diff ; checkTc (tcIsStarKind final_res_kind - || isJust (tcGetCastedTyVar_maybe final_res_kind)) + || isJust (tcGetCastedTyVar_maybe final_res_kind) + || isJust (tcGetTyFamTyConApp_maybe final_res_kind)) (badKindSig False res_kind) }}} * The next step is to figure out where to grab the type family instance axiom from when typechecking data family instances (in `tcDataFamInstDecl`). My first inclination was to change `tcDataKindSig` to return a `CoAxiom` resulting from the return kind signature. However, this doesn't always work. For instance, in the example from comment:3, the return kind of the `DF Bool (a :: Type)` instance is simply `Type` by the type you get to `tcDataKindSig` (instead of something like `TF Bool`), which makes it essentially impossible to grab a type family axiom from. This makes me suspect that we need to grab this type family axiom earlier, perhaps when typechecking the type family patterns (in `tcFamTyPats`). At this point, I became lost. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 13:46:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 13:46:10 -0000 Subject: [GHC] #14883: QuantifiedConstraints don't kick in when used in TypeApplications In-Reply-To: <050.9ae7dfd18c1aed745c56cdebbc78f3e8@haskell.org> References: <050.9ae7dfd18c1aed745c56cdebbc78f3e8@haskell.org> Message-ID: <065.ab504f049399dbf0b1c77a3065e05956@haskell.org> #14883: QuantifiedConstraints don't kick in when used in TypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 15290 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * blockedby: => 15290 Comment: It turns out the original program now panics due to #15290, so that ticket is blocking this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 14:50:25 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 14:50:25 -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.12b8ffbd96fe9d383b3a269cf2a39a41@haskell.org> #7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: abhir00p Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3557 | Differential Rev(s): Wiki Page: wiki:SIMD | -------------------------------------+------------------------------------- Comment (by carter): I'm supervising abhirr00p on this, theres a bunch of stuff still to do for even rudimentary portable SIMD support. Theres a few gotchas that will be clear from sharp edges in this first iteration -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 15:10:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 15:10:11 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.3587f3c400eff69e4f0662ee78984a90@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 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: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * differential: => Phab:D4769 Comment: Since my last update, the patch in Phab:D4769 works but has performance trouble. I've asked Ben & friends for help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 15:11:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 15:11:18 -0000 Subject: [GHC] #14645: Allow type family in data family return kind In-Reply-To: <047.3515b5078f2cb34cf2db81ba3af73423@haskell.org> References: <047.3515b5078f2cb34cf2db81ba3af73423@haskell.org> Message-ID: <062.f52f68df4cbe9b26863e97a701c9068a@haskell.org> #14645: Allow type family in data family return kind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: TypeInType, | TypeFamilies 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): For step one, I wonder if it would be better to look for return kinds that are not ''apart'' from `TYPE r`. Perhaps this would do it: {{{#!hs -- | Returns whether the two types are apart. Assumes that -- both types have the same kind. apart :: Type -> Type -> Bool apart ty1 ty2 | SurelyApart <- tcUnifyTysFG (const BindMe) [ty1] [ty2] = True | otherwise = False }}} (I'm surprised that function doesn't already exist.) Then, use that to check the return kind against `TYPE r` (where `r` can really be any tyvar). This should subsume the current check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 15:14:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 15:14:28 -0000 Subject: [GHC] #14645: Allow type family in data family return kind In-Reply-To: <047.3515b5078f2cb34cf2db81ba3af73423@haskell.org> References: <047.3515b5078f2cb34cf2db81ba3af73423@haskell.org> Message-ID: <062.b34ed82a708fa17c19190a2682ba825e@haskell.org> #14645: Allow type family in data family return kind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: TypeInType, | TypeFamilies 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): Why do you think you need step 2? I think the existing code in `kcDataDefn` will do the right thing here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 15:21:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 15:21:28 -0000 Subject: [GHC] #14645: Allow type family in data family return kind In-Reply-To: <047.3515b5078f2cb34cf2db81ba3af73423@haskell.org> References: <047.3515b5078f2cb34cf2db81ba3af73423@haskell.org> Message-ID: <062.968e39763bf3d0abf4cc6b317e34eedf@haskell.org> #14645: Allow type family in data family return kind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: TypeInType, | TypeFamilies 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:9 goldfire]: > Why do you think you need step 2? I think the existing code in `kcDataDefn` will do the right thing here. I'm not sure that I understand this comment. You're suggesting that GHC will do all of the steps outlined in comment:3 with only step 1? Experimental evidence suggests that this is not true, as trying an implementation with only step 1 panics when given the program in comment:3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 16:11:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 16:11:02 -0000 Subject: [GHC] #15282: Document how equality-bearing constructors are promoted in Core In-Reply-To: <050.090e2292f6620e97635bea0372f57c50@haskell.org> References: <050.090e2292f6620e97635bea0372f57c50@haskell.org> Message-ID: <065.9d6be28798f69d718980ab39e64e31f7@haskell.org> #15282: Document how equality-bearing constructors are promoted in Core -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14845 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"26e9806ada8823160dd63ca2c34556e5848b2f45/ghc" 26e9806/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="26e9806ada8823160dd63ca2c34556e5848b2f45" Document and simplify tcInstTyBinders This fixes #15282. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 16:23:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 16:23:49 -0000 Subject: [GHC] #14645: Allow type family in data family return kind In-Reply-To: <047.3515b5078f2cb34cf2db81ba3af73423@haskell.org> References: <047.3515b5078f2cb34cf2db81ba3af73423@haskell.org> Message-ID: <062.86005ce41add55c59616976749c2c649@haskell.org> #14645: Allow type family in data family return kind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: TypeInType, | TypeFamilies 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): OK. I was hopelessly optimistic. The problem is that, currently, type family axioms never have casts in quite the spot that `ax2` of comment:3 has one in. So we'd need to make a place for that cast, and I don't see an easy way to do that, because the axiom LHS might be something like `((DF ty1 ty2) |> co) ty3 ty4`. Maybe we need to have axioms just take an LHS type instead of a bunch of patterns. But then we'll run into trouble with matching. I ''think'' we'd have to overhaul `CoAxBranch` and `FamInst` to make this work. I don't actually think it would be all that hard, but a good deal of plumbing would have to move, as we're currently assuming that every axiom LHS looks like `F tys`. Once the plumbing has been rearranged, then the `kind_checker` in tcFamTyPats` would have to return some more exotic structure that takes the applied tycon and transforms it to the correct axiom LHS. This should probably be something of type `TcType -> TcType`. (To be clear, I'm proposing that the 5th argument to `tcFamTyPats` have type `TcKind -> TcM (TcType -> TcType, TcKind)`.) Currently, the `kind_checker` returns extra type patterns; these are always appended to existing patterns. The new form would simply be applied to the family tycon applied to the existing patterns. Then, in `kcDataDefn`, you would build the right transformation from the `co` returned by `checkExpectedKindX` -- right now, this `co` is ignored. Definitely hairier than I thought! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 16:24:32 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 16:24:32 -0000 Subject: [GHC] #15282: Document how equality-bearing constructors are promoted in Core In-Reply-To: <050.090e2292f6620e97635bea0372f57c50@haskell.org> References: <050.090e2292f6620e97635bea0372f57c50@haskell.org> Message-ID: <065.a53075f7866b864f27f8c6d79e934b14@haskell.org> #15282: Document how equality-bearing constructors are promoted in Core -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14845 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge Comment: All set now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 16:39:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 16:39:42 -0000 Subject: [GHC] #9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.a931d3af8bbcad7b5a2a298aefe9bb2b@haskell.org> #9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Roles, Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T9123{,a} Blocked By: 15290 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): If we wanted to do this (and I'm waiting for Simon to say that we don't), the quantified constraint would be only an output from the constraint solver, not an input. The constraint solver works over a tree of constraints, where (roughly) interior nodes are givens (which can bring skolems into scope for their descendants) and leaves are wanteds. When inferring, we build up the tree of constraints and then simplify it to another tree that logically entails the first one. When we can simplify no more, we (roughly) look at the tree. If it's the kind of tree we like to quantify over (`Eq a`: yes. `Int ~ Bool`: no. An implication: no, today), convert it back to a normal constraint and quantify. To infer quantified constraints, all we have to do is change what trees we like to quantify over. Some of the action is in `TcSimplify.approximateWC` which looks to find simple (i.e. non-implication) constraints to quantify over. It will have to be adapted to sometimes return implication constraints. Then, the code in `TcDerivInfer.simplifyDeriv` will have to be taught to handle the implication constraints. I don't think it will be all that invasive, but we might find that we're accepting more programs than we like. See Note [Exotic derived instance contexts] in TcDerivInfer. Perhaps this helps start you off... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 16:43:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 16:43:29 -0000 Subject: [GHC] #14164: GHC hangs on type family dependency In-Reply-To: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> References: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> Message-ID: <066.8714168235987b500beab46cd478cb82@haskell.org> #14164: GHC hangs on type family dependency -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T14164 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Assuming the substitution and type t are both well-kinded, yes. And I agree with your next sentence. But I'd like to divorce the invariant from the type t, because we can. I believe your sentence is implied by (*) INVARIANT: If S is a substitution, then inscope(S)\dom(S) is closed over kinds. This is something easy enough to check for. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 17:17:05 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 17:17:05 -0000 Subject: [GHC] #15293: Set up staging branch Message-ID: <046.acfc865b41ac65a2d16c8050d16d16b4@haskell.org> #15293: Set up staging branch -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: highest | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 Integration | 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: -------------------------------------+------------------------------------- Goal: Keep commits that would break CI out of `master`. Approach: Introduce a staging branch where commits will first land to go through the full CI workup. When a commit passes on `staging`, merge it into `master`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 17:31:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 17:31:47 -0000 Subject: [GHC] #15291: Incorrect SCC name parsing according to user manual In-Reply-To: <043.d376bb82d74d734daa2fcf489eac39fe@haskell.org> References: <043.d376bb82d74d734daa2fcf489eac39fe@haskell.org> Message-ID: <058.439568cd12d14dbf992900733b613393@haskell.org> #15291: Incorrect SCC name parsing according to user manual -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2071 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Nice find. I wonder if hp2ps still doesn't handle spaces. May worth checking. Easiest fix is to update the user manual although I wonder if we should spend some time to actually fix hp2ps. Not sure how hard that would be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 17:32:48 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 17:32:48 -0000 Subject: [GHC] #15291: Incorrect SCC name parsing according to user manual In-Reply-To: <043.d376bb82d74d734daa2fcf489eac39fe@haskell.org> References: <043.d376bb82d74d734daa2fcf489eac39fe@haskell.org> Message-ID: <058.5edcad2ca3c8d09f6a7e7977cbc4f71b@haskell.org> #15291: Incorrect SCC name parsing according to user manual -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2071 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): There's also an alternative to hp2ps now: http://hackage.haskell.org/package/hp2pretty perhaps it accepts spaces in identifiers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 18:38:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 18:38:37 -0000 Subject: [GHC] #14023: Split up glasgow_exts.rst In-Reply-To: <046.00c07fe5ce6492eaedacdeae3c6ea07a@haskell.org> References: <046.00c07fe5ce6492eaedacdeae3c6ea07a@haskell.org> Message-ID: <061.c99945419fa858739c206bc542308862@haskell.org> #14023: Split up glasgow_exts.rst -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Documentation | 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 bgamari): > OTOH there are many cross-references amongst different subsections. Is .rst clever enought to stitch togethere the labels? Indeed it is (assuming the reference is a `:ref:`). > I support splitting up the file: I would love to see this done. My only concern is that we may end up breaking users guide URLs again. That being said, `glasgow_exts` is getting a bit unwieldy so perhaps this is a worthwhile cost to bear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 18:49:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 18:49:58 -0000 Subject: [GHC] #15292: ghc_ticker loops if permission denied on timerfd In-Reply-To: <065.2e3eba2da7777347cf476e1f6c4c64cc@haskell.org> References: <065.2e3eba2da7777347cf476e1f6c4c64cc@haskell.org> Message-ID: <080.6cf2c9de187948090c3abdc41b25358a@haskell.org> #15292: ghc_ticker loops if permission denied on timerfd ------------------------------------+-------------------------------------- Reporter: jon.fairbairn@… | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4875 Wiki Page: | ------------------------------------+-------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4875 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 19:05:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 19:05:42 -0000 Subject: [GHC] #10059: :i doesn't work for ~ In-Reply-To: <045.e4d34da19e8a219c9836208516141cc9@haskell.org> References: <045.e4d34da19e8a219c9836208516141cc9@haskell.org> Message-ID: <060.768eb9f2c85cd1ac17f99b48dc3f3d11@haskell.org> #10059: :i doesn't work for ~ -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10056, #12023 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Then again, it turns out that the `:info` output for `(~~)` is similarly broken: {{{ GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> import Data.Type.Equality λ> :i (~~) class ((a :: k0) ~~ (b :: k1)) => (~~) (a :: k0) (b :: k1) -- Defined in ‘GHC.Types’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 19:10:40 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 19:10:40 -0000 Subject: [GHC] #15234: WARNING in hptSomeThingsBelowUs when using a source plugin In-Reply-To: <049.15722b69a2f4eb74d7898931a7d1b55a@haskell.org> References: <049.15722b69a2f4eb74d7898931a7d1b55a@haskell.org> Message-ID: <064.c1a68386399d1230e4d3fac0cd9c4ccf@haskell.org> #15234: WARNING in hptSomeThingsBelowUs when using a source plugin -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | SourcePlugins, plugins 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): Every plugin I have tried has this problem. For example - https://github.com/mpickering/plugin-constraint -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 19:43:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 19:43:46 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.234e06d8165a4e7efba10b661008effa@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059, #10431, | Differential Rev(s): Phab:D4876 #14316 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => Phab:D4876 Comment: Post-d650729f9a0f3b6aa5e6ef2d5fba337f6f70fa60, it's quite easy to remove `HsEqTy`, at the very least. I've done so in Phab:D4876. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 20:36:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 20:36:59 -0000 Subject: [GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module In-Reply-To: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> References: <047.c258bd8a8d43881f32b193f6cbfcf8f0@haskell.org> Message-ID: <062.fc25a8f1ada1ddb3612e49bf0d5b530e@haskell.org> #14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: tdammers Type: bug | Status: patch Priority: high | Milestone: 8.4.2 Component: GHCi | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/should_run/T14963 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4833 Wiki Page: | Phab:D4830 -------------------------------------+------------------------------------- Changes (by Remi): * cc: remi.turk@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 22:46:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 22:46:20 -0000 Subject: [GHC] #10059: :i doesn't work for ~ In-Reply-To: <045.e4d34da19e8a219c9836208516141cc9@haskell.org> References: <045.e4d34da19e8a219c9836208516141cc9@haskell.org> Message-ID: <060.75e92e5af2d5be6d4aadb3ad4d7c6a53@haskell.org> #10059: :i doesn't work for ~ -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10056, #12023 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Both `:info`s look correct to me. Turn on `-fprint-equality-relations` to get better output. I don't know how to do better, given `-fprint-equality- relations`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 19 23:35:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Jun 2018 23:35:50 -0000 Subject: [GHC] #10059: :i doesn't work for ~ In-Reply-To: <045.e4d34da19e8a219c9836208516141cc9@haskell.org> References: <045.e4d34da19e8a219c9836208516141cc9@haskell.org> Message-ID: <060.ef7884264b0922e1272bddd5538bb677@haskell.org> #10059: :i doesn't work for ~ -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10056, #12023 | Differential Rev(s): Phab:D4877 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4877 Comment: In that case, let's do this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 20 00:15:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jun 2018 00:15:54 -0000 Subject: [GHC] #11627: Segmentation fault for space_leak_001 with profiling (-hc) In-Reply-To: <045.274c910606d60239cadf6f398a2dd711@haskell.org> References: <045.274c910606d60239cadf6f398a2dd711@haskell.org> Message-ID: <060.c87bbb81595a0d6413031709a550372f@haskell.org> #11627: Segmentation fault for space_leak_001 with profiling (-hc) -------------------------------------+------------------------------------- Reporter: thomie | Owner: jme Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Profiling | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: | perf/space_leaks/space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2005 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f0179e3adf6677243f587a05307a4a42833aa8d1/ghc" f0179e3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f0179e3adf6677243f587a05307a4a42833aa8d1" testsuite: Skip T11627a and T11627b on Darwin Darwin tends to give us a very small stack which the retainer profiler tends to overflow. Strangely, this manifested on CircleCI yet not Harbormaster. See #15287 and #11627. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 20 00:15:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jun 2018 00:15:54 -0000 Subject: [GHC] #15287: T11627[ab] fail on some Darwin environments In-Reply-To: <046.b4a6b2737b3c1fbfc1faf99f30e4d4f9@haskell.org> References: <046.b4a6b2737b3c1fbfc1faf99f30e4d4f9@haskell.org> Message-ID: <061.435b80e742d2ca49e9f6ab16c7b538fc@haskell.org> #15287: T11627[ab] fail on some Darwin environments -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14758 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f0179e3adf6677243f587a05307a4a42833aa8d1/ghc" f0179e3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f0179e3adf6677243f587a05307a4a42833aa8d1" testsuite: Skip T11627a and T11627b on Darwin Darwin tends to give us a very small stack which the retainer profiler tends to overflow. Strangely, this manifested on CircleCI yet not Harbormaster. See #15287 and #11627. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 20 00:15:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jun 2018 00:15:54 -0000 Subject: [GHC] #15289: isUnliftedType GHC panic on pattern with True :: Maybe In-Reply-To: <043.406dc7510cae6790ee47421c68dfc69f@haskell.org> References: <043.406dc7510cae6790ee47421c68dfc69f@haskell.org> Message-ID: <058.a1701d6b22f176ac98294e18a7ae6fde@haskell.org> #15289: isUnliftedType GHC panic on pattern with True :: Maybe -------------------------------------+------------------------------------- Reporter: Remi | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: Resolution: | PatternSynonyms 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 Ben Gamari ): In [changeset:"7b8dcd90c5a622146dfdd3b162a1f1b1d262d5cf/ghc" 7b8dcd90/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7b8dcd90c5a622146dfdd3b162a1f1b1d262d5cf" testsuite: Add broken test for #15289 The stderr output is merely a guess at what we should expect, but currently this is certainly broken. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 20 00:15:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jun 2018 00:15:54 -0000 Subject: [GHC] #15098: Missing instances for Down In-Reply-To: <045.d367dfe3c3f3b98fcc231593185ffd4d@haskell.org> References: <045.d367dfe3c3f3b98fcc231593185ffd4d@haskell.org> Message-ID: <060.3efd44b6c64b6243ea5e8fe16a47fdec@haskell.org> #15098: Missing instances for Down -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.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:D4870 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"21fa62feace8524cbf4559ccfcc96b22cb07879f/ghc" 21fa62f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="21fa62feace8524cbf4559ccfcc96b22cb07879f" base: Add missing instances for Data.Ord.Down Specifically: * MonadFix * MonadZip * Data * Foldable * Traversable * Eq1 * Ord1 * Read1 * Show1 * Generic * Generic1 Fixes #15098. Reviewers: RyanGlScott, hvr Reviewed By: RyanGlScott Subscribers: sjakobi, rwbarton, thomie, ekmett, carter GHC Trac Issues: #15098 Differential Revision: https://phabricator.haskell.org/D4870 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 20 01:42:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jun 2018 01:42:10 -0000 Subject: [GHC] #15098: Missing instances for Down In-Reply-To: <045.d367dfe3c3f3b98fcc231593185ffd4d@haskell.org> References: <045.d367dfe3c3f3b98fcc231593185ffd4d@haskell.org> Message-ID: <060.df0411352f2f327c329e306d02e09b95@haskell.org> #15098: Missing instances for Down -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 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:D4870 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 20 12:22:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jun 2018 12:22:27 -0000 Subject: [GHC] #15286: "Can't use Natural in base" when compiling GHC.Natural with -O0 In-Reply-To: <048.cfab6e6ea21d7113a33d736cfa0133f3@haskell.org> References: <048.cfab6e6ea21d7113a33d736cfa0133f3@haskell.org> Message-ID: <063.bc1f6b0d3edf84ac99804ff6b1767c2b@haskell.org> #15286: "Can't use Natural in base" when compiling GHC.Natural with -O0 -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 8.5 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): Phab:D4880 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => patch * differential: => Phab:D4880 Comment: I can reproduce. I agree that the integration of built-in Natural (and Integer) in GHC is fragile... Maybe we should fully disable Natural built- in rules when we compile `base` to avoid this issue. In the meantime I have implemented your workaround in Phab:D4880 (it also fixes a critical copy-paste bug). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 20 12:31:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jun 2018 12:31:26 -0000 Subject: [GHC] #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.3eaffc16cad6e9e596dd8ec53988c489@haskell.org> #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context -------------------------------------+------------------------------------- Reporter: cactus | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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 AntC): [https://github.com/ghc/ghc/pull/150 patch incoming]. See comment on it; and apologies for my incompetence with git: I couldn't figure out how to avoid resending the patch for Trac #15146 doco (also for Users Guide/glasgow_exts, but section 10.16) that I sent last month. I'm not changing any of that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 20 13:05:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jun 2018 13:05:23 -0000 Subject: [GHC] #14858: Typed hole subtitution search fails in the REPL In-Reply-To: <044.605f4aa7b63ca26feac6d76a97945eb0@haskell.org> References: <044.605f4aa7b63ca26feac6d76a97945eb0@haskell.org> Message-ID: <059.f77f26e676672983c0cedaad5dfe8858@haskell.org> #14858: Typed hole subtitution search fails in the REPL -------------------------------------+------------------------------------- Reporter: paf31 | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.4.1-alpha3 checker) | Resolution: | Keywords: TypedHoles 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 sighingnow): * owner: (none) => sighingnow -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 20 14:46:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jun 2018 14:46:57 -0000 Subject: [GHC] #15294: Unused "foralls" prevent types from being Coercible Message-ID: <051.6b12be8fe6cf4eff30184ed964b131c7@haskell.org> #15294: Unused "foralls" prevent types from being Coercible -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: Roles | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Just a quick question, do these have the same representation? {{{#!hs newtype A where A :: (Int -> Bool) -> A newtype B where B :: (forall (a::Type). Int -> Bool) -> B }}} I'm wondering because they aren't `Coercible` {{{ > :t coerce :: A -> B :1:1: error: • Couldn't match representation of type ‘forall a. Int -> Bool’ with that of ‘Int -> Bool’ arising from a use of ‘coerce’ • In the expression: coerce :: A -> B }}} What about a new type `C`, that isn't `Coercible` to `B` either {{{#!hs newtype C where C :: (forall k (a :: k). Int -> Bool) -> C }}} Some is true when it's just the order of variables {{{#!hs -- D is not Coercible to E, "can't match type ‘Bool’ with ‘Ordering’" newtype D where D :: (forall (a::Bool) (b::Ordering). Int -> Bool) -> D newtype E where E :: (forall (a::Ordering) (b::Bool). Int -> Bool) -> E }}} My question is is this intended? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 20 14:56:17 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jun 2018 14:56:17 -0000 Subject: [GHC] #15294: Unused "foralls" prevent types from being Coercible In-Reply-To: <051.6b12be8fe6cf4eff30184ed964b131c7@haskell.org> References: <051.6b12be8fe6cf4eff30184ed964b131c7@haskell.org> Message-ID: <066.bcb993c5a6f1933ce0f317fdcdc9c4a5@haskell.org> #15294: Unused "foralls" prevent types from being Coercible -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Roles 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: > Just a quick question, do these have the same representation? > > {{{#!hs > newtype A where > A :: (Int -> Bool) -> A > > newtype B where > B :: (forall (a::Type). Int -> Bool) -> B > }}} > > I'm wondering because they aren't `Coercible` > > {{{ > > :t coerce :: A -> B > > :1:1: error: > • Couldn't match representation of type ‘forall a. Int -> Bool’ > with that of ‘Int -> Bool’ > arising from a use of ‘coerce’ > • In the expression: coerce :: A -> B > }}} > > What about a new type `C`, that isn't `Coercible` to `B` either > > {{{#!hs > newtype C where > C :: (forall k (a :: k). Int -> Bool) -> C > }}} > > Some is true when it's just the order of variables > > {{{#!hs > -- D is not Coercible to E, "can't match type ‘Bool’ with ‘Ordering’" > > newtype D where > D :: (forall (a::Bool) (b::Ordering). Int -> Bool) -> D > > newtype E where > E :: (forall (a::Ordering) (b::Bool). Int -> Bool) -> E > }}} > > My question is is this intended? New description: Just a quick question, do these have the same representation? {{{#!hs newtype A where A :: (Int -> Bool) -> A newtype B where B :: (forall (a::Type). Int -> Bool) -> B }}} I'm wondering because they aren't `Coercible` {{{ > :t coerce :: A -> B :1:1: error: • Couldn't match representation of type ‘forall a. Int -> Bool’ with that of ‘Int -> Bool’ arising from a use of ‘coerce’ • In the expression: coerce :: A -> B }}} `C` isn't `Coercible` to `B` either {{{#!hs newtype C where C :: (forall k (a :: k). Int -> Bool) -> C }}} Also {{{#!hs -- D is not Coercible to E, "can't match type ‘Bool’ with ‘Ordering’" newtype D where D :: (forall (a::Bool) (b::Ordering). Int -> Bool) -> D newtype E where E :: (forall (a::Ordering) (b::Bool). Int -> Bool) -> E }}} My question is is this intended? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 20 15:51:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jun 2018 15:51:47 -0000 Subject: [GHC] #10059: :i doesn't work for ~ In-Reply-To: <045.e4d34da19e8a219c9836208516141cc9@haskell.org> References: <045.e4d34da19e8a219c9836208516141cc9@haskell.org> Message-ID: <060.9025b0a48934509a5d42898de459e54a@haskell.org> #10059: :i doesn't work for ~ -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10056, #12023 | Differential Rev(s): Phab:D4877 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f4dce6cfd71d2a1dc2e281f19cae85e62aaf6b8e/ghc" f4dce6c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f4dce6cfd71d2a1dc2e281f19cae85e62aaf6b8e" Allow :info for (~) in GHCi `(~)` is not an identifier according to GHC's parser, which is why GHCi's `:info` command wouldn't work on it. To rectify this, we apply the same fix that was put in place for `(->)`: add `(~)` to GHC's `identifier` parser production. Test Plan: make test TEST=T10059 Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, mpickering, carter GHC Trac Issues: #10059 Differential Revision: https://phabricator.haskell.org/D4877 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 20 15:51:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jun 2018 15:51:47 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.1f6bb667f8fc4a07f0ad5a95e555b8d4@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059, #10431, | Differential Rev(s): Phab:D4876 #14316 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b9483981d128f55d8dae3f434f49fa6b5b30c779/ghc" b9483981/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b9483981d128f55d8dae3f434f49fa6b5b30c779" Remove HsEqTy and XEqTy After commit d650729f9a0f3b6aa5e6ef2d5fba337f6f70fa60, the `HsEqTy` constructor of `HsType` is essentially dead code. Given that we want to remove `HsEqTy` anyway as a part of #10056 (comment:27), let's just rip it out. Bumps the haddock submodule. Test Plan: ./validate Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #10056 Differential Revision: https://phabricator.haskell.org/D4876 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 20 16:48:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jun 2018 16:48:27 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.a27d2d7eff69884185b9941a893b083e@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.8.4 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059, #10431, | Differential Rev(s): Phab:D4876 #14316 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 20 16:48:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jun 2018 16:48:47 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.19e11febf27bd39aa36c7f522d85b471@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059, #10431, | Differential Rev(s): Phab:D4876 #14316 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 20 16:54:39 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jun 2018 16:54:39 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.358c352d21085651858fa093f08d4bca@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): Don't know anything about Apple's clang, but exactly the same way behaves Windows msvc‑abi‑targeted clang – it inserts nothing. Generally, clang is able to mimic both gcc behaviour *and* native platform toolset behavior, and tries to be gcc compatible when targeting gnu triplet and native toolset compatible when targeting native triplet. Thus, I believe changing `#if defined(__clang__)` to `#if defined(__clang__) && !defined (__GNUC__)` should suffice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 20 18:01:58 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jun 2018 18:01:58 -0000 Subject: [GHC] #15295: Haddock options should be concatened Message-ID: <046.234e50e311e74e13a22a289f266ad26f@haskell.org> #15295: Haddock options should be concatened -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Keywords: haddock | 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 the following situation: 1. If we have an `OPTIONS_HADDOCK` pragma, any CLI options from `-haddock- opts` are ignored 2. If there are multiple `OPTIONS_HADDOCK` pragmas, only the last one is remembered. Instead all options should be concatenated (with `, `), with the CLI options at the end. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 20 18:09:09 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jun 2018 18:09:09 -0000 Subject: [GHC] #15294: Unused "foralls" prevent types from being Coercible In-Reply-To: <051.6b12be8fe6cf4eff30184ed964b131c7@haskell.org> References: <051.6b12be8fe6cf4eff30184ed964b131c7@haskell.org> Message-ID: <066.a136e2cf2c29a22cb428ec6f01cf691a@haskell.org> #15294: Unused "foralls" prevent types from being Coercible -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Roles 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 think this is expected behavior. Representational equality still falls short of its goal of equating all things with equal representation. For example, `Bool` is not `Coercible` to `data BBool = FFalse | TTrue`, even though `Bool` and `BBool` (plausibly) have the same representation. It's true that `forall a. Int -> Bool` and `Int -> Bool` have the same runtime representation, but they crucially look quite different in Core. A member of `forall a. Int -> Bool` looks like `/\ (a :: Type). \ (x :: Int). ...`, while a member of `Int -> Bool` looks like `\ (x :: Int). ...`. One could imagine extending representational equality in this way (it would be sound, if we get the details right), but I don't think it's worth it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 20 18:56:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jun 2018 18:56:42 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.28380c02d3ca40369d06854a6da5ebe5@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * Attachment "nofib-analyse.log.gz" added. nofib analyse output (gzipped because of size limit) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 20 18:56:58 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jun 2018 18:56:58 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.279cfc0ef01f8bd7272a34685fa578f9@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): OK, so it turns out that make clean doesn't actually clean things up thoroughly enough. I did another test run, building both GHC and nofib from a fresh checkout for each run, and now everything works just fine. So it seems that the core dumps I got earlier were somehow caused by artifacts from a previous build still being in the build tree somewhere; clearly if you link things together in ways they weren't meant to, strange behavior is to be expected. Now armed with that, and a fixed `fasta` implementation from #15225, I managed to do six nofib runs; the interesting ones are: - Both GHC and nofib compiled with the state hack in place - this is the current situation (`nofibrun-gs_ns2.log`) - GHC with the state hack, nofib compiled with `-fno-state-hack` (`nofibrun-gs-nn2.log` - Both GHC and nofib compiled with `-fno-state-hack` (`nofibrun- gn_nn2.log`) Results from nofib-analyse attached; key takeaway however is that the difference overall is small and slightly in favor of removing the state hack. A few interesting deviations that stand out: - GHC compiled with `-fno-state-hack` consistently produces larger binaries, by about 5% - Programs compiled with a GHC compiled with `-fno-state-hack` run faster by 3.2% on average, but there is a lot of deviation - Most of the above improvements seem to be from more efficient GC - Compile times differ drastically; vanilla GHC compiling programs with `-fno-state-hack` is 23.6% faster on average than the same compiler with the state hack; compiling GHC itself with `-fno-state-hack` and then compiling the nofib suite also with `-fno-state-hack` is almost 50% faster than compiling everything normally. The difference in allocations is even more whopping, with 35.5% and 58.3% respectively. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 20 19:05:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jun 2018 19:05:44 -0000 Subject: [GHC] #15294: Unused "foralls" prevent types from being Coercible In-Reply-To: <051.6b12be8fe6cf4eff30184ed964b131c7@haskell.org> References: <051.6b12be8fe6cf4eff30184ed964b131c7@haskell.org> Message-ID: <066.e3545ed0124b7feb0779e440402c61c8@haskell.org> #15294: Unused "foralls" prevent types from being Coercible -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: wontfix | Keywords: Roles 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): * status: new => closed * resolution: => wontfix Comment: Ah yeah I see the difficulty, I wanted to make sure :) thanks for the response closing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 20 20:46:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Jun 2018 20:46:35 -0000 Subject: [GHC] #15257: Broken symlinks in lndir build tree In-Reply-To: <049.f0b63926608607176eb8bb749ef67790@haskell.org> References: <049.f0b63926608607176eb8bb749ef67790@haskell.org> Message-ID: <064.bce0f621d60821511ea11d9203f8f889@haskell.org> #15257: Broken symlinks in lndir build tree -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.5 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): Phab:D4853 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * status: closed => new * resolution: fixed => Comment: Unfortunately the fix broke the build on OS X, as `ln -L` is not supported (see d55035f5fe13). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 08:04:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 08:04:54 -0000 Subject: [GHC] #15288: Figure out what to do about retainer profiling debugging code In-Reply-To: <046.635868eb934793530aa87e6e051acfdd@haskell.org> References: <046.635868eb934793530aa87e6e051acfdd@haskell.org> Message-ID: <061.b5b5b58bf1ee11d8e8a09699b1a1523c@haskell.org> #15288: Figure out what to do about retainer profiling debugging code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 simonmar): I'm OK with removing it from the repo. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 08:30:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 08:30:46 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.9981f59a83f38f4225ad401896a7974f@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Well this is surprising news, but I think good news too. Maybe we can kill off the state hack altogether! But before we do that, let's really understand our data. (A minor point: in the nfib-analyse output, the column headings are cut off in the summary table; can you use shorter file names?) * I'm astounded by the reduction in compile time (and compiler allocation), in both variants. Is that caused by (a) a faster GHC stage 2, or (b) smaller Core sizes? Could you pick a module with a particularly big reduction, and dig into why? I confess that I am a bit suspicious. Compile times don't usually halve! * Binary sizes go up 5% when "GHC is compiled with -fno-state-hack". I think that the important thing is that the '''libraries''' (which are linked into the nofib binary) are compiled with -fno-state-hack. I doubt it's caused by the fact that ghc-stage2 is compiled with -fno-state-hack. Can you confirm? * And if binary sizes go up by 5% because the libraries are getting bigger, is that a generic 5% increase in .o file size? Or do a few key modules get a lot bigger? It's puzzling because the per-moudule "Module Sizes" stats in the nofib log suggest that there is an essentially-zero effect on nofib module sizes. * As I wrote above, the motivation for the state hack is functions lie {{{ f :: [Int] -> IO () f xs = print ys >> print xs where ys = reverse xs test 0 = return () test n = f [1,n] >> test (n-1) }}} which I expected to be much less efficient without the state hack. Would it be worth trying to demonstrate a program that does get worse in this way? I'm still amazed at how good the results are! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 08:31:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 08:31:24 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.a6695603c4333946ad182d423c1553b1@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): PS: the bad-ness of 'make clean' is also a worry. It wasted a lot of your time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 08:49:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 08:49:43 -0000 Subject: [GHC] #15296: Sentence is about Complex type but mentions Simple constructor Message-ID: <045.24ba50a15c7175c666a272d89aa697bd@haskell.org> #15296: Sentence is about Complex type but mentions Simple constructor -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.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: -------------------------------------+------------------------------------- There is a mistype in one of the sentences regarding Roles in the documentation : https://ghc.readthedocs.io/en/latest/glasgow_exts.html#nominal- representational-and-phantom {{{ Here are some examples: data Simple a = MkSimple a -- a has role representational type family F type instance F Int = Bool type instance F Age = Char data Complex a = MkComplex (F a) -- a has role nominal data Phant a = MkPhant Bool -- a has role phantom }}} The type Simple has its parameter at role representational, which is generally the most common case. Simple Age would have the same representation as Simple Int. The type Complex, on the other hand, has its parameter at role nominal, because Simple Age and Simple Int are not the same. Lastly, Phant Age and Phant Bool have the same representation, even though Age and Bool are unrelated. The wrong sentence is `The type Complex, on the other hand, has its parameter at role nominal, because Simple Age and Simple Int are not the same. ` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 08:50:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 08:50:02 -0000 Subject: [GHC] #15296: Sentence is about Complex type but mentions Simple constructor In-Reply-To: <045.24ba50a15c7175c666a272d89aa697bd@haskell.org> References: <045.24ba50a15c7175c666a272d89aa697bd@haskell.org> Message-ID: <060.e8e6b9adcb45bbb6320e2edc2819c8ca@haskell.org> #15296: Sentence is about Complex type but mentions Simple constructor -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.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 v0d1ch): * owner: (none) => v0d1ch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 09:11:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 09:11:18 -0000 Subject: [GHC] #15296: Sentence is about Complex type but mentions Simple constructor In-Reply-To: <045.24ba50a15c7175c666a272d89aa697bd@haskell.org> References: <045.24ba50a15c7175c666a272d89aa697bd@haskell.org> Message-ID: <060.95c25348f64f4c3405f5e9af4a6d4414@haskell.org> #15296: Sentence is about Complex type but mentions Simple constructor -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.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 osa1): * status: new => patch Comment: Patch is on Github: https://github.com/ghc/ghc/pull/151 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 12:14:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 12:14:45 -0000 Subject: [GHC] #15297: Add support for insert, extract and broadcast SIMD instructions for native X86 codegen Message-ID: <047.4bffbe7200658f0f54340c87ff625fda@haskell.org> #15297: Add support for insert, extract and broadcast SIMD instructions for native X86 codegen -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 13:20:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 13:20:16 -0000 Subject: [GHC] #12848: Reduce long-term memory usage of GHCi In-Reply-To: <047.67e660d21ca1bf05a200182e30500999@haskell.org> References: <047.67e660d21ca1bf05a200182e30500999@haskell.org> Message-ID: <062.90a1409426bf232960ade1469add1be6@haskell.org> #12848: Reduce long-term memory usage of GHCi ------------------------------------+-------------------------------------- Reporter: arybczak | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by saurabhnanda): Is https://simonmar.github.io/posts/2018-06-20-Finding-fixing-space- leaks.html related to this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 14:02:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 14:02:07 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.3177ae7b03bb4943519c846d62f721d5@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Good grief. At first I thought the problem was simple, but now I realise there is more to it than that. Here is a minimised version that crashes {{{ {-# LANGUAGE TypeApplications, ImpredicativeTypes, ScopedTypeVariables, QuantifiedConstraints, StandaloneDeriving, GeneralizedNewtypeDeriving #-} module T15290 where import Prelude hiding ( Monad(..) ) import Data.Coerce ( Coercible, coerce ) class Monad m where join :: m (m a) -> m a newtype StateT s m a = StateT { runStateT :: s -> m (s, a) } newtype IntStateT m a = IntStateT { runIntStateT :: StateT Int m a } instance (Monad m, forall p q. Coercible p q => Coercible (m p) (m q)) => Monad (IntStateT m) where join = coerce @(forall a. StateT Int m (StateT Int m a) -> StateT Int m a) @(forall a. IntStateT m (IntStateT m a) -> IntStateT m a) join }}} The `deriving` mechanism tries to instantiate `coerce` at a polymorphic type, a form of impredicative polymorphism, so it's on thin ice. And in fact the ice breaks. The call to `coerce` gives rise to {{{ Coercible (forall a. blah1) (forall a. blah2) }}} and that soon simplifies to the implication constraint (because of the forall) {{{ forall a . m (Int, IntStateT m a) ~R# m (Int, StateT Int m a) }}} But, becuase this constraint is under a forall, inside a type, we have to prove it ''without computing any term evidence''. Hence the ``, meaning I can't generate any term-level evidence bindings. Alas, I ''must'' generate a term-level evidence binding, to instantiate the quantified constraint. Currently GHC crashes, but I suppose it should instead decline to consult given quantified constraints if it's in a context where evidence bindings are not allowed. I don't see any way out here. All this arises from a sneaky attempt to use impredicative polymorphism. Maybe instead the derviing mechansim should generate {{{ join = (coerce @(StateT Int m (StateT Int m a) -> StateT Int m a) @(IntStateT m (IntStateT m a) -> IntStateT m a) join) :: forall a. IntStateT m (IntStateT m a) -> IntStateT m a }}} and use ordinary predicative instantiation for `coerce`. And indeed that works fine right now. It'll mean a bit more work for the `deriving` mechanism, but not much. Richard and Ryan may want to comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 14:09:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 14:09:25 -0000 Subject: [GHC] #14980: Runtime performance regression with binary operations on vectors In-Reply-To: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> References: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> Message-ID: <060.88e496a85ed29f0b0e3399bb90f5192d@haskell.org> #14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: vector | bitwise operations 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 tdammers): Hmm, I spent all day trying to reproduce this, but I'm getting exactly the results you'd want. I built the package with cabal, once using ghc 8.0.2, and once using 8.2.2 (both installed from linux-x86_64 release bundles downloaded directly from haskell.org), and I get the same behavior across both compilers, with performance metrics similar to what you're seeing in the 8.0.2 case. Output from `performance-bug-pair1`, compiled with GHC 8.2.2: {{{ tobias at zoidberg:~/well-typed/devel/ghc-T14980/ghc-bug/ > performance-bug- pair-1 "Generated" benchmarking 256 columns/raw unbox vectors time 478.6 μs (477.8 μs .. 479.9 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 476.4 μs (476.0 μs .. 477.0 μs) std dev 1.501 μs (1.076 μs .. 2.501 μs) benchmarking 256 columns/binary packed time 275.2 μs (271.7 μs .. 278.6 μs) 0.999 R² (0.998 R² .. 1.000 R²) mean 280.2 μs (276.6 μs .. 283.2 μs) std dev 6.706 μs (5.090 μs .. 9.040 μs) variance introduced by outliers: 13% (moderately inflated) }}} And with 8.0.2: {{{ "Generated" benchmarking 256 columns/raw unbox vectors time 476.9 μs (474.4 μs .. 480.5 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 473.5 μs (472.5 μs .. 475.1 μs) std dev 4.097 μs (2.212 μs .. 7.591 μs) benchmarking 256 columns/binary packed time 291.3 μs (286.8 μs .. 295.4 μs) 0.999 R² (0.998 R² .. 1.000 R²) mean 297.4 μs (293.6 μs .. 300.1 μs) std dev 6.918 μs (4.971 μs .. 9.873 μs) variance introduced by outliers: 12% (moderately inflated) }}} So there must be something about my setup that makes the bug disappear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 14:20:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 14:20:13 -0000 Subject: [GHC] #14980: Runtime performance regression with binary operations on vectors In-Reply-To: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> References: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> Message-ID: <060.6fe8903f935934f6f1a1c1f127372ada@haskell.org> #14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: vector | bitwise operations 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 ttylec): Hm... not exactly the bug disappear, you observed no speedup with "binary packed" version in the first place. Notice that in my benchmark, the "binary packed" version is an order of magnitude faster that the "unbox vectors" and the bug is about loosing that speed-up when we compile with 8.2.2 (and later) In your case, there was no speed-up in the first place. May I ask you to check also `stack exec performance-bug-pair-2` and `stack exec performance-bug-2`? I am curious on what machine/system you did tested it? Oh, and obviously optimization must be enabled (in case you didn't `stack build` it). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 14:22:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 14:22:19 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.042cfb20a7e3974486d9850c1a9ccf21@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I don't think your workaround is sufficient to avoid the issue. Consider what would happen if we had a variant of `join` with this type signature: {{{#!hs join :: (forall b. b -> a) -> m (m a) -> m a }}} If we plug that in to our proposed scheme: {{{#!hs {-# LANGUAGE TypeApplications, ImpredicativeTypes, ScopedTypeVariables, QuantifiedConstraints, StandaloneDeriving, GeneralizedNewtypeDeriving #-} module T15290 where import Prelude hiding ( Monad(..) ) import Data.Coerce ( Coercible, coerce ) class Monad m where join :: (forall b. b -> a) -> m (m a) -> m a newtype StateT s m a = StateT { runStateT :: s -> m (s, a) } instance Monad m => Monad (StateT s m) where newtype IntStateT m a = IntStateT { runIntStateT :: StateT Int m a } instance (Monad m, forall p q. Coercible p q => Coercible (m p) (m q)) => Monad (IntStateT m) where join = coerce @((forall b. b -> a) -> StateT Int m (StateT Int m a) -> StateT Int m a) @((forall b. b -> a) -> IntStateT m (IntStateT m a) -> IntStateT m a) join :: forall a. (forall b. b -> a) -> IntStateT m (IntStateT m a) -> IntStateT m a }}} Then that, too, will panic: {{{ $ /opt/ghc/head/bin/ghc Bug.hs [1 of 1] Compiling T15290 ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.5.20180616 for x86_64-unknown-linux): addTcEvBind NoEvBindsVar [G] df_a1pg = \ (@ p_aW5) (@ q_aW6) (v_B1 :: Coercible p_aW5 q_aW6) -> coercible_sel @ * @ (m_a1nx[ssk:1] p_aW5) @ (m_a1nx[ssk:1] q_aW6) (df_a1nz @ p_aW5 @ q_aW6 v_B1) a1og Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcRnMonad.hs:1404:5 in ghc:TcRnMonad }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 14:26:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 14:26:10 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.3677057e6d1a29f762dd864859ac0cb9@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, I agree. I'll stop the panic (by refraining from using quantified constraints if I have no place to put the evidence) but that will make GHC reject `deriving` for * A higher rank method * That makes essential use of a quantified constraint * Under a forall I don't see how to avoid that restriction. If anyone else does, please say so! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 14:32:12 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 14:32:12 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.afa80f2a8fe4872dd9b07894e18cbcd7@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Wait, you're saying that deriving classes with methods that use higher- rank types will no longer work? If so, that is going to break enormous swaths of code both in the wild and in the test suite (see [http://git.haskell.org/ghc.git/blob/3048a87a3f2ef97d9f6559064d7a32ec7566542b:/testsuite/tests/deriving/should_compile/T8631.hs#l14 here] for one example). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 14:42:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 14:42:47 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.e68078c99a0b463e0699d0d7994968ad@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Wait, you're saying that deriving classes with methods that use higher- rank types will no longer work? No, I am not saying that (see the second bullet). It's just that if you can't ''simultaneously'' exploit impredicative instantiation of `coerce` and quantified constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 14:46:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 14:46:28 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.7262cd2828ecce5cd5e19a4abda33880@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah, my apologies. I interpreted that list of bullet points as three separate criteria under which `deriving` would fail, not as a list of three conditions which must simultaneously hold. In that case, I feel much better about this idea (if this really is the only way forward). I've always thought that derived instance methods should use `InstanceSigs`, and this gives us a good excuse to do so. (And I think certain folks, possibly from Iceland, will find that more aesthetically pleasing to look at in `-ddump-deriv` output.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 14:50:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 14:50:00 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.26a8d1543eedc385feec6dd094a9ccf2@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): You could use `InstanceSigs`; or just an expression type signature as I have done. And incidentally you can them omit the second type argument to `coerce`, which is perhaps nice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 14:52:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 14:52:06 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.00cda99068957ba20941b1d8414bf771@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To be clear: are you working on the change to `deriving` alongside the typechecker changes? Or should I implement the `deriving` bits? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 15:00:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 15:00:20 -0000 Subject: [GHC] #14883: QuantifiedConstraints don't kick in when used in TypeApplications In-Reply-To: <050.9ae7dfd18c1aed745c56cdebbc78f3e8@haskell.org> References: <050.9ae7dfd18c1aed745c56cdebbc78f3e8@haskell.org> Message-ID: <065.472d2a68ee7c037cb5e4a4808fa1f666@haskell.org> #14883: QuantifiedConstraints don't kick in when used in TypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 15290 | Blocking: Related Tickets: #15290 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15290 Comment: In light of https://ghc.haskell.org/trac/ghc/ticket/15290#comment:5, perhaps it's best that we not pursue making the impredicative variants typecheck. If we incorporate the change to `deriving` that Simon suggests in that ticket, then the code that would be generated for the original program would be: {{{#!hs instance Traversable' m => Traversable' (T1 m) where traverse' :: forall f a b. (Applicative' f) => (a -> f b) -> T1 m a -> f (T1 m b) traverse' = coerce @((a -> f b) -> m a -> f (m b)) traverse' }}} Which, conveniently enough, is pretty much exactly the `-- Typechecks` variant! So that's convenient. I'll keep this ticket open since as a reminder to check in these two lovely test cases, but implementing the `deriving` change in #15290 should make this whole issue moot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 15:18:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 15:18:16 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.65e9cfb02915397efa9da0aab5ddc89b@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Could you do the `deriving` bits? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 15:20:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 15:20:25 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.5bac696455b4ca7733265fd2e6335128@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See also #14883, which is very similar -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 15:33:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 15:33:05 -0000 Subject: [GHC] #10059: :i doesn't work for ~ In-Reply-To: <045.e4d34da19e8a219c9836208516141cc9@haskell.org> References: <045.e4d34da19e8a219c9836208516141cc9@haskell.org> Message-ID: <060.c6a53766b26141504bae76faff914352@haskell.org> #10059: :i doesn't work for ~ -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | ghci/scripts/T10059 Blocked By: | Blocking: Related Tickets: #10056, #12023 | Differential Rev(s): Phab:D4877 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge * testcase: => ghci/scripts/T10059 * milestone: => 8.6.1 Comment: This could be merged to GHC 8.6 if desired. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 17:05:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 17:05:48 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.c43f2e27360623ac31643a673df71d88@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Hm, I've hit a roadblock when trying to switch over to the scheme proposed in comment:5. Consider this code: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# OPTIONS_GHC -ddump-deriv #-} module Bug where import Data.Coerce class C a where c :: Int -> forall b. b -> a instance C Int where c _ _ = 42 newtype Age = MkAge Int -- This is what -- -- deriving instance C Age -- -- would generate: instance C Age where c = coerce @( Int -> forall b. b -> a) c :: forall a. Int -> forall b. b -> a }}} This fails to typecheck: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:26:7: error: • Couldn't match representation of type ‘forall b2. b2 -> a’ with that of ‘b1 -> a’ arising from a use of ‘coerce’ • In the expression: coerce @(Int -> forall b. b -> a) c :: forall a. Int -> forall b. b -> a In an equation for ‘c’: c = coerce @(Int -> forall b. b -> a) c :: forall a. Int -> forall b. b -> a In the instance declaration for ‘C Age’ | 26 | c = coerce @( Int -> forall b. b -> a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} The same error occurs if I use `InstanceSigs`. Any ideas on how to make this work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 17:41:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 17:41:37 -0000 Subject: [GHC] #9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.fec0663c8d5902bb33f7bd1ab6024b73@haskell.org> #9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Roles, Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T9123{,a} Blocked By: 15290 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 Comment: This won't happen for 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 17:42:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 17:42:17 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.ee2d2ed1f43a625dbf4f550456b9e788@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The current behavior was introduced in b612da667fe8fa5277fc78e972a86d4b35f98364 That commit fixes some impredicativity bug but also rewrites GND to use type application. However, the change to GND also has it work with polytypes instead of its previous behavior, using monotypes. It sounds like we want to go to the previous behavior. As for Ryan's question: try passing both type arguments to `coerce`. As explained in the visible type application paper, type signatures on expressions are ''deeply skolemized'', which is causing havoc for you here. I think including the second type parameter to `coerce` will solve the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 17:42:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 17:42:24 -0000 Subject: [GHC] #10059: :i doesn't work for ~ In-Reply-To: <045.e4d34da19e8a219c9836208516141cc9@haskell.org> References: <045.e4d34da19e8a219c9836208516141cc9@haskell.org> Message-ID: <060.792200f199202564d80fb9ce17d4aebd@haskell.org> #10059: :i doesn't work for ~ -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | ghci/scripts/T10059 Blocked By: | Blocking: Related Tickets: #10056, #12023 | Differential Rev(s): Phab:D4877 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This is in 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 17:43:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 17:43:44 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.5b608cf7387c007a1c116938b9ee374f@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059, #10431, | Differential Rev(s): Phab:D4876 #14316 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 Comment: I believe there is more to do here, but it won't happen for 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 17:44:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 17:44:47 -0000 Subject: [GHC] #13205: Run `validate --slow` during CI at least sometimes. In-Reply-To: <047.9b52b4440ebca44d5a2343fbe8a3a428@haskell.org> References: <047.9b52b4440ebca44d5a2343fbe8a3a428@haskell.org> Message-ID: <062.27a149a4a77c29841a39d9a93473339d@haskell.org> #13205: Run `validate --slow` during CI at least sometimes. -------------------------------------+------------------------------------- Reporter: dobenour | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Continuous | Version: 8.0.1 Integration | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14890 | Differential Rev(s): Phab:D4354 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This is now done as of 838aeb9b254efb3df7ed0cedeb945ec7c7789c90. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 17:45:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 17:45:29 -0000 Subject: [GHC] #13240: Make it easier to find builds we may want to cancel In-Reply-To: <045.083696e70698bf335a9cf61ca21cf888@haskell.org> References: <045.083696e70698bf335a9cf61ca21cf888@haskell.org> Message-ID: <060.396f9eda51761dce3bfb7e067e8c9a93@haskell.org> #13240: Make it easier to find builds we may want to cancel -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mpickering Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Trac & Git | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => wontfix Comment: Harbormaster is ultimately going the way of the dinosaur due to CircleCI. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 17:48:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 17:48:19 -0000 Subject: [GHC] #14413: Profiling breaks determinism In-Reply-To: <046.99e30ca5e93737bb465713a1e875ab35@haskell.org> References: <046.99e30ca5e93737bb465713a1e875ab35@haskell.org> Message-ID: <061.4abc5020f52b07bfd01ce72b7756894f@haskell.org> #14413: Profiling breaks determinism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: determinism 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: I believe this was addressed in d8e47a2ea89dbce647b06132ec10c39a2de67437. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 17:51:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 17:51:16 -0000 Subject: [GHC] Batch modify: #13072, #13078, #13090, #13091, #13092, #13093, ... In-Reply-To: <174.e073816a43f2b3a5506b3db735fe0484@haskell.org> References: <174.e073816a43f2b3a5506b3db735fe0484@haskell.org> Message-ID: <189.7b555459819fa0617f64df836cb65595@haskell.org> Batch modification to #13072, #13078, #13090, #13091, #13092, #13093, #13152, #13153, #13154, #13176, #13189, #13225, #13226, #13243, #13253, #13309, #13331, #13346, #13357, #13360, #13363, #13390, #13406 by bgamari: milestone to 8.6.1 Comment: This will not be addressed in GHC 8.6. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 17:53:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 17:53:57 -0000 Subject: [GHC] #13724: Clamping of llvm llc to -O1 and -O2 In-Reply-To: <047.d48b0e89728a8ea310f720588810c39a@haskell.org> References: <047.d48b0e89728a8ea310f720588810c39a@haskell.org> Message-ID: <062.1d571f1a0abceb9c0258944ced084f57@haskell.org> #13724: Clamping of llvm llc to -O1 and -O2 -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (LLVM) | 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): I believe this can be addressed in a way similar to the approach in Phab:D4421. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 17:54:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 17:54:24 -0000 Subject: [GHC] Batch modify: #13072, #13078, #13090, #13091, #13092, #13093, ... In-Reply-To: <276.c305a99562a7fd4c2d165022fea92255@haskell.org> References: <276.c305a99562a7fd4c2d165022fea92255@haskell.org> Message-ID: <291.bc7a5d3f95255294bb69a10ae3e57b0f@haskell.org> Batch modification to #13072, #13078, #13090, #13091, #13092, #13093, #13152, #13153, #13154, #13176, #13189, #13225, #13226, #13243, #13253, #13309, #13331, #13346, #13357, #13360, #13363, #13390, #13406, #13423, #13448, #13465, #13507, #13511, #13513, #13515, #13554, #13564, #13617, #13629, #13647, #13686, #13692, #13693, #13717, #13753 by bgamari: milestone to 8.8.1 Comment: These will not be addressed in GHC 8.6. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 17:58:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 17:58:03 -0000 Subject: [GHC] Batch modify: #13723, #13896, #13898, #13905, #13906, #13981, ... In-Reply-To: <150.e3228907e2126db8b8e8db024d527ae6@haskell.org> References: <150.e3228907e2126db8b8e8db024d527ae6@haskell.org> Message-ID: <165.b2557901089f7f37fad7ec85a6d3c534@haskell.org> Batch modification to #13723, #13896, #13898, #13905, #13906, #13981, #14003, #14030, #14040, #14155, #14165, #14190, #14214, #14242, #14252, #14261, #14268, #14283, #14298 by bgamari: milestone to 8.8.1 Comment: These won't be addressed by GHC 8.6. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 17:59:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 17:59:49 -0000 Subject: [GHC] #14319: Stuck type families can lead to lousy error messages In-Reply-To: <045.325a1c439073c01e464a5d95796bd31d@haskell.org> References: <045.325a1c439073c01e464a5d95796bd31d@haskell.org> Message-ID: <060.b288a00921877ba0dc15e13634ab71fa@haskell.org> #14319: Stuck type families can lead to lousy error messages -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.3 checker) | Keywords: TypeInType, Resolution: | 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 bgamari): * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 18:00:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 18:00:45 -0000 Subject: [GHC] Batch modify: #14319, #14331, #14336, #14337, #14400, #14469, ... In-Reply-To: <090.5506abf0c04e59e0302f4448d6005616@haskell.org> References: <090.5506abf0c04e59e0302f4448d6005616@haskell.org> Message-ID: <105.9d36e95fb220d366d242d72fa6486142@haskell.org> Batch modification to #14319, #14331, #14336, #14337, #14400, #14469, #14482, #14502, #14509 by bgamari: milestone to 8.8.1 Comment: These won't be addressed in GHC 8.6. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 18:02:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 18:02:05 -0000 Subject: [GHC] Batch modify: #14512, #14529, #14551, #14602, #14604, #14610 In-Reply-To: <072.d419c03ba7769b979b773c0914bef14f@haskell.org> References: <072.d419c03ba7769b979b773c0914bef14f@haskell.org> Message-ID: <087.f70e92ac33814f793f3853e888121dca@haskell.org> Batch modification to #14512, #14529, #14551, #14602, #14604, #14610 by bgamari: milestone to 8.8.1 Comment: These won't be addressed in GHC 8.6. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 18:02:58 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 18:02:58 -0000 Subject: [GHC] #14617: Join point test join001 doesn't seem to be properly automated In-Reply-To: <045.8df871e2e6ed60aeb57e9e867858e89d@haskell.org> References: <045.8df871e2e6ed60aeb57e9e867858e89d@haskell.org> Message-ID: <060.f04cdbecdf511c1c9d55c40e9931bcbc@haskell.org> #14617: Join point test join001 doesn't seem to be properly automated -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Test Suite | Version: 8.2.2 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 bgamari): * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 18:05:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 18:05:46 -0000 Subject: [GHC] Batch modify: #14684, #14727, #14765, #14806, #14816, #14823, ... In-Reply-To: <126.a1e852393c0e201d8f328ad6242e47c9@haskell.org> References: <126.a1e852393c0e201d8f328ad6242e47c9@haskell.org> Message-ID: <141.dc2f9e1af9895478d29439784b78a2aa@haskell.org> Batch modification to #14684, #14727, #14765, #14806, #14816, #14823, #14838, #14839, #14870, #14909, #14911, #14973, #15007, #15010, #15011 by bgamari: milestone to 8.8.1 Comment: These won't be addressed in GHC 8.6. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 18:06:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 18:06:47 -0000 Subject: [GHC] #14673: Unary Unboxed Tuple Type Constructor In-Reply-To: <049.d9c870f0c2ef1490b284fbb19f566786@haskell.org> References: <049.d9c870f0c2ef1490b284fbb19f566786@haskell.org> Message-ID: <064.a8d09887adc06b743080668672889918@haskell.org> #14673: Unary Unboxed Tuple Type Constructor -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.1-alpha1 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): * milestone: 8.6.1 => 8.8.1 Comment: This won't be addressed in GHC 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 18:09:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 18:09:08 -0000 Subject: [GHC] #15053: Compiler panic on invalid syntax (unterminated pragma) In-Reply-To: <047.d617a7e8bd5e9dac7c56bae30af4b445@haskell.org> References: <047.d617a7e8bd5e9dac7c56bae30af4b445@haskell.org> Message-ID: <062.24373b2374172cb1a132fefca1ae4180@haskell.org> #15053: Compiler panic on invalid syntax (unterminated pragma) -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (Parser) | 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:D4883 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D4883 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 18:09:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 18:09:55 -0000 Subject: [GHC] Batch modify: #14670, #15019, #15020, #15029, #15034, #15043, ... In-Reply-To: <168.31a1d1e337db917e13a55915b4191410@haskell.org> References: <168.31a1d1e337db917e13a55915b4191410@haskell.org> Message-ID: <183.b63c5978dd01f3a09d9354161fd8164d@haskell.org> Batch modification to #14670, #15019, #15020, #15029, #15034, #15043, #15044, #15048, #15050, #15054, #15069, #15070, #15072, #15074, #15076, #15077, #15078, #15080, #15081, #15087, #15089, #15090 by bgamari: milestone to 8.8.1 Comment: These won't be addressed by GHC 8.6. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 18:11:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 18:11:09 -0000 Subject: [GHC] Batch modify: #15091, #15092, #15096, #15100, #15105, #15106, ... In-Reply-To: <288.eab0a4b3f8689f50ed6c8082ba9ce67b@haskell.org> References: <288.eab0a4b3f8689f50ed6c8082ba9ce67b@haskell.org> Message-ID: <303.7dc6e6c746359aa807239d84366c3196@haskell.org> Batch modification to #15091, #15092, #15096, #15100, #15105, #15106, #15112, #15117, #15124, #15129, #15130, #15135, #15138, #15141, #15147, #15148, #15149, #15153, #15155, #15156, #15165, #15167, #15175, #15177, #15182, #15183, #15184, #15185, #15189, #15190, #15191, #15193, #15194, #15196, #15200, #15201, #15203, #15205, #15206, #15207, #15208, #15211 by bgamari: milestone to 8.8.1 Comment: These won't be addressed for GHC 8.6. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 18:12:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 18:12:26 -0000 Subject: [GHC] #15239: Is there an issue with Haskell GHC 8.4.3 on Travis? In-Reply-To: <044.17aaafc1d49b4b960e98036021c03c2b@haskell.org> References: <044.17aaafc1d49b4b960e98036021c03c2b@haskell.org> Message-ID: <059.8795ba093d0806a3c0923e043464d459@haskell.org> #15239: Is there an issue with Haskell GHC 8.4.3 on Travis? -------------------------------------+------------------------------------- Reporter: Orome | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Assuming this is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 18:13:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 18:13:36 -0000 Subject: [GHC] Batch modify: #15219, #15220, #15221, #15231, #15233, #15234, ... In-Reply-To: <174.74b0dfcfb904719b3bee17bf43301321@haskell.org> References: <174.74b0dfcfb904719b3bee17bf43301321@haskell.org> Message-ID: <189.1036c3a8ae768cfcdb5c144049ef49ee@haskell.org> Batch modification to #15219, #15220, #15221, #15231, #15233, #15234, #15235, #15239, #15245, #15246, #15247, #15248, #15249, #15250, #15251, #15252, #15257, #15258, #15261, #15262, #15263, #15270, #15271 by bgamari: milestone to 8.8.1 Comment: These won't be addressed in GHC 8.6. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 18:14:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 18:14:34 -0000 Subject: [GHC] Batch modify: #15253, #15260, #15273, #15283, #15288, #15291, ... In-Reply-To: <090.ef208b979a3a39bcce24829032298138@haskell.org> References: <090.ef208b979a3a39bcce24829032298138@haskell.org> Message-ID: <105.7f926863d37a4773fd769a1cb9e77fc2@haskell.org> Batch modification to #15253, #15260, #15273, #15283, #15288, #15291, #15292, #15296, #15297 by bgamari: milestone to 8.8.1 Comment: These won't be addressed in GHC 8.6. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 18:15:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 18:15:05 -0000 Subject: [GHC] #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs In-Reply-To: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> References: <046.d67fe0f29d3ab9719210cf02d0142851@haskell.org> Message-ID: <061.b5c715b53379ec0af449f51cc34831f5@haskell.org> #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs -------------------------------------+------------------------------------- Reporter: clemens | Owner: thoughtpolice Type: task | Status: new Priority: low | Milestone: 8.8.1 Component: Compiler (NCG) | Version: 6.11 Resolution: | Keywords: codegen 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.6.1 => 8.8.1 Comment: We won't be don't this in 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 18:15:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 18:15:23 -0000 Subject: [GHC] #11958: Improved testing of cross-compiler In-Reply-To: <044.199977cda1889326e5e53eb484e40895@haskell.org> References: <044.199977cda1889326e5e53eb484e40895@haskell.org> Message-ID: <059.aafc28c177d1581ca85b81546fd0bdb6@haskell.org> #11958: Improved testing of cross-compiler -------------------------------------+------------------------------------- Reporter: erikd | Owner: bgamari Type: task | Status: new Priority: low | Milestone: 8.8.1 Component: Continuous | Version: 7.10.3 Integration | 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): * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 18:15:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 18:15:56 -0000 Subject: [GHC] #15218: HEAD doesn't build without sphinx-build In-Reply-To: <042.48e52db875cf86898104c8cf24945fa7@haskell.org> References: <042.48e52db875cf86898104c8cf24945fa7@haskell.org> Message-ID: <057.bd85f276c500e41d58b24db22d5419e9@haskell.org> #15218: HEAD doesn't build without sphinx-build -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.6.1 Component: Build System | Version: 8.4.3 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Indeed that testsuite failure should now be resolved as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 18:16:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 18:16:33 -0000 Subject: [GHC] #11764: ghc internal error building llvm-general-3.5.1.2 In-Reply-To: <049.1e7850c7fbe53a08db3314e9a97a33fc@haskell.org> References: <049.1e7850c7fbe53a08db3314e9a97a33fc@haskell.org> Message-ID: <064.5ac3c9d260c56792c529e9efe8633f70@haskell.org> #11764: ghc internal error building llvm-general-3.5.1.2 -------------------------------------+------------------------------------- Reporter: andrew.wja | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: cabal install | llvm-general Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: dfeuer => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 18:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 18:21:06 -0000 Subject: [GHC] #15245: Data family promotion is possible In-Reply-To: <048.2bfd93318ecc0fe9c70183281e7bf50f@haskell.org> References: <048.2bfd93318ecc0fe9c70183281e7bf50f@haskell.org> Message-ID: <063.6d581e08e59911776469206b07b1ff38@haskell.org> #15245: Data family promotion is possible -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | dependent/should_fail/T15245.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4748 Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): Huh? Isn't the corresponding commit in the ghc-8.6 branch? I think we should set the resolution to "fixed". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 18:56:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 18:56:13 -0000 Subject: [GHC] #15298: Support spliced function names in type signatures in TH declaration quotes Message-ID: <043.1a4a2d0311f0e64366ade2762ccca9ea@haskell.org> #15298: Support spliced function names in type signatures in TH declaration quotes -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11129 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There doesn't seem to be a way to splice function names into type signatures in Template Haskell declaration quotes `[d|...|]`. For example, `fDecl1` below does not work. According to [https://stackoverflow.com/a/32279198/470844 this StackOverflow answer], the approach in `fDecl2` below used to work, but it doesn't work with recent GHCs and is much less readable than `fDecl1`. {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH fName :: Name fName = mkName "f" fTy :: TypeQ fTy = [t| Int |] fBody :: ExpQ fBody = [e| 3 |] -- | Not allowed: -- -- @ -- error: -- Invalid type signature: $fName :: ... -- Should be of form :: -- @ -- -- Similarly, using @$(varP fName) :: $fTy@ fails with an analogous -- error. fDecl1 :: DecsQ fDecl1 = [d| $fName :: $fTy $(varP fName) = $fBody |] -- | Not allowed: -- -- @ -- error: -- Splices within declaration brackets not (yet) handled by Template Haskell -- @ fDecl2 :: DecsQ fDecl2 = [d| $((:[]) <$> sigD fName fTy) $(varP fName) = $fBody |] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 18:57:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 18:57:00 -0000 Subject: [GHC] #15298: Support spliced function names in type signatures in TH declaration quotes In-Reply-To: <043.1a4a2d0311f0e64366ade2762ccca9ea@haskell.org> References: <043.1a4a2d0311f0e64366ade2762ccca9ea@haskell.org> Message-ID: <058.f466fb1610e6dc3ef67b76bfb0e988ab@haskell.org> #15298: Support spliced function names in type signatures in TH declaration quotes -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6089 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ntc2): * related: #11129 => #6089 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 19:18:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 19:18:02 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.97cbf8b450daf2200628e6cf1b5d5505@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thanks Richard, that did indeed solve that problem. On the other hand, I seem to have hit an even trickier problem. For context: this is the entirety of my patch at the moment: {{{#!diff diff --git a/compiler/typecheck/TcGenDeriv.hs b/compiler/typecheck/TcGenDeriv.hs index b944520..1f1cba2 100644 --- a/compiler/typecheck/TcGenDeriv.hs +++ b/compiler/typecheck/TcGenDeriv.hs @@ -1668,13 +1668,16 @@ gen_Newtype_binds loc cls inst_tvs inst_tys rhs_ty [] rhs_expr] where Pair from_ty to_ty = mkCoerceClassMethEqn cls inst_tvs inst_tys rhs_ty meth_id + (_, _, from_tau) = tcSplitSigmaTy from_ty + (_, _, to_tau) = tcSplitSigmaTy to_ty meth_RDR = getRdrName meth_id rhs_expr = nlHsVar (getRdrName coerceId) - `nlHsAppType` from_ty - `nlHsAppType` to_ty - `nlHsApp` nlHsVar meth_RDR + `nlHsAppType` from_tau + `nlHsAppType` to_tau + `nlHsApp` nlHsVar meth_RDR + `nlExprWithTySig` to_ty mk_atf_inst :: TyCon -> TcM FamInst mk_atf_inst fam_tc = do }}} i.e., drop the `forall`s from each of the types inside the explicit type applications, and put an explicit type signature (with `forall`s) on the whole expression. Now here's the kicker: if you try that patch on this program: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# OPTIONS_GHC -ddump-deriv #-} module Bug where import Data.Coerce class Foo a where bar :: a -> Maybe b instance Foo Int where bar _ = Nothing newtype Age = MkAge Int deriving Foo }}} Then it no longer typechecks: {{{ $ inplace/bin/ghc-stage2 --interactive ../Bug2.hs GHCi, version 8.7.20180621: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( ../Bug2.hs, interpreted ) ==================== Derived instances ==================== Derived class instances: instance Bug.Foo Bug.Age where Bug.bar = GHC.Prim.coerce @(GHC.Types.Int -> GHC.Maybe.Maybe b_a1AR) @(Bug.Age -> GHC.Maybe.Maybe b_a1AR) Bug.bar :: forall (b_a1AR :: TYPE GHC.Types.LiftedRep). Bug.Age -> GHC.Maybe.Maybe b_a1AR Derived type family instances: ../Bug2.hs:16:12: error: • Couldn't match type ‘b1’ with ‘b’ ‘b1’ is a rigid type variable bound by an expression type signature: forall b1. Age -> Maybe b1 at ../Bug2.hs:16:12-14 ‘b’ is a rigid type variable bound by the type signature for: bar :: forall b. Age -> Maybe b at ../Bug2.hs:16:12-14 Expected type: Age -> Maybe b1 Actual type: Age -> Maybe b • In the expression: coerce @(Int -> Maybe b) @(Age -> Maybe b) bar :: forall (b :: TYPE GHC.Types.LiftedRep). Age -> Maybe b In an equation for ‘bar’: bar = coerce @(Int -> Maybe b) @(Age -> Maybe b) bar :: forall (b :: TYPE GHC.Types.LiftedRep). Age -> Maybe b When typechecking the code for ‘bar’ in a derived instance for ‘Foo Age’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘Foo Age’ • Relevant bindings include bar :: Age -> Maybe b (bound at ../Bug2.hs:16:12) | 16 | deriving Foo | ^^^ }}} For the life of me, I can't figure out why this shouldn't typecheck. What's even stranger, if I take the code that GHC's giving me and paste it back into the source: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# OPTIONS_GHC -ddump-deriv #-} module Bug where import Data.Coerce class Foo a where bar :: a -> Maybe b instance Foo Int where bar _ = Nothing newtype Age = MkAge Int -- deriving Foo instance Foo Age where bar = coerce @(Int -> Maybe b) @(Age -> Maybe b) bar :: forall b. Age -> Maybe b }}} Then it typechecks again! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 19:37:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 19:37:33 -0000 Subject: [GHC] #14298: Let Template Haskell dynamically add something with which to link In-Reply-To: <050.5b84ef44d6dba8c28fe71b17d035f8a7@haskell.org> References: <050.5b84ef44d6dba8c28fe71b17d035f8a7@haskell.org> Message-ID: <065.4e27f607c4bee193596808bcc19704c2@haskell.org> #14298: Let Template Haskell dynamically add something with which to link -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 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:D4064 Wiki Page: | -------------------------------------+------------------------------------- Comment (by harpocrates): Isn't this fixed in ceb914771aece0aa6d87339227ce406c7179d1d1 (which is in GHC 8.6)? I think the ticket can be closed now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 19:51:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 19:51:06 -0000 Subject: [GHC] #15239: Is there an issue with Haskell GHC 8.4.3 on Travis? In-Reply-To: <044.17aaafc1d49b4b960e98036021c03c2b@haskell.org> References: <044.17aaafc1d49b4b960e98036021c03c2b@haskell.org> Message-ID: <059.cd3c7d0ffe002477aeb986fa36d81e0c@haskell.org> #15239: Is there an issue with Haskell GHC 8.4.3 on Travis? -------------------------------------+------------------------------------- Reporter: Orome | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Orome): \Yes. Clearing the Travis cache resolved the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 21:13:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 21:13:49 -0000 Subject: [GHC] #11764: ghc internal error building llvm-general-3.5.1.2 In-Reply-To: <049.1e7850c7fbe53a08db3314e9a97a33fc@haskell.org> References: <049.1e7850c7fbe53a08db3314e9a97a33fc@haskell.org> Message-ID: <064.720b90c1bf3294279bd9031666f6bd74@haskell.org> #11764: ghc internal error building llvm-general-3.5.1.2 -------------------------------------+------------------------------------- Reporter: andrew.wja | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: cabal install | llvm-general Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): Doesn't compile on 8.4.3 either, looks ot be same errors as on 8.4.2 (see above) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 22:10:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 22:10:20 -0000 Subject: [GHC] #15299: GHCi :print produces variables that cause a panic Message-ID: <042.578eecf80127f42516c823183cdbc00f@haskell.org> #15299: GHCi :print produces variables that cause a panic --------------------------------------+------------------------------- Reporter: Omf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- Using ghci installed by Stack, I noted some strange behaviour from the :sprint and :print commands: {{{#!hs λ> xs = [1,2,3] λ> :sprint xs xs = _ λ> head xs 1 λ> :sprint xs xs = _ λ> :print xs xs = (_t1::Num a => [a]) λ> _t1 :6:1: error: • No instance for (Num a) arising from a use of ‘_t1’ • In the expression: _t1 In an equation for ‘it’: it = _t1 λ> :t _t1 :1:1: error: No instance for (Num a) arising from a use of ‘_t1’ λ> :info _t1 _t1 :: Num a => [a] -- Defined in ‘interactive:Ghci3’ λ> _t1 :: [Int] :9:1: error:ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): No skolem info: a_a1rR 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 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I don't really understand the error, or why even the :type command fails, but it appears to be related to the way numeric types are polymorphic until a specific type is forced. Note that the both the :sprint and :print commands don't seem to recognise that we've evaluated any of xs, just printing an underscore no matter what. The panic doesn't happen if I force a type when defining xs: {{{#!hs λ> xs = [1,2,3] :: [Int] λ> :sp xs xs = _ λ> head xs 1 λ> :sp xs xs = 1 : _ λ> :print xs xs = 1 : (_t2::[Int]) λ> _t2 [2,3] λ> :t _t2 _t2 :: [Int] λ> :in _t2 _t2 :: [Int] -- Defined in ‘interactive:Ghci6’ λ> _t2 :: [Integer] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 22:14:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 22:14:01 -0000 Subject: [GHC] #15299: GHCi :print produces variables that cause a panic In-Reply-To: <042.578eecf80127f42516c823183cdbc00f@haskell.org> References: <042.578eecf80127f42516c823183cdbc00f@haskell.org> Message-ID: <057.8ff2b85d204d7f9e542ab90b6712d160@haskell.org> #15299: GHCi :print produces variables that cause a panic -------------------------------+-------------------------------------- Reporter: Omf | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by Omf): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 22:17:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 22:17:47 -0000 Subject: [GHC] #15299: GHCi :print produces variables that cause a panic In-Reply-To: <042.578eecf80127f42516c823183cdbc00f@haskell.org> References: <042.578eecf80127f42516c823183cdbc00f@haskell.org> Message-ID: <057.24189630a0693b26b8d5c237b5a08046@haskell.org> #15299: GHCi :print produces variables that cause a panic -------------------------------+-------------------------------------- Reporter: Omf | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: debugger Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by RyanGlScott): * keywords: => debugger -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 21 22:28:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Jun 2018 22:28:17 -0000 Subject: [GHC] #15299: GHCi :print produces variables that cause a panic In-Reply-To: <042.578eecf80127f42516c823183cdbc00f@haskell.org> References: <042.578eecf80127f42516c823183cdbc00f@haskell.org> Message-ID: <057.0aea9fd300530588b96a04de0c8ac9b5@haskell.org> #15299: GHCi :print produces variables that cause a panic -------------------------------+-------------------------------------- Reporter: Omf | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: debugger Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by Omf): * version: 8.2.2 => 8.4.3 Comment: (tested and experienced the same behaviour in both 8.2.2 and 8.4.3) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 00:18:41 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 00:18:41 -0000 Subject: [GHC] #15262: TH splice containing numeric literal 0 causes heap overflow while cross-compiling In-Reply-To: <050.8f7705015e16ef64b51a5dbaaaac982c@haskell.org> References: <050.8f7705015e16ef64b51a5dbaaaac982c@haskell.org> Message-ID: <065.993d608820b858203180461b695f6837@haskell.org> #15262: TH splice containing numeric literal 0 causes heap overflow while cross- compiling -------------------------------------+------------------------------------- Reporter: howtonotwin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: MacOS X | 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 howtonotwin): Further testing reveals that the issue is simply that the GHC distribution that created the `ghc-iserv` program used `integer-gmp` but the cross- compiler used `integer-simple`. Configuring the non-cross-compiling GHC to use `integer-simple` too fixes this. It would be nice, however, if the error message were more informative. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 00:47:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 00:47:06 -0000 Subject: [GHC] #15300: Unboxed Sums Crash Message-ID: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- I've made it a little further in my experiments with unboxed tuples in the `packed` library. However, I've run into another issue that I strongly suspect is the result of bad behavior of unboxed tuples. To replicate this issue (with GHC 8.4.3), do the following: {{{ git clone https://github.com/andrewthad/packed cd packed cabal new-build }}} We use `cabal new-build` for its side effect of creating a `.ghc.environment.xyz` file. Now, create a minimal example in the directory called `eol.hs` with the following contents: {{{ import Packed.Bytes.Parser (Parser) import Data.Word import Packed.Bytes (Bytes) import GHC.Exts (RealWorld) import Packed.Bytes.Stream.IO (ByteStream) import qualified Packed.Bytes as B import qualified Data.Char import qualified Packed.Bytes.Parser as P import qualified Packed.Bytes.Stream.IO as Stream main :: IO () main = do r <- runExampleParser ( do P.takeBytesUntilEndOfLineConsume P.takeBytesUntilEndOfLineConsume P.takeBytesUntilEndOfLineConsume ) (foldMap Stream.singleton (map charToWord8 "the\nemporium\rhas\narrived")) print r runExampleParser :: Parser e () a -> ByteStream RealWorld -> IO (Maybe a, Maybe String) runExampleParser parser stream = do P.Result mleftovers r _ <- P.parseStreamIO stream () parser mextra <- case mleftovers of Nothing -> return Nothing Just (P.Leftovers chunk remainingStream) -> do bs <- Stream.unpack remainingStream return (Just (map word8ToChar (B.unpack chunk ++ bs))) return (either (const Nothing) Just r,mextra) word8ToChar :: Word8 -> Char word8ToChar = Data.Char.chr . fromIntegral charToWord8 :: Char -> Word8 charToWord8 = fromIntegral . Data.Char.ord s2b :: String -> Bytes s2b = B.pack . map charToWord8 c2w :: Char -> Word8 c2w = charToWord8 }}} Finally, build this with `ghc -O2 eol.hs`, and then run the executable this produces to get the following: {{{ (Nothing,Just "\rhas\narrived") eol: internal error: stg_ap_n_ret (GHC version 8.4.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} Things worth noting: 1. I think the program fails in the final GC that runs right before the program terminates. We can see that it produces a correct result of `(Nothing,Just "\rhas\narrived")`, but something on the heap has definitely been corrupted. 2. This only happens with `-O2` turned on. 3. This only happens when the parser does not successfully parse its input. Here's some more context around this. I've been working on a parser that uses unboxed sums instead of continuations. After #15038 was fixed, everything had been going well. Then, I took the parser type and added two things to it: (1) context and (2) typed errors. Context is basically like throwing `StateT` on top and errors are like throwing `ExceptT` on top. After this, everything in my test suite kept working except for a single test, which now consistently crashes my test suite. So, I originally had this: {{{ type Bytes# = (# ByteArray#, Int#, Int# #) type Maybe# (a :: TYPE r) = (# (# #) | a #) type Leftovers# s = (# Bytes# , ByteStream s #) type Result# s (r :: RuntimeRep) (a :: TYPE r) = (# Maybe# (Leftovers# s), Maybe# a #) newtype ParserLevity (r :: RuntimeRep) (a :: TYPE r) = ParserLevity { getParserLevity :: forall s. Maybe# (Leftovers# s) -> State# s -> (# State# s, Result# s r a #) } }}} But I changed it to this: {{{ type Bytes# = (# ByteArray#, Int#, Int# #) type Maybe# (a :: TYPE r) = (# (# #) | a #) type Either# a (b :: TYPE r) = (# a | b #) type Leftovers# s = (# Bytes# , ByteStream s #) type Result# e c s (r :: RuntimeRep) (a :: TYPE r) = (# Maybe# (Leftovers# s), Either# (Maybe e) a, c #) newtype ParserLevity e c (r :: RuntimeRep) (a :: TYPE r) = ParserLevity { getParserLevity :: forall s. c -> Maybe# (Leftovers# s) -> State# s -> (# State# s, Result# e c s r a #) } }}} Specifically, the function causing trouble is (as currently defined): {{{ {-# NOINLINE takeBytesUntilEndOfLineConsumeUnboxed #-} takeBytesUntilEndOfLineConsumeUnboxed :: ParserLevity e c BytesRep Bytes# takeBytesUntilEndOfLineConsumeUnboxed = ParserLevity (go (# (# #) | #)) where go :: Maybe# Bytes# -> c -> Maybe# (Leftovers# s) -> State# s -> (# State# s, Result# e c s BytesRep Bytes# #) go !_ c (# (# #) | #) s0 = (# s0, (# (# (# #) | #), (# Nothing | #), c #) #) go !mbytes c (# | (# bytes0@(# arr0, off0, len0 #), !stream0@(ByteStream streamFunc) #) #) s0 = case BAW.findAnyByte2 (I# off0) (I# len0) 10 13 (ByteArray arr0) of Nothing -> case streamFunc s0 of (# s1, r #) -> go (# | appendMaybeBytes mbytes bytes0 #) c r s1 Just (I# ix, W8# theByte) -> case theByte of 10## -> (# s0, (# (# | (# unsafeDrop# ((ix -# off0) +# 1# ) bytes0, stream0 #) #), (# | appendMaybeBytes mbytes (# arr0, off0, ix -# off0 #) #), c #) #) -- second case means it was 13 _ -> case ix <# (off0 +# len0 -# 1#) of 1# -> case indexWord8Array# arr0 (ix +# 1# ) of 10## -> (# s0, (# (# | (# unsafeDrop# ((ix -# off0) +# 2# ) bytes0, stream0 #) #), (# | appendMaybeBytes mbytes (# arr0, off0, ix -# off0 #) #), c #) #) _ -> (# s0, (# (# | (# unsafeDrop# (ix -# off0) bytes0, stream0 #) #), (# Nothing | #), c #) #) _ -> case nextNonEmpty stream0 s0 of (# s1, m #) -> case m of (# (# #) | #) -> (# s1, (# (# | (# unboxBytes (B.singleton 13), Stream.empty #) #), (# Nothing | #), c #) #) (# | (# bytes1@(# arr1, _, _ #), stream1 #) #) -> case indexWord8Array# arr1 0# of 10## -> (# s1, (# (# | (# unsafeDrop# 1# bytes1, stream1 #) #), (# | appendMaybeBytes mbytes (# arr0, off0, ix -# off0 #) #), c #) #) _ -> (# s1, (# (# | (# unboxBytes (B.cons 13 (boxBytes bytes1)), stream1 #) #), (# Nothing | #), c #) #) }}} That's all I've got for now. If no one's able to make headway, I'll probably come back to this and try to make a more minimal example at some point. I won't have time to do this soon though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 01:02:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 01:02:14 -0000 Subject: [GHC] #15245: Data family promotion is possible In-Reply-To: <048.2bfd93318ecc0fe9c70183281e7bf50f@haskell.org> References: <048.2bfd93318ecc0fe9c70183281e7bf50f@haskell.org> Message-ID: <063.fd24915f03cb96a8808ff35953a248b4@haskell.org> #15245: Data family promotion is possible -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | dependent/should_fail/T15245.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4748 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: 8.8.1 => 8.6.1 Comment: Indeed; oversight on my part. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 07:18:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 07:18:47 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.1c1ac50702780b0e9d8f65387defcb39@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: | -------------------------------------+------------------------------------- Comment (by osa1): Thanks for reporting. I managed to reproduce this with GHC HEAD. > I think the program fails in the final GC that runs right before the program > terminates. We can see that it produces a correct result of (Nothing,Just > "\rhas\narrived"), but something on the heap has definitely been corrupted. This program does not do any GC at all. Try this: {{{ $ gdb --args ./eol Reading symbols from ./eol...done. >>> break GarbageCollect Breakpoint 1 at 0x8b3ca7: file rts/sm/GC.c, line 224. >>> r }}} you'll see that the breakpoint is never triggered. So this is definitely a code generation bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 07:19:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 07:19:16 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.fbce85766eb805b86be0e791a1de6cb6@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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 osa1): * version: 8.4.3 => 8.5 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 07:19:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 07:19:26 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.f9fead9eced46cdcdd21ae9c7da6285d@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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 osa1): * type: task => bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 07:28:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 07:28:04 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.6e46ceec90955455a25a356162bce633@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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: | -------------------------------------+------------------------------------- Comment (by osa1): Both the library and the program passes Core, Stg and Cmm lints. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 11:35:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 11:35:04 -0000 Subject: [GHC] #15301: Regression in Natural desugaring Message-ID: <045.90c91b42b96252b83bfe60ec247894bd@haskell.org> #15301: Regression in Natural desugaring -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- My recent merged patch "Built-in Natural literals in Core" https://phabricator.haskell.org/rGHCfe770c211631e7b4c9b0b1e88ef9b6046c6585ef introduced a regression when desugaring large numbers. Patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 11:38:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 11:38:27 -0000 Subject: [GHC] #15301: Regression in Natural desugaring In-Reply-To: <045.90c91b42b96252b83bfe60ec247894bd@haskell.org> References: <045.90c91b42b96252b83bfe60ec247894bd@haskell.org> Message-ID: <060.f5b0413824c108dca548ac1b0f3f387b@haskell.org> #15301: Regression in Natural desugaring -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4885 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => patch * differential: => Phab:D4885 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 11:56:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 11:56:14 -0000 Subject: [GHC] #14883: QuantifiedConstraints don't kick in when used in TypeApplications In-Reply-To: <050.9ae7dfd18c1aed745c56cdebbc78f3e8@haskell.org> References: <050.9ae7dfd18c1aed745c56cdebbc78f3e8@haskell.org> Message-ID: <065.74ca5d63537e11e04ee0d93d405f454b@haskell.org> #14883: QuantifiedConstraints don't kick in when used in TypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 15290 | Blocking: Related Tickets: #15290 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > implementing the deriving change in #15290 should make this whole issue moot. Hurrah! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 12:06:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 12:06:58 -0000 Subject: [GHC] #9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.ec570dcda4a60f6d111bf3195a1bdb68@haskell.org> #9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Roles, Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T9123{,a} Blocked By: 15290 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > If we wanted to do this (and I'm waiting for Simon to say that we don't) I don't! It's pretty much always possible to take all the constraints needed for the constructors to typecheck, and spit them out as the instance context. Bingo - the instance typechecks. But we don't always want to do that. E.g. If we need `Int ~ Bool` we probably don't want to quantify over that. In fact GHC is pretty conservative: `Note [Exotic derived instance contexts]` in `TcDerivInfer`. One could make it less conservative provided you still obeyed the termination conditions. Generally we are pretty conservative, even for ordinary functions in `tcSimplifyInfer`, where we have no termination conditions to worry about. See `pickQuantifiablePreds` in `TcType`. We don't even ''try'' to quantify over a quantified constraint. Before quantifying over quantified constraints in instances, we should consider it for the simpler case of ordinary functions. And I frankly doubt it'll be feasible in practice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 12:11:30 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 12:11:30 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.2d36936519d976ebe4cb4b2c304b5b0d@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"32eb41994f7448caf5fb6b06ed0678d79d029deb/ghc" 32eb419/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="32eb41994f7448caf5fb6b06ed0678d79d029deb" Instances in no-evidence implications Trac #15290 showed that it's possible that we might attempt to use a quantified constraint to solve an equality in a situation where we don't have anywhere to put the evidence bindings. This made GHC crash. This patch stops the crash, but still rejects the pogram. See Note [Instances in no-evidence implications] in TcInteract. Finding this bug revealed another lurking bug: * An infelicity in the treatment of superclasses -- we were expanding them locally at the leaves, rather than at their binding site; see (3a) in Note [The superclass story]. As a consequence, TcRnTypes.superclassesMightHelp must look inside implications. In more detail: * Stop the crash, by making TcInteract.chooseInstance test for the no-evidence-bindings case. In that case we simply don't use the instance. This entailed a slight change to the type of chooseInstance. * Make TcSMonad.getPendingScDicts (now renamed getPendingGivenScs) return only Givens from the /current level/; and make TcRnTypes.superClassesMightHelp look inside implications. * Refactor the simpl_loop and superclass-expansion stuff in TcSimplify. The logic is much easier to understand now, and has less duplication. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 12:18:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 12:18:00 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.381d01dd2d18a820cde04acdc9219af9@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15290, T15290a Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => quantified-constraints/T15290, T15290a -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 15:12:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 15:12:23 -0000 Subject: [GHC] #12769: ghc: internal error: stg_ap_pp_ret In-Reply-To: <045.3906df0b47185ed07f8c39e1db59841e@haskell.org> References: <045.3906df0b47185ed07f8c39e1db59841e@haskell.org> Message-ID: <060.a305abf0ebc458bd84c9a8eb136566cd@haskell.org> #12769: ghc: internal error: stg_ap_pp_ret ----------------------------------+---------------------------------------- Reporter: kinnla | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed Comment: Closing this due to not activity for a long time. Presuming the problem was fixed for the user. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 15:13:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 15:13:22 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.b7266441329b88548da41440b113074c@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15290, T15290a Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To make things more outrageous, if I manually freshen the type variable binders in `to_ty` in comment:17 (using `freshTyVarBndrs`), //then// it works. Quite mysterious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 15:17:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 15:17:14 -0000 Subject: [GHC] #15302: TTG for IPBind wrong extension name Message-ID: <044.6aedb86c3fb3b3deb8c5cd1f95b1006a@haskell.org> #15302: TTG for IPBind wrong extension name -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: ttg | 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 standard[1] for extension naming is to use the `XC` prefix for the internal extension points, rather than for a new constructor. This is violated for `IPBind`, having {{{#!hs data IPBind id = IPBind (XIPBind id) (Either (Located HsIPName) (IdP id)) (LHsExpr id) | XCIPBind (XXIPBind id) }}} Swap the usage of `XIPBind` and `XCIPBind` [1] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow#Namingconventions -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 15:17:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 15:17:28 -0000 Subject: [GHC] #15302: TTG for IPBind wrong extension name In-Reply-To: <044.6aedb86c3fb3b3deb8c5cd1f95b1006a@haskell.org> References: <044.6aedb86c3fb3b3deb8c5cd1f95b1006a@haskell.org> Message-ID: <059.fbc50f327ac1cdb2984f608b153a34b0@haskell.org> #15302: TTG for IPBind wrong extension name -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: ttg 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 alanz): * owner: (none) => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 15:34:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 15:34:34 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.82e844be9017dc13801f48a80ebf153b@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15290, T15290a Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm on it. Digging through manure in `TcHsType`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 15:40:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 15:40:15 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.092d4df3e84bdc2a85594bb608ed6a0d@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15290, T15290a Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): On the subject of the actual panic observed in this ticket, I don't think Simon's commit quite fixed it. I'm still observing the panic on commit 122ba98af22c2b016561433dfa55bbabba98d972 with this program (taken from #14883): {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} module Bug where import Data.Coerce import Data.Kind type Representational1 m = (forall a b. Coercible a b => Coercible (m a) (m b) :: Constraint) class Representational1 f => Functor' f where fmap' :: (a -> b) -> f a -> f b class Functor' f => Applicative' f where pure' :: a -> f a (<*>@) :: f (a -> b) -> f a -> f b class Functor' t => Traversable' t where traverse' :: Applicative' f => (a -> f b) -> t a -> f (t b) -- Typechecks newtype T1 m a = MkT1 (m a) deriving (Functor', Traversable') }}} {{{ $ ghc/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20180621 for x86_64-unknown-linux): addTcEvBind NoEvBindsVar [G] df_a1bF = \ (@ a_asM) (@ b_asN) (v_B1 :: Coercible a_asM b_asN) -> coercible_sel @ * @ (m_a1bn[sk:1] a_asM) @ (m_a1bn[sk:1] b_asN) (df_a1bE @ a_asM @ b_asN v_B1) a1bw Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcRnMonad.hs:1404:5 in ghc:TcRnMonad }}} The panic does not occur if I derive `Traversable'` through `StandaloneDeriving`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 16:20:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 16:20:11 -0000 Subject: [GHC] #14926: failed to build cross-compiler In-Reply-To: <047.7e41252e6edebe6a23db1a7997fb158e@haskell.org> References: <047.7e41252e6edebe6a23db1a7997fb158e@haskell.org> Message-ID: <062.fe5843168d4f81ff8e1a67d16b4e78e0@haskell.org> #14926: failed to build cross-compiler -------------------------------------+------------------------------------- Reporter: rueshyna | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by denisshevchenko): I have exactly the same error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 17:30:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 17:30:23 -0000 Subject: [GHC] #15282: Document how equality-bearing constructors are promoted in Core In-Reply-To: <050.090e2292f6620e97635bea0372f57c50@haskell.org> References: <050.090e2292f6620e97635bea0372f57c50@haskell.org> Message-ID: <065.8b9e3050989149f6bfadd548b3210d9e@haskell.org> #15282: Document how equality-bearing constructors are promoted in Core -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14845 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: merge => closed * resolution: => fixed * milestone: 8.8.1 => 8.6.1 Comment: This is in GHC 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 19:35:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 19:35:25 -0000 Subject: [GHC] #15302: TTG for IPBind wrong extension name In-Reply-To: <044.6aedb86c3fb3b3deb8c5cd1f95b1006a@haskell.org> References: <044.6aedb86c3fb3b3deb8c5cd1f95b1006a@haskell.org> Message-ID: <059.9b24ee14efc83cb055cb7a5a376a541c@haskell.org> #15302: TTG for IPBind wrong extension name -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: ttg 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 Alan Zimmerman ): In [changeset:"5f06cf6b6199c8f0e4921f4126f6eb15e2ff18ac/ghc" 5f06cf6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5f06cf6b6199c8f0e4921f4126f6eb15e2ff18ac" TTG for IPBind had wrong extension name The standard[1] for extension naming is to use the XC prefix for the internal extension points, rather than for a new constructor. This is violated for IPBind, having data IPBind id = IPBind (XIPBind id) (Either (Located HsIPName) (IdP id)) (LHsExpr id) | XCIPBind (XXIPBind id) Swap the usage of XIPBind and XCIPBind [1] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow#Namingconventions Closes #15302 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 19:59:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 19:59:43 -0000 Subject: [GHC] #15292: ghc_ticker loops if permission denied on timerfd In-Reply-To: <065.2e3eba2da7777347cf476e1f6c4c64cc@haskell.org> References: <065.2e3eba2da7777347cf476e1f6c4c64cc@haskell.org> Message-ID: <080.5f808189aef49aab5dfae08639034377@haskell.org> #15292: ghc_ticker loops if permission denied on timerfd ------------------------------------+-------------------------------------- Reporter: jon.fairbairn@… | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4875 Wiki Page: | ------------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"c7b1e93b47915a5276dfdb04f09030f5abaed290/ghc" c7b1e93/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c7b1e93b47915a5276dfdb04f09030f5abaed290" rts: Abort if timerfd read fails Currently we belch some output to stderr but fail to abort, resulting in a busy loop. Fixes #15292. Test Plan: * Validate * try running program under environment without timerfd capabilities; ensure we don't busy-loop Reviewers: simonmar, erikd Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15929 Differential Revision: https://phabricator.haskell.org/D4875 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 19:59:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 19:59:58 -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.915ce37887b7b097b41b275515c7334a@haskell.org> #14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: SantiM Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Runtime System | Version: 8.0.1 (Linker) | 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:D4817 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"67c422ca0e7b94e021430e3dfc9b19f3de21ed16/ghc" 67c422c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="67c422ca0e7b94e021430e3dfc9b19f3de21ed16" rts/linker/{SymbolExtras,elf_got}.c: map code as read-only protect mmaped addresses from writes after being initially manipulated Test Plan: ./validate Reviewers: bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: angerman, carlostome, rwbarton, thomie, carter GHC Trac Issues: #14069 Differential Revision: https://phabricator.haskell.org/D4817 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 20:00:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 20:00:13 -0000 Subject: [GHC] #11477: Remove -Wamp In-Reply-To: <046.3dbac51dca4bf042073a762ce7d4fafd@haskell.org> References: <046.3dbac51dca4bf042073a762ce7d4fafd@haskell.org> Message-ID: <061.6b2b0e369f8836861e0cd338cf280326@haskell.org> #11477: Remove -Wamp -------------------------------------+------------------------------------- Reporter: bgamari | Owner: RolandSenn Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D4785 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"33724fc75499a3dfaf2ffcc4bf5db6d505df58f4/ghc" 33724fc7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="33724fc75499a3dfaf2ffcc4bf5db6d505df58f4" Remove -Wamp flag Test Plan: "ghc -Wamp XXX.hs" should give "unrecognised warning flag" Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #11477 Differential Revision: https://phabricator.haskell.org/D4785 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 22 23:04:08 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Jun 2018 23:04:08 -0000 Subject: [GHC] #15250: Add support for _mm512_shuffle_epi8 intrinsic In-Reply-To: <047.fda88db89169ce07c0e87baa9a0daf82@haskell.org> References: <047.fda88db89169ce07c0e87baa9a0daf82@haskell.org> Message-ID: <062.95bb9c431ad07ade0130bede3a0d3edb@haskell.org> #15250: Add support for _mm512_shuffle_epi8 intrinsic -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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 carter): repeating my remark from phab: hrmmm, i suspect the AVX512 stuff may not be terrible performant / some / many intel CPUS in consumer / dev machine hands wont support them, have you tested using it via C FFI for your inner loops first? This is definitely an example of an instruction where the shuffle data can be at runtime, i'd suggest first making sure an inner loop / subroutine in C has satisfactory perf first. Whats the context driving this effort? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 23 03:16:59 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jun 2018 03:16:59 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.88e040e91ccca62af46fde68a8fe6622@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15290, T15290a Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:21 simonpj]: > I'm on it. Digging through manure in `TcHsType`. Presumably mine. What's up this time? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 23 07:04:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jun 2018 07:04:12 -0000 Subject: [GHC] #15303: API Annotations lost when parsing tyapp Message-ID: <044.1aa714aa9f40d3b728af19a48aa49408@haskell.org> #15303: API Annotations lost when parsing tyapp -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In `Parser.y`, the `typapp` production has {{{#!hs | SIMPLEQUOTE qconop {% ams (sLL $1 $> $ TyElOpr (unLoc $2)) [mj AnnSimpleQuote $1] } | SIMPLEQUOTE varop {% ams (sLL $1 $> $ TyElOpr (unLoc $2)) [mj AnnSimpleQuote $1] } }}} By using `unLoc $2` we are discarding any annotations attached to the `qconop` or `qvarop`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 23 07:04:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jun 2018 07:04:32 -0000 Subject: [GHC] #15303: API Annotations lost when parsing tyapp In-Reply-To: <044.1aa714aa9f40d3b728af19a48aa49408@haskell.org> References: <044.1aa714aa9f40d3b728af19a48aa49408@haskell.org> Message-ID: <059.30dd4a1d2670b50a40f40eeb98ab5ef7@haskell.org> #15303: API Annotations lost when parsing tyapp -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | 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 Jun 23 10:14:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jun 2018 10:14:29 -0000 Subject: [GHC] #15250: Add support for _mm512_shuffle_epi8 intrinsic In-Reply-To: <047.fda88db89169ce07c0e87baa9a0daf82@haskell.org> References: <047.fda88db89169ce07c0e87baa9a0daf82@haskell.org> Message-ID: <062.1ab5af6262920670c39f10ebe16e45dd@haskell.org> #15250: Add support for _mm512_shuffle_epi8 intrinsic -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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 newhoggy): Yes, I've recently discovered that my laptop does not have AVX512 support, in which case I'd like to have support equivalent for AVX2 instruction _mm256_shuffle_epi8 and _mm_shuffle_epi8 instructions for lower performance, compatibility on such platforms. I will also need to be able to load an unload packed bytes to and from vectors with require some additional primops. The context is that I would like to implement Data Parallel State Machines which have been documented to run 5x faster than state machines without SIMD support, and also open the way to parallelise state machines (that are normally run serially) across multiple cores. https://www.microsoft.com/en-us/research/wp- content/uploads/2016/02/asplos302-mytkowicz.pdf Being able to run state machines with high performance is in itself a worthwhile endeavour, but I would like to investigate the possibility of using this to build very fast JSON, XML and CSV parsers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 23 10:17:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jun 2018 10:17:58 -0000 Subject: [GHC] #15250: Add support for _mm512_shuffle_epi8 intrinsic In-Reply-To: <047.fda88db89169ce07c0e87baa9a0daf82@haskell.org> References: <047.fda88db89169ce07c0e87baa9a0daf82@haskell.org> Message-ID: <062.4d252f9d544b987f77a519b747eaa5b3@haskell.org> #15250: Add support for _mm512_shuffle_epi8 intrinsic -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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 newhoggy): I was recently inspired by a talk by Gabriel Gonzalez on this topic: http://www.youtube.com/watch?v=b4bb8EP_pIE -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 23 13:30:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jun 2018 13:30:57 -0000 Subject: [GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 Message-ID: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I am the author of the cl3 library on Hackage. I have noticed a huge increase of compile time and memory use when testing 8.2.2 and 8.4.2. ghc-8.0.2 compiled in 4:17.33 using 3.5 GB. ghc-8.2.2 compiled in 26:40.15 using 32.8 GB. This is an increase of 6x in time and 9x in memory. This is not all bad, my nbody benchmark has improved about 35% between ghc-8.0.2 and ghc-8.4.2 so the increased compilation time and memory usage are producing much better runtime performance. I am interested if you could suggest some workarounds to help others compile on systems with less resources. I have 64GB memory in my system and would like to test out some -fno-* GHC Options. Could you point me in the right direction? The library is almost entirely pure functions. I am also interested in other options, like if there are ways to rewrite things to make it easier on the compiler or using NOINLINE on a trouble spot and how to find that trouble spot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 23 15:39:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jun 2018 15:39:05 -0000 Subject: [GHC] #15292: ghc_ticker loops if permission denied on timerfd In-Reply-To: <065.2e3eba2da7777347cf476e1f6c4c64cc@haskell.org> References: <065.2e3eba2da7777347cf476e1f6c4c64cc@haskell.org> Message-ID: <080.e11d0b564ff6273d6c37abc33dc582fd@haskell.org> #15292: ghc_ticker loops if permission denied on timerfd ------------------------------------+-------------------------------------- Reporter: jon.fairbairn@… | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4875 Wiki Page: | ------------------------------------+-------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 23 15:39:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jun 2018 15:39:15 -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.d55334f71b6c475de44a53980859a89d@haskell.org> #14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: SantiM Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Runtime System | Version: 8.0.1 (Linker) | 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:D4817 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 23 15:45:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jun 2018 15:45:16 -0000 Subject: [GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 In-Reply-To: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> References: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> Message-ID: <066.f85bff9500c7beeac52cbcfd7de50668@haskell.org> #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): A quick first thing to do is to run `ghc` with `-v`. It will print statistics about each core-to-core pass (size of the AST, and in recent versions memory consumption), and maybe you can spot one pass where the size of the AST drastically increases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 23 16:53:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jun 2018 16:53:15 -0000 Subject: [GHC] #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation Message-ID: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation -------------------------------------+------------------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the following code, `fun` contains an exhaustive pattern match, but, when compiling with -Wall, ghc erroneously reports a non-exhaustive pattern match. {{{#!hs data (:+:) f g a = Inl !(f a) | Inr !(g a) data A data B data Foo l where Foo :: Foo A data Bar l where Bar :: Bar B type Sig = Foo :+: Bar fun :: Sig B -> Int fun (Inr Bar) = 1 }}} This report came from https://stackoverflow.com/questions/16225281/gadts- failed-exhaustiveness-checking . Without strictness annotations, this is indeed a failed exhaustive check, due to bottom. I spoke to Richard Eisenberg at PLDI a few days ago, and he informed me that, if this warning did not disappear with strictness annotations, it was a bug. I added strictness annotations, and it did not disappear. I've tried all combinations of using strictness annotations and/or running with `{-# LANGUAGE Strict #-}`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 23 16:53:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jun 2018 16:53:34 -0000 Subject: [GHC] #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation In-Reply-To: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> References: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> Message-ID: <061.2f9ea474a6a4c20918fd1c3adde03553@haskell.org> #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation -------------------------------------+------------------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | 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: | -------------------------------------+------------------------------------- Changes (by jkoppel): * Attachment "Main.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 23 17:36:41 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jun 2018 17:36:41 -0000 Subject: [GHC] #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation In-Reply-To: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> References: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> Message-ID: <061.049d842085817053df047238b956118e@haskell.org> #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation -------------------------------------+------------------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: Resolution: | PatternMatchWarnings 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): * keywords: => PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 23 21:29:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jun 2018 21:29:58 -0000 Subject: [GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 In-Reply-To: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> References: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> Message-ID: <066.b78bb2f7f613c9ce6068cb27c04113d8@haskell.org> #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by NathanWaivio): * Attachment "ghc-8.2.2-v.txt" added. verbose output of ghc-8.2.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 23 21:47:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Jun 2018 21:47:08 -0000 Subject: [GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 In-Reply-To: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> References: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> Message-ID: <066.78e2174ffd965b43aeee47cc062c225f@haskell.org> #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NathanWaivio): All of the numbers look pretty big to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 24 08:04:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jun 2018 08:04:08 -0000 Subject: [GHC] #15306: First attempt at starting GHCI failed Message-ID: <044.bb0e20f9b63de8ba8466a48783a5351a@haskell.org> #15306: First attempt at starting GHCI failed -------------------------------------+------------------------------------- Reporter: DaleB | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- PS C:\WINDOWS\system32> ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help ghc.exe: C:\F\G77\lib\libmingw32.a: Not a x86_64 PE+ file. ghc.exe: getNumberOfSymbols: error whilst reading `CRTglob.o' header in `C:\F\G77\lib\libmingw32.a': Unknown COFF_OBJ_TYPE. ghc.exe: loadArchive: error whilst reading `C:\F\G77\lib\libmingw32.a' ghc.exe: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-mingw32): loadArchive "C:\\F\\G77\\lib\\libmingw32.a": failed 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 Sun Jun 24 10:14:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jun 2018 10:14:38 -0000 Subject: [GHC] #15306: First attempt at starting GHCI failed In-Reply-To: <044.bb0e20f9b63de8ba8466a48783a5351a@haskell.org> References: <044.bb0e20f9b63de8ba8466a48783a5351a@haskell.org> Message-ID: <059.1e48b1ebc8f1bd076020ea668cd75837@haskell.org> #15306: First attempt at starting GHCI failed -------------------------------------+------------------------------------- Reporter: DaleB | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * failure: None/Unknown => Runtime crash * os: Unknown/Multiple => Windows * component: Compiler => Runtime System (Linker) Old description: > PS C:\WINDOWS\system32> ghci > GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help > ghc.exe: C:\F\G77\lib\libmingw32.a: Not a x86_64 PE+ file. > ghc.exe: getNumberOfSymbols: error whilst reading `CRTglob.o' header in > `C:\F\G77\lib\libmingw32.a': Unknown COFF_OBJ_TYPE. > ghc.exe: loadArchive: error whilst reading `C:\F\G77\lib\libmingw32.a' > ghc.exe: panic! (the 'impossible' happened) > (GHC version 8.4.3 for x86_64-unknown-mingw32): > loadArchive "C:\\F\\G77\\lib\\libmingw32.a": failed > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug New description: {{{ PS C:\WINDOWS\system32> ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help ghc.exe: C:\F\G77\lib\libmingw32.a: Not a x86_64 PE+ file. ghc.exe: getNumberOfSymbols: error whilst reading `CRTglob.o' header in `C:\F\G77\lib\libmingw32.a': Unknown COFF_OBJ_TYPE. ghc.exe: loadArchive: error whilst reading `C:\F\G77\lib\libmingw32.a' ghc.exe: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-mingw32): loadArchive "C:\\F\\G77\\lib\\libmingw32.a": failed 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 Sun Jun 24 11:39:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jun 2018 11:39:01 -0000 Subject: [GHC] #15307: Incorrect -ddump-deriv parenthesization for GND'd fmap implementation Message-ID: <050.5a1160e153a31f1bbdd2d69e21505079@haskell.org> #15307: Incorrect -ddump-deriv parenthesization for GND'd fmap implementation -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- This program: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# OPTIONS_GHC -ddump-deriv #-} module Bug where newtype Foo a = MkFoo (Maybe a) deriving Functor }}} When compiling, displays incorrect code in its `-ddump-deriv` output: {{{ $ ghci Bug.hs GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) ==================== Derived instances ==================== Derived class instances: instance GHC.Base.Functor Bug.Foo where GHC.Base.fmap = GHC.Prim.coerce @(forall (a_a1y2 :: TYPE GHC.Types.LiftedRep) (b_a1y3 :: TYPE GHC.Types.LiftedRep). a_a1y2 -> b_a1y3 -> GHC.Base.Maybe a_a1y2 -> GHC.Base.Maybe b_a1y3) @(forall (a_a1y2 :: TYPE GHC.Types.LiftedRep) (b_a1y3 :: TYPE GHC.Types.LiftedRep). a_a1y2 -> b_a1y3 -> Bug.Foo a_a1y2 -> Bug.Foo b_a1y3) GHC.Base.fmap (GHC.Base.<$) = GHC.Prim.coerce @(forall (a_a1y9 :: TYPE GHC.Types.LiftedRep) (b_a1ya :: TYPE GHC.Types.LiftedRep). a_a1y9 -> GHC.Base.Maybe b_a1ya -> GHC.Base.Maybe a_a1y9) @(forall (a_a1y9 :: TYPE GHC.Types.LiftedRep) (b_a1ya :: TYPE GHC.Types.LiftedRep). a_a1y9 -> Bug.Foo b_a1ya -> Bug.Foo a_a1y9) (GHC.Base.<$) Derived type family instances: Ok, one module loaded. }}} Notice how the type of `fmap` is `a_a1y2 -> b_a1y3 -> Bug.Foo a_a1y2 -> Bug.Foo b_a1y3`, not `(a_a1y2 -> b_a1y3) -> Bug.Foo a_a1y2 -> Bug.Foo b_a1y3`. The culprit is the `nlHsFunTy` function, which is used to construct this function type in `typeToLHsType`: {{{#!hs nlHsFunTy :: LHsType (GhcPass p) -> LHsType (GhcPass p) -> LHsType (GhcPass p) nlHsFunTy a b = noLoc (HsFunTy noExt a b) }}} This makes no attempt to add `HsParTy`s around any of its arguments. It's tempting to parenthesize //both// arguments, but interestingly, if you do this, then the type of `fmap` would become: {{{#!hs (a -> b) -> (Foo a -> Foo b) }}} This perhaps not what we want, since the parentheses around `Foo a -> Foo b` are redundant. Therefore, I propose that we adopt the same parenthesization scheme that `ppr_ty` uses for pretty-printing Core `Type`s: {{{#!hs ppr_ty ctxt_prec (IfaceFunTy ty1 ty2) = -- We don't want to lose synonyms, so we mustn't use splitFunTys here. maybeParen ctxt_prec funPrec $ sep [ppr_ty funPrec ty1, sep (ppr_fun_tail ty2)] where ppr_fun_tail (IfaceFunTy ty1 ty2) = (arrow <+> ppr_ty funPrec ty1) : ppr_fun_tail ty2 ppr_fun_tail other_ty = [arrow <+> pprIfaceType other_ty] }}} Namely, always parenthesize the argument type under `funPrec`, and recursively check the result type to see if it's also a function type, parenthesizing its arguments as necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 24 12:09:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jun 2018 12:09:25 -0000 Subject: [GHC] #15307: Incorrect -ddump-deriv parenthesization for GND'd fmap implementation In-Reply-To: <050.5a1160e153a31f1bbdd2d69e21505079@haskell.org> References: <050.5a1160e153a31f1bbdd2d69e21505079@haskell.org> Message-ID: <065.85d1feef3f0b8753c102c879366019d3@haskell.org> #15307: Incorrect -ddump-deriv parenthesization for GND'd fmap implementation -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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:D4890 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4890 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 24 12:12:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jun 2018 12:12:50 -0000 Subject: [GHC] #15235: GHCi's claim of infixr 0 (->) is a lie In-Reply-To: <050.1dea13c2dffcf4fb3726d468418c6455@haskell.org> References: <050.1dea13c2dffcf4fb3726d468418c6455@haskell.org> Message-ID: <065.e272206427d0cd57359dd666f12fa4ff@haskell.org> #15235: GHCi's claim of infixr 0 (->) is a lie -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15236 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Changing GHCi's fixity information for `(->)` is a simple matter of applying this change: {{{#!diff diff --git a/compiler/basicTypes/BasicTypes.hs b/compiler/basicTypes/BasicTypes.hs index 93010b7..e9d32f6 100644 --- a/compiler/basicTypes/BasicTypes.hs +++ b/compiler/basicTypes/BasicTypes.hs @@ -409,7 +409,7 @@ defaultFixity = Fixity NoSourceText maxPrecedence InfixL negateFixity, funTyFixity :: Fixity -- Wired-in fixities negateFixity = Fixity NoSourceText 6 InfixL -- Fixity of unary negate -funTyFixity = Fixity NoSourceText 0 InfixR -- Fixity of '->' +funTyFixity = Fixity NoSourceText (-1) InfixR -- Fixity of '->' {- Consider }}} However, there's one more question we should answer before applying this change: do we want the displayed `:info` output to be this: {{{ infixr -1 -> }}} Or this? {{{ infixr (-1) -> }}} With only the above change, `:info` will display the former. If we want the latter, we'd have to make additional changes to the pretty-printer output for fixity information to add parentheses. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 24 13:49:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jun 2018 13:49:22 -0000 Subject: [GHC] #15308: Error message prints explicit kinds when it shouldn't Message-ID: <050.8a60180d637a0d8f09dfd184e0f165b6@haskell.org> #15308: Error message prints explicit kinds when it shouldn't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Type checker) | 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: -------------------------------------+------------------------------------- When compiled, this program: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} {-# OPTIONS_GHC -fno-print-explicit-kinds #-} module Bug where import Data.Kind data Foo (a :: Type) :: forall b. (a -> b -> Type) -> Type where MkFoo :: Foo a f f :: Foo a f -> String f = show }}} Gives the following error: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:13:5: error: • No instance for (Show (Foo a b f)) arising from a use of ‘show’ • In the expression: show In an equation for ‘f’: f = show | 13 | f = show | ^^^^ }}} This error message is slightly incorrect, however. In "`No instance for (Show (Foo a b f))`", it claims that `Foo` has three visible type parameters, but it only has two. (I've even made sure to enable `-fno- print-explicit-kinds` at the type to ensure that the invisible `b` kind shouldn't get printed, but it was anyway.) This is a regression that was apparently introduced between GHC 8.0 and 8.2, since in GHC 8.0.2, it prints the correct thing: {{{ $ /opt/ghc/8.0.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:13:5: error: • No instance for (Show (Foo a f)) arising from a use of ‘show’ • In the expression: show In an equation for ‘f’: f = show }}} But it does not in GHC 8.2.1: {{{ $ /opt/ghc/8.2.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:13:5: error: • No instance for (Show (Foo a b f)) arising from a use of ‘show’ • In the expression: show In an equation for ‘f’: f = show | 13 | f = show | ^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 24 14:41:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jun 2018 14:41:55 -0000 Subject: [GHC] #15308: Error message prints explicit kinds when it shouldn't In-Reply-To: <050.8a60180d637a0d8f09dfd184e0f165b6@haskell.org> References: <050.8a60180d637a0d8f09dfd184e0f165b6@haskell.org> Message-ID: <065.d07fd9d9718a57d585d55fb2ec492327@haskell.org> #15308: Error message prints explicit kinds when it shouldn't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 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): Phab:D4891 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4891 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 24 16:48:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jun 2018 16:48:14 -0000 Subject: [GHC] #13584: ghci parse error on operator info In-Reply-To: <046.930e1afa5ab80feb957e040b20527a91@haskell.org> References: <046.930e1afa5ab80feb957e040b20527a91@haskell.org> Message-ID: <061.2553d2434119d0eef740a9bfa1c32cda@haskell.org> #13584: ghci parse error on operator info -------------------------------------+------------------------------------- Reporter: akegalj | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: parse, info, | operator Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by anarchist666): The {{{words}}} operator is used in the {{{:info}}} command. {{{ info :: Bool -> String -> InputT GHCi () info _ "" = throwGhcException (CmdLineError "syntax: ':i '") info allInfo s = handleSourceError GHC.printException $ do unqual <- GHC.getPrintUnqual dflags <- getDynFlags sdocs <- mapM (infoThing allInfo) (words s) mapM_ (liftIO . putStrLn . showSDocForUser dflags unqual) sdocs }}} But you can type {{{:info + -}}} and get this {{{ class Num a where (+) :: a -> a -> a ... -- Defined in ‘GHC.Num’ infixl 6 + class Num a where (-) :: a -> a -> a ... -- Defined in ‘GHC.Num’ infixl 6 - }}} We can filter all brackets in the input line, but I want to know what the others think about it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 24 20:57:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jun 2018 20:57:15 -0000 Subject: [GHC] #15309: mkLHsOpTy is discarding API Annotations Message-ID: <044.829fca7d22bd3f9199bbfac46b5e35d7@haskell.org> #15309: mkLHsOpTy is discarding API Annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For {{{#!hs ft :: (->) a b }}} the `AnnRarrow` API annotation is discarded. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jun 24 20:57:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Jun 2018 20:57:37 -0000 Subject: [GHC] #15309: mkLHsOpTy is discarding API Annotations In-Reply-To: <044.829fca7d22bd3f9199bbfac46b5e35d7@haskell.org> References: <044.829fca7d22bd3f9199bbfac46b5e35d7@haskell.org> Message-ID: <059.d7f92bd3e4cea3532df6b4062ae7c457@haskell.org> #15309: mkLHsOpTy is discarding API Annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | 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 Mon Jun 25 01:42:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 01:42:07 -0000 Subject: [GHC] #15306: First attempt at starting GHCI failed In-Reply-To: <044.bb0e20f9b63de8ba8466a48783a5351a@haskell.org> References: <044.bb0e20f9b63de8ba8466a48783a5351a@haskell.org> Message-ID: <059.4e6e9a4c6cb359517b96bd028078d57f@haskell.org> #15306: First attempt at starting GHCI failed -------------------------------------+------------------------------------- Reporter: DaleB | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by DaleB): * Attachment "WinGHCI Error.JPG" added. Error message received when opening WinGHCI -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 01:45:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 01:45:56 -0000 Subject: [GHC] #15306: First attempt at starting GHCI failed In-Reply-To: <044.bb0e20f9b63de8ba8466a48783a5351a@haskell.org> References: <044.bb0e20f9b63de8ba8466a48783a5351a@haskell.org> Message-ID: <059.44abc6dd1674aab3728f89bf653cfeaa@haskell.org> #15306: First attempt at starting GHCI failed -------------------------------------+------------------------------------- Reporter: DaleB | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by DaleB): * Attachment "WinGHCI Error 2.JPG" added. This shows that the offending file does exist -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 05:06:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 05:06:24 -0000 Subject: [GHC] #15310: Derive Generic1 instances for types of kind (k -> *) -> * that include applications of the parameter Message-ID: <050.14c3ec74b257e247a38f2225bf37d2c7@haskell.org> #15310: Derive Generic1 instances for types of kind (k -> *) -> * that include applications of the parameter -------------------------------------+------------------------------------- Reporter: cedricshock | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: (Type checker) | Keywords: DeriveGeneric | Operating System: Unknown/Multiple Generic1 | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `Generic1` class is polykinded. The `DeriveGeneric` extension can derive `Generic1` instances for types of kind `k -> *` parameterized over a parameter with a kind other than `k ~ *`, but only if they don't apply the parameter to other types. It currently cannot derive an instance for {{{#!hs newtype Fix f = In (f (Fix f)) deriving (Generic1) }}} or for {{{#!hs data Child f = Child { ordinal :: Int, nickname :: f String } deriving (Generic1) }}} It's possible to represent these types generically, either with composition that can include occurrences of the parameter or with new types that represent applications of the parameter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 05:29:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 05:29:32 -0000 Subject: [GHC] #14980: Runtime performance regression with binary operations on vectors In-Reply-To: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> References: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> Message-ID: <060.2bbee9bdbfdaed786e24a3c6fef3d32a@haskell.org> #14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: vector | bitwise operations 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 tdammers): Replying to [comment:7 ttylec]: > Hm... not exactly the bug disappear, you observed no speedup with "binary packed" version in the first place. Notice that in my benchmark, the "binary packed" version is an order of magnitude faster that the "unbox vectors" and the bug is about loosing that speed-up when we compile with 8.2.2 (and later) Indeed, I noticed. > In your case, there was no speed-up in the first place. May I ask you to check also `stack exec performance-bug-pair-2` and `stack exec performance-bug-2`? Stack failed on a cassava thing, I'm not exactly sure how to fix it, so I tried cabal first. If stack vs. cabal is the problem, however, then most likely that means it's a library problem rather than a GHC bug. I'll see if I can sort it out though, so that maybe I can reproduce your results. However, I don't think optimization settings could be the problem - after all, these are specified in the .cabal file, not stack.yaml, I have not overridden anything, and I verified that -O2 actually gets passed to GHC. I have even compiled the programs manually, merely pointing GHC to the cabal sandbox's package cache, and got the same results regardless. Results for `performance-bug-2` are similar. 8.0.2: {{{ "Generated" benchmarking 64 columns/raw unbox vectors time 445.2 μs (445.1 μs .. 445.4 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 443.4 μs (442.9 μs .. 443.8 μs) std dev 1.366 μs (1.077 μs .. 1.655 μs) benchmarking 64 columns/binary packed time 51.16 μs (51.09 μs .. 51.24 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 50.95 μs (50.90 μs .. 51.01 μs) std dev 204.4 ns (159.7 ns .. 264.0 ns) benchmarking 256 columns/raw unbox vectors time 443.9 μs (443.6 μs .. 444.4 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 442.7 μs (442.1 μs .. 444.1 μs) std dev 2.711 μs (1.414 μs .. 5.048 μs) benchmarking 256 columns/binary packed time 260.4 μs (255.3 μs .. 266.2 μs) 0.997 R² (0.996 R² .. 0.998 R²) mean 266.6 μs (263.1 μs .. 271.5 μs) std dev 9.366 μs (6.649 μs .. 13.29 μs) variance introduced by outliers: 24% (moderately inflated) }}} 8.2.2: {{{ "Generated" benchmarking 64 columns/raw unbox vectors time 445.0 μs (444.7 μs .. 445.2 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 444.0 μs (443.2 μs .. 447.0 μs) std dev 4.654 μs (1.118 μs .. 9.693 μs) benchmarking 64 columns/binary packed time 51.13 μs (51.11 μs .. 51.15 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 50.90 μs (50.86 μs .. 50.94 μs) std dev 146.1 ns (122.9 ns .. 181.2 ns) benchmarking 256 columns/raw unbox vectors time 440.4 μs (440.1 μs .. 440.5 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 437.9 μs (437.3 μs .. 438.4 μs) std dev 1.797 μs (1.576 μs .. 2.095 μs) benchmarking 256 columns/binary packed time 289.5 μs (285.1 μs .. 294.3 μs) 0.998 R² (0.998 R² .. 0.999 R²) mean 295.6 μs (292.0 μs .. 299.8 μs) std dev 8.814 μs (6.656 μs .. 11.69 μs) variance introduced by outliers: 19% (moderately inflated) }}} > I am curious on what machine/system you did tested it? Oh, and obviously optimization must be enabled (in case you didn't `stack build` it). Debian 9, x86_64. Intel i5 CPU, 4 GB RAM, official GHC release builds. I have a few possible explanations as to why we're seeing these differences: - Stack may be pulling in other GHC versions than the release bundles - Stack may be pulling in different version of some crucial library - Whatever platform you run on might trigger different code paths in GHC I'll investigate further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 05:51:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 05:51:47 -0000 Subject: [GHC] #15310: Derive Generic1 instances for types of kind (k -> *) -> * that include applications of the parameter In-Reply-To: <050.14c3ec74b257e247a38f2225bf37d2c7@haskell.org> References: <050.14c3ec74b257e247a38f2225bf37d2c7@haskell.org> Message-ID: <065.9976a17fd6f65c0deef374afb800ffea@haskell.org> #15310: Derive Generic1 instances for types of kind (k -> *) -> * that include applications of the parameter -------------------------------------+------------------------------------- Reporter: cedricshock | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: checker) | Keywords: DeriveGeneric Resolution: | Generic1 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 cedricshock): These types can represent applications of the parameter in `Generic1` instances {{{#!hs newtype ParAp0 c p = ParAp0 { unParAp0 :: p c } -- applications of the parameter newtype ParAp1 f p = ParAp1 { unParAp1 :: p (f p) } -- recursive applications of the parameter }}} For example the `f (Fix f)` in `Fix` can be represented by `ParAp1 Fix` {{{#!hs type Rep1 Fix = D1 ('MetaData "Fix" "CanDoRep1Model_0" "main" 'GHC.Types.False) (C1 ('MetaCons "In" 'PrefixI 'GHC.Types.False) (S1 ('MetaSel 'GHC.Maybe.Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (ParAp1 Fix))) }}} and the `f String` in `Child` can be represented by `ParAp0 String` {{{#!hs type Rep1 Child = D1 ('MetaData "Child" "CanDoRep1Model_0" "main" 'GHC.Types.False) (C1 ('MetaCons "Child" 'PrefixI 'GHC.Types.True) (S1 ('MetaSel ('Just "ordinal") 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (Rec0 GHC.Types.Int) :*: S1 ('MetaSel ('Just "nickname") 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (ParAp0 GHC.Base.String))) }}} Problems arise when attempting to represent a type that contains the parameter applied to the composition of other types. This type contains an application of the parameter to the composition of `[]` and `D` {{{#!hs data Compose2 f = Comp2 (f (Maybe (D f))) deriving Generic1 data D f = D deriving Generic1 }}} `ParAp1 (Maybe :*: D)` can represent `f (Maybe (D f))`, but the resulting `ParAp1` holds an `f ((Maybe :*: D) f))`, which, while representationally equivalent to `f (Maybe (D f))`, isn't nominally equivalent to `f (Maybe (D f))`. This prevents the `to1` and `from1` methods from being written, even with the help of `coerce`. Multiple compositions can be refactored to have `Generic1` instances. {{{#!hs data Compose2 f = Comp2 (f (MaybeD f)) deriving Generic1 newtype MaybeD f = MaybeD (Maybe (D f)) deriving Generic1 data D f = D deriving Generic1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 06:05:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 06:05:53 -0000 Subject: [GHC] #15310: Derive Generic1 instances for types of kind (k -> *) -> * that include applications of the parameter In-Reply-To: <050.14c3ec74b257e247a38f2225bf37d2c7@haskell.org> References: <050.14c3ec74b257e247a38f2225bf37d2c7@haskell.org> Message-ID: <065.90428003d36692852e30e97a3faafa46@haskell.org> #15310: Derive Generic1 instances for types of kind (k -> *) -> * that include applications of the parameter -------------------------------------+------------------------------------- Reporter: cedricshock | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: checker) | Keywords: DeriveGeneric Resolution: | Generic1 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 cedricshock): I wrote an implementation of `Generic1` deriving using `ParAp0` and `ParAp1`. You can preview it in this PR: https://github.com/Cedev/ghc/pull/1 I could use some practical advice and help on what to do next 1. I don't have a test case for a kind `(k -> *) -> *` where `k` isn't `*`. If you have any ideas, especially for a test case where `k ~ Constraint`, I'd appreciate them. 2. There are types in `base` that can now have `Generic1` instances derived for them, starting with `ParAp0` and `ParAp1` themselves. How do I add `Generic1` instances to base without breaking the compiler building, since an old compiler won't be able to derive those `Generic1` instances? 3. What other typeclasses should `ParAp0` and `ParAp1` have instances for? 4. What do I do next? Get feedback from both `ghc-devs` and `glasgow- haskell-users`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 08:48:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 08:48:29 -0000 Subject: [GHC] #15306: First attempt at starting GHCI failed In-Reply-To: <044.bb0e20f9b63de8ba8466a48783a5351a@haskell.org> References: <044.bb0e20f9b63de8ba8466a48783a5351a@haskell.org> Message-ID: <059.db661f97465dc6c5daaa96587dc24b56@haskell.org> #15306: First attempt at starting GHCI failed -------------------------------------+------------------------------------- Reporter: DaleB | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by DaleB): So I deleted the folder "C:\F", ran ghci at the command prompt and it is now working fine.This ticket can now be closed unless somebody out there want to do some further investigation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 09:25:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 09:25:56 -0000 Subject: [GHC] #14980: Runtime performance regression with binary operations on vectors In-Reply-To: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> References: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> Message-ID: <060.5f9c828a0311aff0118b79557201d430@haskell.org> #14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: vector | bitwise operations 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 tdammers): OK, some more experimenting. Changed the .cabal file to force `vector` to `0.12.0.1` (the latest version on hackage); no difference, results are still more or less the same on both compilers. Also managed to get things built with stack; the 8.2 results are also very similar: {{{ "Generated" benchmarking 64 columns/raw unbox vectors time 443.6 μs (443.2 μs .. 443.9 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 441.6 μs (441.2 μs .. 442.0 μs) std dev 1.364 μs (1.092 μs .. 1.738 μs) benchmarking 64 columns/binary packed time 51.35 μs (51.29 μs .. 51.44 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 51.07 μs (51.00 μs .. 51.18 μs) std dev 265.9 ns (176.1 ns .. 453.5 ns) benchmarking 256 columns/raw unbox vectors time 446.1 μs (445.5 μs .. 447.2 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 443.9 μs (443.4 μs .. 444.6 μs) std dev 1.883 μs (1.337 μs .. 3.374 μs) benchmarking 256 columns/binary packed time 291.2 μs (286.2 μs .. 296.9 μs) 0.998 R² (0.998 R² .. 0.999 R²) mean 298.3 μs (294.2 μs .. 301.2 μs) std dev 7.891 μs (5.688 μs .. 10.20 μs) variance introduced by outliers: 15% (moderately inflated) }}} Stack-installed, with 8.0.2: {{{ "Generated" benchmarking 64 columns/raw unbox vectors time 412.3 μs (411.7 μs .. 413.1 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 412.4 μs (412.0 μs .. 413.1 μs) std dev 1.643 μs (1.124 μs .. 2.815 μs) benchmarking 64 columns/binary packed time 21.89 μs (21.87 μs .. 21.90 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 21.90 μs (21.89 μs .. 21.91 μs) std dev 38.13 ns (26.94 ns .. 54.15 ns) benchmarking 256 columns/raw unbox vectors time 417.6 μs (416.0 μs .. 419.5 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 417.2 μs (416.5 μs .. 419.1 μs) std dev 3.403 μs (935.8 ns .. 6.896 μs) benchmarking 256 columns/binary packed time 29.56 μs (29.51 μs .. 29.63 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 29.52 μs (29.51 μs .. 29.56 μs) std dev 71.00 ns (36.37 ns .. 131.9 ns) }}} So apparently compiling with 8.0.2 through cabal gives different results than compiling though stack. Strange. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 10:21:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 10:21:55 -0000 Subject: [GHC] #15311: MCoercion lacks an Outputable instance Message-ID: <049.b5ea1182b9f8a04e41d20be9a8908734@haskell.org> #15311: MCoercion lacks an Outputable instance -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- There should be an outputable instance for `MCoercion` so it can be printed when debugging. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 10:29:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 10:29:36 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.5c3b44afa40527304def002fb920f43b@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15290, T15290a Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Good grief -- again! comment:17 is ghastly. Here's what is happening. What we are 'really' checking is {{{ bar = ((coerce @(Int -> Maybe b) @(Age -> Maybe b) bar) :: forall b. Age -> Maybe b) :: forall b. Age -> Maybe b }}} where * the outer type signature comes from checking that the type of the method matches the type that the class expects * the inner one comes from the 'deriving' patch Because both of those type sigs ultimately from the same source, both 'b's happen to have the same unique. That should be fine but it isn't: * The outer forall adds `b :-> b1[sk]` to the type environment. That's fine, even though this outer forall b does not scope; the type envt isn't responsible for resolving lexical scoping. * The `forall` on the inner signature is typechecked with by the `HsForAllTy` case of `tc_hs_type`, which calls * `tcExplicitTKBndrs`, which calls * `tcHsTyVarBndr`, which calls * `tcHsTyVarName`, '''which has a special case for type variables already in scope''' * The in-scope handling in `tcHsTyVarName` is a very special case intended '''only''' for the binders in the `LHSQTyVars` of an associated type or type instance declaration, nested inside a class decl. Yet it is here being used (accidentally) for the `forall` of a type signature, a situation that it is utterly unsuitable for. Even if the tyvar for a `forall` is already in scope, that should be utterly irrelevant to the type signature. * The net result is chaos: we end up with two different skolems that really represent the same type variable. Conclusion: we should radically narrow the cases in which this funny in-scope test applies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 11:22:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 11:22:04 -0000 Subject: [GHC] #15299: GHCi :print produces variables that cause a panic In-Reply-To: <042.578eecf80127f42516c823183cdbc00f@haskell.org> References: <042.578eecf80127f42516c823183cdbc00f@haskell.org> Message-ID: <057.555af70f161b8548031b6cd118a228df@haskell.org> #15299: GHCi :print produces variables that cause a panic -------------------------------+-------------------------------------- Reporter: Omf | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: duplicate | Keywords: debugger Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: Thank you for the report. Unless I'm mistaken, this is a duplicate of #12449. Please reopen if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 11:22:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 11:22:38 -0000 Subject: [GHC] #12449: Broken types in identifiers bound by :print In-Reply-To: <044.542a5d089ce4efa7862430871616a137@haskell.org> References: <044.542a5d089ce4efa7862430871616a137@haskell.org> Message-ID: <059.d089f65ba3856b4a1237afd08340a73f@haskell.org> #12449: Broken types in identifiers bound by :print -------------------------------------+------------------------------------- Reporter: mniip | 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: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): Also reported at #15299. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 13:17:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 13:17:36 -0000 Subject: [GHC] #14980: Runtime performance regression with binary operations on vectors In-Reply-To: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> References: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> Message-ID: <060.abbc08a3cf99ddd98aff92e54f69a944@haskell.org> #14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: vector | bitwise operations 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 tdammers): Even more strangely, I am now getting 8.0.2-like results using 8.2.2: {{{ "Generated" benchmarking 64 columns/raw unbox vectors time 417.9 μs (417.5 μs .. 418.3 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 418.3 μs (417.8 μs .. 419.6 μs) std dev 2.364 μs (827.2 ns .. 4.744 μs) benchmarking 64 columns/binary packed time 22.95 μs (22.90 μs .. 23.01 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 22.94 μs (22.91 μs .. 22.97 μs) std dev 105.9 ns (75.87 ns .. 146.9 ns) benchmarking 256 columns/raw unbox vectors time 432.7 μs (422.4 μs .. 443.9 μs) 0.997 R² (0.995 R² .. 0.999 R²) mean 423.4 μs (420.3 μs .. 428.6 μs) std dev 13.41 μs (7.712 μs .. 19.14 μs) variance introduced by outliers: 25% (moderately inflated) benchmarking 256 columns/binary packed time 29.75 μs (29.51 μs .. 30.16 μs) 0.999 R² (0.999 R² .. 1.000 R²) mean 29.64 μs (29.57 μs .. 29.86 μs) std dev 395.1 ns (120.1 ns .. 801.2 ns) }}} I'm starting to suspect that the decisive factor here is not GHC itself, but rather something else. Quite possibly, library versions play a role - the cabal builds for 8.0.2 and 8.2.2 use the same versions for all libraries (except base), while the stack builds differ in a few of them. Another possible explanation could be that while I'm forcing the compiler itself when compiling with cabal (`--with-compiler` / `--with-ghc`), I am not doing the same for any of the other tools cabal may be using, and those might not resolve in a compiler-specific way but rather just use whatever is installed system-wide (which happens to be from GHC 8.0.2 right now, but was 8.4.2 when I first started profiling). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 14:01:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 14:01:32 -0000 Subject: [GHC] #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation In-Reply-To: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> References: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> Message-ID: <061.b6977ad6c97eaba30ff7c5ac997b342f@haskell.org> #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation -------------------------------------+------------------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: Resolution: | PatternMatchWarnings 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 simonpj): Good point. Pattern-match coverage checking sorely needs a champion: someone who is willing to take ownership of the code (which is in only one module!) and give it love and care. There are a lot of open tickets: see [https://ghc.haskell.org/trac/ghc/wiki/PatternMatchCheck this summary wiki page] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 14:04:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 14:04:48 -0000 Subject: [GHC] #15310: Derive Generic1 instances for types of kind (k -> *) -> * that include applications of the parameter In-Reply-To: <050.14c3ec74b257e247a38f2225bf37d2c7@haskell.org> References: <050.14c3ec74b257e247a38f2225bf37d2c7@haskell.org> Message-ID: <065.ae12b63c9ee2e7c35a0c10eedbd93d57@haskell.org> #15310: Derive Generic1 instances for types of kind (k -> *) -> * that include applications of the parameter -------------------------------------+------------------------------------- Reporter: cedricshock | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: checker) | Keywords: DeriveGeneric Resolution: | Generic1 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 have to admit that I'm not fond of this approach, as it feels terribly //ad hoc//. These new representation types "fix" the issue by wiring in two very particular ways that the last parameter can appear in a data type. But there are an infinite numbers of ways that the last parameter can appear in a data type. What about: * `newtype A a = MkA (Either a a)` * `newtype B f = MkB (WrappedMonad f (Maybe f))` * etc. For every representation type that you cook up to fix one particular use case, one can always come up with another example that can't be represented neatly with the existing machinery. In my view, this reflects a weakness of `Generic1` approach in general. Namely, that one has to go through incredible contortions to bend data types to a certain shape just to be able to have a derived instance. Moreover, the contortions that one must do become even wilder if you start thinking about what it would take to support hypothetical `Generic2`, `Generic3`, etc. classes. My inclination is to not pursue this line of thinking, and instead recommend that you try an alternative generic programming library that's better suited to what you're trying to accomplish. The paper [http://dreixel.net/research/pdf/gpmp_colour.pdf Generic Programming with Multiple Parameters], which is authored by the same person who originally developed `Generic1`, was written to address this concern. In the paper, the author demonstrates a variant of `Generic` that works for any number of parameters (thus subsuming `Generic1`, `Generic2`, `Generic3`, etc.), and allows occurrences of these parameters wherever one desires. Bottom line: while `Generic1` is unfortunately restricted in what it's capable of, its capabilities are also quite predictable. I'm inclined to favor a predictable and limited approach over an approach which covers slightly more data types but adds unwarranted complexity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 14:35:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 14:35:05 -0000 Subject: [GHC] #15289: isUnliftedType GHC panic on pattern with True :: Maybe In-Reply-To: <043.406dc7510cae6790ee47421c68dfc69f@haskell.org> References: <043.406dc7510cae6790ee47421c68dfc69f@haskell.org> Message-ID: <058.8c7b97e3c68d294137271c1c5dc4b47a@haskell.org> #15289: isUnliftedType GHC panic on pattern with True :: Maybe -------------------------------------+------------------------------------- Reporter: Remi | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: Resolution: | PatternSynonyms 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:"2896082ec79f02b6388e038a8dae6cb22fe72dfc/ghc" 2896082e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2896082ec79f02b6388e038a8dae6cb22fe72dfc" Fix error recovery for pattern synonyms As Trac #15289 showed, we were carrying on after a type error in a pattern synonym, and then crashing. This patch improves error handling for pattern synonyms. I also moved a bit of code from TcBinds into TcPatSyn, which helpfully narrows the API. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 14:35:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 14:35:05 -0000 Subject: [GHC] #1520: Use Linux's signalfd() instead of pipe() to deliver signals to the IO manager In-Reply-To: <047.70e7b79651c491b5b253718c9a075059@haskell.org> References: <047.70e7b79651c491b5b253718c9a075059@haskell.org> Message-ID: <062.512a516930cd75fcc9966cfc269afcc3@haskell.org> #1520: Use Linux's signalfd() instead of pipe() to deliver signals to the IO manager -----------------------------------+--------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Runtime System | Version: 6.6.1 Resolution: wontfix | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -----------------------------------+--------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"9fc40c733ba8822a04bd92883801b214dee099ca/ghc" 9fc40c73/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9fc40c733ba8822a04bd92883801b214dee099ca" Refactor the kind-checking of tyvar binders The refactoring here is driven by the ghastly mess described in comment:24 of Trac #1520. The overall goal is to simplify the kind-checking of typev-variable binders, and in particular to narrow the use of the "in-scope tyvar binder" stuff, which is needed only for associated types: see the new Note [Kind-checking tyvar binders for associated types] in TcHsType. Now * The "in-scope tyvar binder" stuff is done only in - kcLHsQTyVars, which is used for the LHsQTyVars of a data/newtype, or type family declaration. - tcFamTyPats, which is used for associated family instances; it now calls tcImplicitQTKBndrs, which in turn usese newFlexiKindedQTyVar * tcExpicitTKBndrs (which is used only for function signatures, data con signatures, pattern synonym signatures, and expression type signatures) now does not go via the "in-scope tyvar binder" stuff at all. While I'm still not happy with all this code, the code is generally simpler, and I think this is a useful step forward. It does cure the problem too. (It's hard to trigger the problem in vanilla Haskell code, because the renamer would normally use different names for nested binders, so I can't offer a test.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 15:00:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 15:00:02 -0000 Subject: [GHC] #1520: Use Linux's signalfd() instead of pipe() to deliver signals to the IO manager In-Reply-To: <047.70e7b79651c491b5b253718c9a075059@haskell.org> References: <047.70e7b79651c491b5b253718c9a075059@haskell.org> Message-ID: <062.fcb093fe0f0112019448028d772b02d6@haskell.org> #1520: Use Linux's signalfd() instead of pipe() to deliver signals to the IO manager -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Runtime System | Version: 6.6.1 Resolution: wontfix | 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 RyanGlScott): The commit in comment:14 was really intended for #15290. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 15:00:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 15:00:08 -0000 Subject: [GHC] #14980: Runtime performance regression with binary operations on vectors In-Reply-To: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> References: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> Message-ID: <060.7b1e7e928ea8e0d3ba8ba60ed25f0b98@haskell.org> #14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: vector | bitwise operations 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): Perhaps the difference between stack and cabal come from the two making difference choices about which versions of which libraries they choose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 15:01:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 15:01:43 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.fc51bdc678eab77aab9911f8804fc157@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15290, T15290a Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Simon made a commit (9fc40c733ba8822a04bd92883801b214dee099ca) addressing the issue in comment:24, but he accidentally tagged the wrong ticket number. Here is the commit: {{{ From 9fc40c733ba8822a04bd92883801b214dee099ca Mon Sep 17 00:00:00 2001 From: Simon Peyton Jones Date: Mon, 25 Jun 2018 13:20:59 +0100 Subject: [PATCH] Refactor the kind-checking of tyvar binders The refactoring here is driven by the ghastly mess described in comment:24 of Trac #1520. The overall goal is to simplify the kind-checking of typev-variable binders, and in particular to narrow the use of the "in-scope tyvar binder" stuff, which is needed only for associated types: see the new Note [Kind-checking tyvar binders for associated types] in TcHsType. Now * The "in-scope tyvar binder" stuff is done only in - kcLHsQTyVars, which is used for the LHsQTyVars of a data/newtype, or type family declaration. - tcFamTyPats, which is used for associated family instances; it now calls tcImplicitQTKBndrs, which in turn usese newFlexiKindedQTyVar * tcExpicitTKBndrs (which is used only for function signatures, data con signatures, pattern synonym signatures, and expression type signatures) now does not go via the "in-scope tyvar binder" stuff at all. While I'm still not happy with all this code, the code is generally simpler, and I think this is a useful step forward. It does cure the problem too. (It's hard to trigger the problem in vanilla Haskell code, because the renamer would normally use different names for nested binders, so I can't offer a test.) --- compiler/hsSyn/HsDecls.hs | 43 +++++-- compiler/typecheck/TcHsType.hs | 258 +++++++++++++++++++++---------------- compiler/typecheck/TcTyClsDecls.hs | 3 +- 3 files changed, 178 insertions(+), 126 deletions(-) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 15:07:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 15:07:22 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.d15ce44ce03b39b01c973c9c1c014d26@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15290, T15290a Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for putting this in the right place. I think your patch should work now; and I tried this which seems even better {{{ diff --git a/compiler/typecheck/TcGenDeriv.hs b/compiler/typecheck/TcGenDeriv.hs index b944520..736eb14 100644 --- a/compiler/typecheck/TcGenDeriv.hs +++ b/compiler/typecheck/TcGenDeriv.hs @@ -1668,13 +1668,12 @@ gen_Newtype_binds loc cls inst_tvs inst_tys rhs_ty [] rhs_expr] where Pair from_ty to_ty = mkCoerceClassMethEqn cls inst_tvs inst_tys rhs_ty meth_id - meth_RDR = getRdrName meth_id + (_, _, from_tau) = tcSplitSigmaTy from_ty rhs_expr = nlHsVar (getRdrName coerceId) - `nlHsAppType` from_ty - `nlHsAppType` to_ty - `nlHsApp` nlHsVar meth_RDR + `nlHsApp` (nlHsVar meth_RDR `nlExprWithTySig` from_tau) + `nlExprWithTySig` to_ty mk_atf_inst :: TyCon -> TcM FamInst mk_atf_inst fam_tc = do @@ -1703,11 +1702,6 @@ gen_Newtype_binds loc cls inst_tvs inst_tys rhs_ty rep_cvs' = toposortTyVars rep_cvs pp_lhs = ppr (mkTyConApp fam_tc rep_lhs_tys) -nlHsAppType :: LHsExpr GhcPs -> Type -> LHsExpr GhcPs -nlHsAppType e s = noLoc (HsAppType hs_ty e) - where - hs_ty = mkHsWildCardBndrs $ nlHsParTy (typeToLHsType s) - nlExprWithTySig :: LHsExpr GhcPs -> Type -> LHsExpr GhcPs nlExprWithTySig e s = noLoc $ ExprWithTySig hs_ty $ parenthesizeHsExpr sigPrec e }}} I like this because it feels more uniform: two type signatures rather that one type signature and two type applications. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 15:09:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 15:09:18 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.49277ee0400c76d6f4ef6bb3663d5bd0@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15290, T15290a Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thanks, Simon. Do be aware that the program in comment:22 still panics. I'll check that it as an `expect_broken` test case in my upcoming patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 15:10:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 15:10:08 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.17a87593136db43579ef04aef7789111@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15290, T15290a Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > On the subject of the actual panic observed in this ticket, I don't think Simon's commit quite fixed it. I'm still observing the panic on commit 122ba98af22c2b016561433dfa55bbabba98d972 with this program (taken from #14883): Are you sure? It compiles on HEAD for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 15:18:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 15:18:39 -0000 Subject: [GHC] #15061: print022 testcase fails on i386 In-Reply-To: <046.070201c29a49dce5435517538bdcfad1@haskell.org> References: <046.070201c29a49dce5435517538bdcfad1@haskell.org> Message-ID: <061.5d0384a9e39bcfa464c58b0351c41d50@haskell.org> #15061: print022 testcase fails on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: ci-breakage 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): * owner: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 15:19:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 15:19:39 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.676e39f327a0c113078f7267b7e59ff3@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15290, T15290a Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Actually, it turns out that the approach in comment:26 isn't feasible. It breaks on the program in comment:15, as it generates the following code: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} module T15290b where import Data.Coerce class C a where c :: Int -> forall b. b -> a instance C Int where c _ _ = 42 newtype Age = MkAge Int -- deriving C instance C Age where c = coerce (c :: Int -> forall b. b -> Int) :: Int -> forall b. b -> Age }}} {{{ $ ghc Bug.hs [1 of 1] Compiling T15290b ( Bug.hs, Bug.o ) Bug.hs:19:7: error: • Couldn't match representation of type ‘b0’ with that of ‘b1’ arising from a use of ‘coerce’ ‘b1’ is a rigid type variable bound by a type expected by the context: Int -> forall b1. b1 -> Age at Bug.hs:19:50-74 • In the expression: coerce (c :: Int -> forall b. b -> Int) :: Int -> forall b. b -> Age In an equation for ‘c’: c = coerce (c :: Int -> forall b. b -> Int) :: Int -> forall b. b -> Age In the instance declaration for ‘C Age’ | 19 | c = coerce (c :: Int -> forall b. b -> Int) :: Int -> forall b. b -> Age | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Since this does typecheck with the `TypeApplications`-based approach, I'll go with that one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 15:20:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 15:20:02 -0000 Subject: [GHC] #15064: T8089 mysteriously fails when GHC is built with LLVM In-Reply-To: <046.7f8c4e91c0adf39423142484582ab39d@haskell.org> References: <046.7f8c4e91c0adf39423142484582ab39d@haskell.org> Message-ID: <061.2fa876cdeb8956adc43ca03dfdbd282e@haskell.org> #15064: T8089 mysteriously fails when GHC is built with LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (LLVM) | Version: 8.2.2 Resolution: | Keywords: ci-breakage 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): * owner: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 15:21:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 15:21:56 -0000 Subject: [GHC] #15216: plugins10 broken In-Reply-To: <046.4e5e0be222cd091f3b7f1aa715644fd7@haskell.org> References: <046.4e5e0be222cd091f3b7f1aa715644fd7@haskell.org> Message-ID: <061.52b92eed01ab81e601ec5355481bab6e@haskell.org> #15216: plugins10 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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): * owner: tdammers => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 15:26:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 15:26:59 -0000 Subject: [GHC] #15136: High CPU when asynchronous exception and unblocking retry on TVar raced In-Reply-To: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> References: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> Message-ID: <062.da8a187427f011a3efc2cb641e3bd610@haskell.org> #15136: High CPU when asynchronous exception and unblocking retry on TVar raced -------------------------------------+------------------------------------- Reporter: nshimaza | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.2 Resolution: | Keywords: 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): We will make a best-effort to look at this for 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 16:19:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 16:19:58 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.e610cca28f57bee510cfc5dbb8e4af17@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15290, T15290a Blocked By: | Blocking: 9123, 14883 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Ah, correction, I can reproduce this. Weird. I'll look. Gah. Yet another unrelated bug, this time in `TcDerivInfer.simplifyDeriv`. Patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 16:44:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 16:44:07 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.34a85700634de450677fad227b2c8e5d@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15290, T15290a Blocked By: | Blocking: 9123 Related Tickets: | Differential Rev(s): Phab:D4895 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4895 * blocking: 9123, 14883 => 9123 Comment: Phab:D4895 implements the `deriving`-related bits. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 16:45:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 16:45:00 -0000 Subject: [GHC] #14883: QuantifiedConstraints don't kick in when used in TypeApplications In-Reply-To: <050.9ae7dfd18c1aed745c56cdebbc78f3e8@haskell.org> References: <050.9ae7dfd18c1aed745c56cdebbc78f3e8@haskell.org> Message-ID: <065.2b7d8ce6c1d04b5005ba8eb7f34489ed@haskell.org> #14883: QuantifiedConstraints don't kick in when used in TypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #15290 | Differential Rev(s): Phab:D4895 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4895 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 16:45:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 16:45:56 -0000 Subject: [GHC] #15205: Unnecessary equality superclass In-Reply-To: <046.518e1da1aecaf92b89e450640d4328c5@haskell.org> References: <046.518e1da1aecaf92b89e450640d4328c5@haskell.org> Message-ID: <061.754c4f08c509b971234b43e0e7f56e3e@haskell.org> #15205: Unnecessary equality superclass -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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 Simon Peyton Jones ): In [changeset:"577399c0dfd544a613e69f0760046ec0769f33a2/ghc" 577399c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="577399c0dfd544a613e69f0760046ec0769f33a2" Coments and debug tracing only See Trac #15205 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 17:05:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 17:05:22 -0000 Subject: [GHC] #10869: Option to dump preprocessed source In-Reply-To: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> References: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> Message-ID: <061.c40980ac78e3bf8193a0637f08510216@haskell.org> #10869: Option to dump preprocessed source -------------------------------------+------------------------------------- Reporter: phischu | Owner: RolandSenn Type: feature request | Status: patch Priority: low | Milestone: Component: Driver | Version: 7.10.2 Resolution: | Keywords: easy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10869 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D4861 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * testcase: => T10869 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 17:36:40 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 17:36:40 -0000 Subject: [GHC] #14899: Significant compilation time regression between 8.4 and HEAD due to coverage checking In-Reply-To: <050.9e589019d6eb1fc4987004e5aa20a3e4@haskell.org> References: <050.9e589019d6eb1fc4987004e5aa20a3e4@haskell.org> Message-ID: <065.dbe6ae2f97ae5c1c75211dedd2f52b54@haskell.org> #14899: Significant compilation time regression between 8.4 and HEAD due to coverage checking -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | 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: | -------------------------------------+------------------------------------- Comment (by bgamari): It seems to me like comment:4 (which I updated to fix a few mistakes) is only part of the story. In particular, the constraint `Δ'` proposed in that comment is not currently admitted under the constraint syntax given in the paper. In particular, the right hand size of a term equality (e.g. the `≈` production) is expected to be an expression. However, there is no way to lift `(u_0 |> sym co)` into an expression. More generally, it doesn't make sense to me to lift a value abstraction like `u_0` into an expression. Perhaps a new constraint variety is needed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 18:16:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 18:16:25 -0000 Subject: [GHC] #15289: isUnliftedType GHC panic on pattern with True :: Maybe In-Reply-To: <043.406dc7510cae6790ee47421c68dfc69f@haskell.org> References: <043.406dc7510cae6790ee47421c68dfc69f@haskell.org> Message-ID: <058.1b441cdbe003f59c89f4b0c7bfed2823@haskell.org> #15289: isUnliftedType GHC panic on pattern with True :: Maybe -------------------------------------+------------------------------------- Reporter: Remi | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: Resolution: | PatternSynonyms 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): Simon, is this a merge candidate for 8.6.1? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 18:31:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 18:31:34 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails In-Reply-To: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> References: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> Message-ID: <065.163989ecaf062889d9c4b76450141b1b@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, CUSKs 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): I have good news and bad news. The bad news is that this still does not typecheck on GHC HEAD. The good news is that it no longer panics! It now gives the following, lovely error message: {{{ $ /opt/ghc/head/bin/ghci Bug.hs GHCi, version 8.7.20180621: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:8:42: error: • Expected a type, but ‘k’ has kind ‘k’ • In the kind ‘[(k, Type)]’ | 8 | class ListTuple (tuple :: Type) (as :: [(k, Type)]) where | ^ }}} So that's... nice, I guess. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 18:33:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 18:33:14 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails In-Reply-To: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> References: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> Message-ID: <065.654c2b97d137772a7be5884d914939e3@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, CUSKs 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): As far as I can tell, the only available workaround for this issue is to explicitly quantify `k`, like so: {{{#!hs class ListTuple (tuple :: Type) k (as :: [(k, Type)]) where type ListToTuple as :: Type }}} `generic-lens` may need to employ this hack if this issue hasn't been fixed by 8.6.1's release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 18:48:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 18:48:02 -0000 Subject: [GHC] #14890: Make Linux slow validate green In-Reply-To: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> References: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> Message-ID: <061.0e6649013ffc2930001058c3687d4910@haskell.org> #14890: Make Linux slow validate green -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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): D4546, D4636, Wiki Page: | D4712 -------------------------------------+------------------------------------- Comment (by requisitebits): I also see failures on my x86_64 Linux desktop, but maybe my verification strategy is missing something. See https://gist.github.com/jmitchell/97ec81a114cb92a3323abb4ec3e020b6 for the script I ran. Note that the git revision I chose comes from comment:12. Here are results: {{{ Unexpected results from: TEST="T10294 T10294a T10420 T11462 T11525 T12567a annrun01 frontend01 ghci024 plugin-recomp-flags plugin-recomp-impure plugin-recomp-pure plugins01 plugins05 plugins06 plugins07 plugins08 plugins09 plugins11 plugins12 plugins13 plugins14 plugins15 process001 process002" SUMMARY for test run started at Mon Jun 25 03:50:20 2018 UTC 1:30:34 spent to go through 6419 total tests, which gave rise to 19948 test cases, of which 13291 were skipped 20 had missing libraries 6458 expected passes 154 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 25 unexpected failures 0 unexpected stat failures Unexpected failures: annotations/should_run/annrun01.run annrun01 [exit code non-0] (normal) ghci/scripts/ghci024.run ghci024 [bad stderr] (normal) plugins/plugins01.run plugins01 [bad exit code] (normal) plugins/plugins05.run plugins05 [exit code non-0] (dyn) plugins/plugins06.run plugins06 [exit code non-0] (dyn) plugins/plugins07.run plugins07 [bad exit code] (normal) plugins/plugins08.run plugins08 [bad exit code] (normal) plugins/plugins09.run plugins09 [bad exit code] (normal) plugins/plugins11.run plugins11 [bad exit code] (normal) plugins/plugins12.run plugins12 [bad exit code] (normal) plugins/plugins13.run plugins13 [bad exit code] (normal) plugins/plugins14.run plugins14 [bad exit code] (normal) plugins/plugins15.run plugins15 [bad exit code] (normal) plugins/T10420.run T10420 [bad exit code] (normal) plugins/T10294.run T10294 [bad exit code] (normal) plugins/T10294a.run T10294a [bad exit code] (normal) plugins/frontend01.run frontend01 [bad exit code] (normal) plugins/T12567a.run T12567a [bad exit code] (normal) plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit code] (normal) plugins/plugin-recomp-impure.run plugin-recomp-impure [bad exit code] (normal) plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit code] (normal) typecheck/should_compile/T11462.run T11462 [exit code non-0] (normal) typecheck/should_compile/T11525.run T11525 [exit code non-0] (normal) ../../libraries/process/tests/process001.run process001 [bad exit code] (normal) ../../libraries/process/tests/process002.run process002 [bad exit code] (normal) make[1]: *** [../mk/test.mk:329: test] Error 1 make[1]: Leaving directory '/home/jake/src/ghc/testsuite/tests' make: *** [Makefile:223: test] Error 2 }}} I'm running the same script again using `REV=1c2c2d3dfd4c36884b22163872feb87122b4528d` (recent `master` commit) instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 21:43:23 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 21:43:23 -0000 Subject: [GHC] #14890: Make Linux slow validate green In-Reply-To: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> References: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> Message-ID: <061.f908633233aff02468a3deb23af345e9@haskell.org> #14890: Make Linux slow validate green -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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): D4546, D4636, Wiki Page: | D4712 -------------------------------------+------------------------------------- Comment (by requisitebits): Results when using the same script from comment:15, except with `REV=1c2c2d3dfd4c36884b22163872feb87122b4528d`: {{{ Unexpected results from: TEST="T10294 T10294a T10420 T11462 T11525 T12567a annrun01 frontend01 ghci024 plugin-recomp-flags plugin-recomp-impure plugin-recomp-pure plugins01 plugins05 plugins06 plugins07 plugins08 plugins09 plugins11 plugins12 plugins13 plugins14 plugins15" SUMMARY for test run started at Mon Jun 25 19:59:07 2018 UTC 1:30:40 spent to go through 6454 total tests, which gave rise to 20029 test cases, of which 13338 were skipped 20 had missing libraries 6495 expected passes 153 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 23 unexpected failures 0 unexpected stat failures Unexpected failures: annotations/should_run/annrun01.run annrun01 [exit code non-0] (normal) ghci/scripts/ghci024.run ghci024 [bad stderr] (normal) plugins/plugins01.run plugins01 [bad exit code] (normal) plugins/plugins05.run plugins05 [exit code non-0] (dyn) plugins/plugins06.run plugins06 [exit code non-0] (dyn) plugins/plugins07.run plugins07 [bad exit code] (normal) plugins/plugins08.run plugins08 [bad exit code] (normal) plugins/plugins09.run plugins09 [bad exit code] (normal) plugins/plugins11.run plugins11 [bad exit code] (normal) plugins/plugins12.run plugins12 [bad exit code] (normal) plugins/plugins13.run plugins13 [bad exit code] (normal) plugins/plugins14.run plugins14 [bad exit code] (normal) plugins/plugins15.run plugins15 [bad exit code] (normal) plugins/T10420.run T10420 [bad exit code] (normal) plugins/T10294.run T10294 [bad exit code] (normal) plugins/T10294a.run T10294a [bad exit code] (normal) plugins/frontend01.run frontend01 [bad exit code] (normal) plugins/T12567a.run T12567a [bad exit code] (normal) plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit code] (normal) plugins/plugin-recomp-impure.run plugin-recomp-impure [bad exit code] (normal) plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit code] (normal) typecheck/should_compile/T11462.run T11462 [exit code non-0] (normal) typecheck/should_compile/T11525.run T11525 [exit code non-0] (normal) make[1]: *** [../mk/test.mk:329: test] Error 1 make[1]: Leaving directory '/home/jake/src/ghc/testsuite/tests' make: *** [Makefile:223: test] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 22:02:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 22:02:48 -0000 Subject: [GHC] #14890: Make Linux slow validate green In-Reply-To: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> References: <046.a107a76cbb0183d36ada5ee5738b1b26@haskell.org> Message-ID: <061.c958b9c32ed5746012c011dcfeeee69e@haskell.org> #14890: Make Linux slow validate green -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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): D4546, D4636, Wiki Page: | D4712 -------------------------------------+------------------------------------- Comment (by bgamari): It's entirely possible that there is some environment-dependence here. It certainly passes somewhat reliably on CircleCI (save a pesky intermittent failure of `posix002` which I haven't been able to reproduce locally). See the circleci configuration in the tree `.circleci/config.yml` for the test configuration. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jun 25 22:46:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Jun 2018 22:46:04 -0000 Subject: [GHC] #15289: isUnliftedType GHC panic on pattern with True :: Maybe In-Reply-To: <043.406dc7510cae6790ee47421c68dfc69f@haskell.org> References: <043.406dc7510cae6790ee47421c68dfc69f@haskell.org> Message-ID: <058.e74831f7be40121664acacd9fdd28c41@haskell.org> #15289: isUnliftedType GHC panic on pattern with True :: Maybe -------------------------------------+------------------------------------- Reporter: Remi | Owner: (none) Type: bug | Status: merge Priority: low | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: Resolution: | PatternSynonyms 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): * status: new => merge Comment: It seems like a simple enough patch and this is clearly a bug so I'm happy to merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 04:09:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 04:09:24 -0000 Subject: [GHC] #15312: getChanContents exception behavior seems a bit odd Message-ID: <045.12177ba1b6d5f9a9adf57d73b0a776a1@haskell.org> #15312: getChanContents exception behavior seems a bit odd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.4.3 Libraries | 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: -------------------------------------+------------------------------------- I've been playing around with `Control.Concurrent.Chan` today. Something seems a bit off: {{{#!hs -- Bug.hs import Control.Concurrent (forkIO, yield) import Control.Concurrent.Chan import Data.List (elem) import Control.Exception import Control.Concurrent.MVar data Ex = Ex deriving Show instance Exception Ex main = do ch <- newChan sync1 <- newEmptyMVar sync2 <- newEmptyMVar forkIO $ do {writeList2Chan ch [1..3*10^6 :: Int]; putMVar sync1 ()} yield writeChan ch (-12) cont <- getChanContents ch tid <- forkIO $ do evaluate (last cont) putMVar sync2 () yield throwTo tid Ex print (elem (3*10^6) cont) takeMVar sync1 tryTakeMVar sync2 }}} When I run this single-threaded (`+RTS -N1`), it prints {{{ Bug: Ex Bug: Ex }}} One of the thunks in the lazy list gets overwritten by the (asynchronous) exception. This seems a bit surprising; is it the way it should be? Does `hGetContents` do this too? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 04:55:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 04:55:11 -0000 Subject: [GHC] #15312: getChanContents exception behavior seems a bit odd In-Reply-To: <045.12177ba1b6d5f9a9adf57d73b0a776a1@haskell.org> References: <045.12177ba1b6d5f9a9adf57d73b0a776a1@haskell.org> Message-ID: <060.e25280354a2c5d59d683cdd68dd374f6@haskell.org> #15312: getChanContents exception behavior seems a bit odd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.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 dfeuer): The basic problem seems to be that `readChan` uses `modifyMVar`, which uses `onException`, which catches arbitrary exceptions and rethrows them as synchronous exceptions: {{{#!hs onException :: IO a -> IO b -> IO a onException io what = io `catch` \e -> do _ <- what throwIO (e :: SomeException) }}} I don't think `readChan` can throw any synchronous exceptions, so perhaps it should rethrow any exceptions it receives asynchronously and retry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 05:42:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 05:42:31 -0000 Subject: [GHC] #15051: -split-objs generates excessively many files on Windows In-Reply-To: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> References: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> Message-ID: <060.5510a1d1461c980d59d35a74d1a27d2c@haskell.org> #15051: -split-objs generates excessively many files on Windows -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Phyx- Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (CodeGen) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * failure: None/Unknown => Compile-time performance bug * component: Compiler => Compiler (CodeGen) * architecture: x86_64 (amd64) => Unknown/Multiple Comment: This is beyond annoying. The windows tarballs are useless after this change. A full compile takes a day and a half in validate mode. even compiling a simple module now takes seconds. So I'm just going to kill SPLIT_OBJS as this change has effectively made it useless. Compiling a simple Cabal module alone takes 900 fork/exec calls. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 06:24:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 06:24:27 -0000 Subject: [GHC] #14529: Refactor ConDecl In-Reply-To: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> References: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> Message-ID: <061.4fa4bc832f6fca2b242423dfd67949b6@haskell.org> #14529: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 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:D4867 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): @bgamari, this is already on the ghc-8.6 branch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 08:50:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 08:50:19 -0000 Subject: [GHC] #15289: isUnliftedType GHC panic on pattern with True :: Maybe In-Reply-To: <043.406dc7510cae6790ee47421c68dfc69f@haskell.org> References: <043.406dc7510cae6790ee47421c68dfc69f@haskell.org> Message-ID: <058.76253af7e39d180bd2b8f3c744f512ae@haskell.org> #15289: isUnliftedType GHC panic on pattern with True :: Maybe -------------------------------------+------------------------------------- Reporter: Remi | Owner: (none) Type: bug | Status: merge Priority: low | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: Resolution: | PatternSynonyms 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): Yes, probably worth merging -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 08:58:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 08:58:17 -0000 Subject: [GHC] #15313: Framework failures on windows with plugins Message-ID: <046.f52c74aebbb7c1bfb16082509fa8f952@haskell.org> #15313: Framework failures on windows with plugins -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- On Windows, when the load is heavy (i.e. when doing a full `sh validate` I get a bunch of framework failures in the `plugins/` testsuite directory {{{ Framework failures: plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) plugins/T10420.run T10420 [normal] (pre_cmd failed: 2) plugins/T11244.run T11244 [normal] (pre_cmd failed: 2) plugins/plugin-recomp-pure.run plugin-recomp-pure [normal] (pre_cmd failed: 2) plugins/plugin-recomp-impure.run plugin-recomp-impure [normal] (pre_cmd failed: 2) plugins/plugin-recomp-flags.run plugin-recomp-flags [normal] (pre_cmd failed: 2) }}} I sent a full log to Tamar who said: Thanks for the log, that does give a clue. The command fails with {{{ setup.exe: 'C:/code/HEAD/inplace/bin/ghc-pkg.exe' exited with an error: ... rule-defining-plugin-0.1: cannot find any of ["libHSrule-defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z.a","libHSrule- defining-plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z.p_a","libHSrule-defining- plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z-ghc8.5.20180616.so","libHSrule-defining- plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z-ghc8.5.20180616.dylib","HSrule-defining- plugin-0.1-GxqqrdsQ5NRK9hAhEkvz8Z-ghc8.5.20180616.dll"] on library path (use --force to override) make[2]: *** [Makefile:18: package.T10420] Error 1 }}} so it's the `setup install` from https://github.com/ghc/ghc/blob/c2783ccf545faabd21a234a4dfc569cd856082b9/testsuite/tests/plugins /rule-defining-plugin/Makefile failing. Unfortunately, all those tests run with -v0 which is annoying because now the verbosity of the testsuite doesn't control that of these tests. I'm not sure why these commands fail under heavy load though. I'll need to dive into the source of ghc-pkg to figure out what's happening. Notice that all the framework failures are these plugin tests which modify a package database. A wild guess is that `ghc-pkg` tries to take a lock on all package-databases or something when it's mutating one. But I'm not intimately familiar with the package store and this doesn't explain why it doesn't happen on Linux. For now one solution I can propose is to create a ticket to track these and mark these tests as cpu multirace on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 09:08:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 09:08:44 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.a8e1ccadd292799c166d32136be353b4@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): #12753 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 09:10:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 09:10:24 -0000 Subject: [GHC] #15303: API Annotations lost when parsing tyapp In-Reply-To: <044.1aa714aa9f40d3b728af19a48aa49408@haskell.org> References: <044.1aa714aa9f40d3b728af19a48aa49408@haskell.org> Message-ID: <059.082b50ad5a0d6a2ae28b813b1807fd0f@haskell.org> #15303: API Annotations lost when parsing tyapp -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"e53c113dcfeca9ee957722ede3d8b6a2c4c751a1/ghc" e53c113d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e53c113dcfeca9ee957722ede3d8b6a2c4c751a1" API Annotations when parsing typapp Make sure the original annotations are still accessible for a promoted type. Closes #15303 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 09:13:48 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 09:13:48 -0000 Subject: [GHC] #15303: API Annotations lost when parsing tyapp In-Reply-To: <044.1aa714aa9f40d3b728af19a48aa49408@haskell.org> References: <044.1aa714aa9f40d3b728af19a48aa49408@haskell.org> Message-ID: <059.bb0041b373891ca1a71934cc4ea48547@haskell.org> #15303: API Annotations lost when parsing tyapp -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => merge Comment: Merge to ghc-8.6 please. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 09:38:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 09:38:09 -0000 Subject: [GHC] #14980: Runtime performance regression with binary operations on vectors In-Reply-To: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> References: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> Message-ID: <060.23db25b6baf962edc8bb37fc5b4a0720@haskell.org> #14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: vector | bitwise operations 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 tdammers): I have written a script to analyze the library selections in the 4 different build scenarios. Cabal with GHC 8.0.2 and cabal with GHC 8.2.2 both pull in the exact same libraries (except for `base`, obv.); so I only compared cabal with GHC 8.0.2 (`good1`), stack LTS 9.21 (`good2`), and stack LTS 11.1 (`bad`). I deleted `~/.stack`, and made clean builds for each of the three and verified that the `good` ones expose the desired behavior, and the `bad` one regresses. Then I listed the packages that got installed (from `.stack/snapshots/...` and `.cabal-sandbox/.../...packages.conf.d`), and compared the three lists. I threw out all the packages that met any of the following criteria: - the package is not in all 3 lists (meaning that it's not a direct dependency, and the difference must also be reflected in some other package choice) - the package version for the `bad` list matches one of the `good` lists exactly (meaning that it cannot be the culprit) The remaining list is this (columns giving the installed versions for the `good1`, `good2` and `bad` lists in this order): {{{ aeson: 1.4.0.0 | 1.1.2.0 | 1.2.4.0 criterion: 1.4.1.0 | 1.1.4.0 | 1.3.0.0 primitive: 0.6.4.0 | 0.6.2.0 | 0.6.3.0 scientific: 0.3.6.2 | 0.3.5.2 | 0.3.5.3 terminal-ansi: 0.8.0.4 | 0.6.3.1 | 0.8.0.2 }}} Which is interesting, in that the `bad` versions are all between the `good1` and `good2` versions. So if any of these cause the badness, then the problem must be a regression that wasn't present in the first version, and has been fixed between the second and the third version. Another remarkable fact is that Cabal installs the exact same versions of all the libraries for GHC 8.0.2 and GHC 8.2.2, despite `base` versions being different - this could mean one of two things: a) Cabal fails to detect the correct version of `base` (using the system- wide GHC install instead of the one demanded by `--with-compiler`), so we end up resolving libraries for 8.0.2, and it just happens to compile cleanly with 8.2.2 anyway; or b) All the required libraries happen to have bounds on `base` that are compatible with both 8.0.2 and 8.2.2, so Cabal's resolver ends up producing the exact same solution for both compilers. a) would be a bug, b) would be a lucky coincidence. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 10:28:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 10:28:22 -0000 Subject: [GHC] #15314: Internal error during typechecking of a hole in GHCi when there's shadowed identifiers Message-ID: <044.a38cb36cce530ca78b0769c47739ba35@haskell.org> #15314: Internal error during typechecking of a hole in GHCi when there's shadowed identifiers -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.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: -------------------------------------+------------------------------------- {{{#!hs GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> let x = () Prelude> let x = () Prelude> :t _ :1:1: error: GHC internal error: ‘Ghci1.x’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [] }}} Seems to only happen when there were two identifiers defined with the same name. As verified by mpickering on IRC this isn't reproducible in 8.2.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 10:37:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 10:37:34 -0000 Subject: [GHC] #15315: Renamer plugins could run after each group has been renamed Message-ID: <049.364dc4b31c5f3adc156474aa350df00b@haskell.org> #15315: Renamer plugins could run after each group has been renamed -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: plugins | 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 discussion with Ben, he suggested that it might be possible for a renamer plugin to run after each group had been renamed. This would then make it possible to modify renamed bindings. Currently, the interface for renamer plugins is quite strange and they run just before typechecker plugins in the implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 11:12:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 11:12:57 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.e86d3dd1bd1a81d4928c5be6b5437ea3@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15290, T15290a Blocked By: | Blocking: 9123 Related Tickets: | Differential Rev(s): Phab:D4895 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, this commit fixes the problem reported in comment:22, and adds the code there as a regression test. This is the ''third'' separate bug exposed by the original bug report. Wow. {{{ commit 261dd83cacec71edd551e9c581d05285c9ea3226 Author: Simon Peyton Jones Date: Mon Jun 25 17:42:57 2018 +0100 Fix TcLevel manipulation in TcDerivInfer.simplifyDeriv The level numbers we were getting simply didn't obey the invariant (ImplicInv) in TcType Note [TcLevel and untouchable type variables] That leads to chaos. Easy to fix. I improved the documentation. I also added an assertion in TcSimplify that checks that level numbers go up by 1 as we dive inside implications, so that we catch the problem at source rather than than through its obscure consequences. That in turn showed up that TcRules was also generating constraints that didn't obey (ImplicInv), so I fixed that too. I have no idea what consequences were lurking behing that bug, but anyway now it's fixed. Hooray. }}} Are we done now? (Once Ryan has committed the stuff in comment:31.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 11:20:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 11:20:31 -0000 Subject: [GHC] #14980: Runtime performance regression with binary operations on vectors In-Reply-To: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> References: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> Message-ID: <060.c89935c993d01ed31218d3da58e659bd@haskell.org> #14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: vector | bitwise operations 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): If the badness is only for a particular stack LTS, I wonder if the badness will go away in the next stack LTS and we can declare this ticket moot? I'd suggest the next thing to investigate: do a profiled build and see where the factor of 100 is going. It's such a huge change it should be blindingly obvious :-). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 12:05:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 12:05:39 -0000 Subject: [GHC] #15312: getChanContents exception behavior seems a bit odd In-Reply-To: <045.12177ba1b6d5f9a9adf57d73b0a776a1@haskell.org> References: <045.12177ba1b6d5f9a9adf57d73b0a776a1@haskell.org> Message-ID: <060.a34e624170b36c896749ad7a9c44a2d3@haskell.org> #15312: getChanContents exception behavior seems a bit odd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.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 simonmar): Yeah, this is tricky stuff. We have special handling for async exceptions in the IO library, see `Note [async]` in `GHC.IO.Handle.Internals`. Note that since you threw `Ex` as an async exception, it should really be a child of `AsyncException` in the exception hierarchy, because we use that assumption when handling async exceptions differently. (it wouldn't have made a difference with your code though). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 12:24:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 12:24:24 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.8286df0a751ae321b81fe7194e11ebf6@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15290, T15290a Blocked By: | Blocking: 9123 Related Tickets: | Differential Rev(s): Phab:D4895 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:32 simonpj]: > Are we done now? I certainly hope so! :) I've rebased Phab:D4895 on top of your most recent changes, so that should wrap things up on this ticket. Another question remains of what to do with #9123, which requests that `GeneralizedNewtypeDeriving` emit quantified constraints involving `Coercible`. But this ticket shows that doing so often leads to disaster. In light of this, should we close #9123 as wontfix? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 12:28:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 12:28:31 -0000 Subject: [GHC] #15195: Merge -XPolyKinds with -XTypeInType In-Reply-To: <047.c44c81564ca3186b8f7d6c799db31ecf@haskell.org> References: <047.c44c81564ca3186b8f7d6c799db31ecf@haskell.org> Message-ID: <062.21a8d366cb5af2a08d634831a4d935a3@haskell.org> #15195: Merge -XPolyKinds with -XTypeInType -------------------------------------+------------------------------------- Reporter: goldfire | Owner: int-index Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: GHCProposal, | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4748 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: GHCProposal => GHCProposal, TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 12:33:00 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 12:33:00 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.48ac9c3246ea2d26c5496baac6d49903@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15290, T15290a Blocked By: | Blocking: 9123 Related Tickets: | Differential Rev(s): Phab:D4895 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): As comment:63 says (on #9123) I don't think we should ever infer quantified constraints, regardless of this ticket. So I'm fine with closing #9123 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 12:34:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 12:34:15 -0000 Subject: [GHC] #13790: GHC doesn't reduce type family in kind signature unless its arm is twisted In-Reply-To: <050.82fd0d8f15c203df7dc458114ed0312c@haskell.org> References: <050.82fd0d8f15c203df7dc458114ed0312c@haskell.org> Message-ID: <065.ee21f0e74e83950efcd80bba9fca4335@haskell.org> #13790: GHC doesn't reduce type family in kind signature unless its arm is twisted -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Keywords: TypeInType, Resolution: duplicate | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12088 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #12088 Comment: Closing as a duplicate of #12088. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 12:45:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 12:45:01 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.b20f89739eafcaa41e91350235f73a01@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.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:D4783 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgillespie): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 12:59:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 12:59:52 -0000 Subject: [GHC] #15235: GHCi's claim of infixr 0 (->) is a lie In-Reply-To: <050.1dea13c2dffcf4fb3726d468418c6455@haskell.org> References: <050.1dea13c2dffcf4fb3726d468418c6455@haskell.org> Message-ID: <065.0472757e32b002fa167e00364c218be5@haskell.org> #15235: GHCi's claim of infixr 0 (->) is a lie -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15236 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I don't think it matters much, so I'd be inclined to do whatever is least work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 13:02:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 13:02:11 -0000 Subject: [GHC] #15235: GHCi's claim of infixr 0 (->) is a lie In-Reply-To: <050.1dea13c2dffcf4fb3726d468418c6455@haskell.org> References: <050.1dea13c2dffcf4fb3726d468418c6455@haskell.org> Message-ID: <065.daa95a7f8e8b246747f5124c5dde7aa5@haskell.org> #15235: GHCi's claim of infixr 0 (->) is a lie -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15236 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => newcomer Comment: Sounds good to me. This would be a good task for someone wanting to get involved with GHC development, so I'll mark this as a newcomer ticket. All you'd need to do is apply the change in comment:4, and include a comment explaining why this negative fixity is used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 14:20:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 14:20:10 -0000 Subject: [GHC] #14980: Runtime performance regression with binary operations on vectors In-Reply-To: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> References: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> Message-ID: <060.f1a0079b3d18704b1320881a61963a18@haskell.org> #14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: vector | bitwise operations 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 tdammers): Profiled builds don't seem to reveal much, because as soon as I enable profiling, the performance difference between LTS 9 / GHC 8.0.2 and LTS 11 / GHC 8.2.2 disappears almost entirely - in fact, a profiling build from LTS 9 is *slower* than one from LTS 11. Profile output from LTS 9: {{{ Tue Jun 26 16:12 2018 Time and Allocation Profiling Report (Final) performance-bug-2 +RTS -p -RTS total time = 28.28 secs (28277 ticks @ 1000 us, 1 processor) total alloc = 24,003,734,896 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc >>= Data.Vector.Fusion.Util Data/Vector/Fusion/Util.hs:36:3-18 12.4 19.9 compile'.\ Main performance- bug-2.hs:40:22-33 11.4 4.3 basicUnsafeIndexM Data.Vector.Primitive Data/Vector/Primitive.hs:222:3-75 10.9 16.1 matchPacked Main performance- bug-2.hs:(108,1)-(111,27) 8.8 11.0 uniform System.Random.MWC System/Random/MWC.hs:217:5-33 8.7 15.0 basicUnsafeIndexM Data.Vector.Unboxed.Base Data/Vector/Unboxed/Base.hs:266:841-899 6.6 0.0 matchPacked.go Main performance- bug-2.hs:(110,5)-(111,27) 3.7 0.4 >>= Data.Vector.Fusion.Util Data/Vector/Fusion/Util.hs:50:3-19 3.3 2.6 getOverhead Criterion.Monad Criterion/Monad.hs:(47,1)-(56,12) 3.3 0.0 basicUnsafeWrite Data.Vector.Primitive.Mutable Data/Vector/Primitive/Mutable.hs:115:3-69 2.7 2.3 basicUnsafeIndexM Data.Vector.Unboxed.Base Data/Vector/Unboxed/Base.hs:345:3-73 2.6 11.2 matched.matches Main performance- bug-2.hs:28:5-27 2.4 0.0 basicUnsafeIndexM Data.Vector.Unboxed.Base internal/unbox-tuple- instances:(452,3)-(458,29) 2.2 0.0 compile' Main performance- bug-2.hs:40:1-33 1.7 0.0 compile.cc Main performance- bug-2.hs:37:5-28 1.6 0.0 getGCStats Criterion.Measurement Criterion/Measurement.hs:(46,1)-(48,16) 1.5 0.0 matched Main performance- bug-2.hs:(23,1)-(29,23) 1.5 2.4 basicLength Data.Vector.Unboxed.Base Data/Vector/Unboxed/Base.hs:343:3-42 1.1 0.0 fmap Data.Vector.Fusion.Stream.Monadic Data/Vector/Fusion/Stream/Monadic.hs:(133,3)-(135,20) 0.7 1.0 toPacked4.inst Main performance- bug-2.hs:88:5-26 0.6 1.1 pack64bit Main performance- bug-2.hs:(59,1)-(62,23) 0.6 1.8 }}} And LTS 11: {{{ Tue Jun 26 14:26 2018 Time and Allocation Profiling Report (Final) performance-bug-2 +RTS -p -RTS total time = 23.79 secs (23791 ticks @ 1000 us, 1 processor) total alloc = 17,329,594,624 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc >>= Data.Vector.Fusion.Util Data/Vector/Fusion/Util.hs:36:3-18 19.4 26.9 basicUnsafeIndexM Data.Vector.Primitive Data/Vector/Primitive.hs:222:3-75 14.8 18.3 compile'.\ Main performance- bug-2.hs:40:22-33 13.0 5.0 matchPacked Main performance- bug-2.hs:(108,1)-(111,27) 7.2 8.6 >>= Data.Vector.Fusion.Util Data/Vector/Fusion/Util.hs:50:3-19 4.2 3.0 basicUnsafeIndexM Data.Vector.Unboxed.Base Data/Vector/Unboxed/Base.hs:266:841-899 3.9 0.0 matchPacked.go Main performance- bug-2.hs:(110,5)-(111,27) 3.4 0.4 primitive Control.Monad.Primitive Control/Monad/Primitive.hs:178:3-16 3.2 0.2 basicUnsafeIndexM Data.Vector.Unboxed.Base Data/Vector/Unboxed/Base.hs:345:3-73 2.9 13.2 matched.matches Main performance- bug-2.hs:28:5-27 2.7 0.0 uniform System.Random.MWC System/Random/MWC.hs:217:5-33 2.0 0.9 matched Main performance- bug-2.hs:(23,1)-(29,23) 2.0 2.8 basicUnsafeIndexM Data.Vector.Unboxed.Base internal/unbox-tuple- instances:(452,3)-(458,29) 1.8 0.0 compile' Main performance- bug-2.hs:40:1-33 1.7 0.0 basicUnsafeWrite Data.Vector.Primitive.Mutable Data/Vector/Primitive/Mutable.hs:115:3-69 1.5 4.2 compile.cc Main performance- bug-2.hs:37:5-28 1.5 0.0 basicLength Data.Vector.Unboxed.Base Data/Vector/Unboxed/Base.hs:343:3-42 1.2 0.0 toPacked4.inst Main performance- bug-2.hs:88:5-26 0.9 1.5 basicUnsafeRead Data.Vector.Primitive.Mutable Data/Vector/Primitive/Mutable.hs:112:3-63 0.7 1.7 fmap Data.Vector.Fusion.Stream.Monadic Data/Vector/Fusion/Stream/Monadic.hs:(133,3)-(135,20) 0.7 1.1 take64.(...) Main performance- bug-2.hs:66:17-38 0.6 2.3 }}} And the main culprits are roughly the same, give or take ordering. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 14:25:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 14:25:17 -0000 Subject: [GHC] #14980: Runtime performance regression with binary operations on vectors In-Reply-To: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> References: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> Message-ID: <060.5ffd49d3b8ec66837e82e5d477e32239@haskell.org> #14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: vector | bitwise operations 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 tdammers): Replying to [comment:13 simonpj]: > If the badness is only for a particular stack LTS, I wonder if the badness will go away in the next stack LTS and we can declare this ticket moot? That would of course be a "beautiful" solution. I could try pinning it down to a specific library, and force that to the newest version in the LTS 11.1 build, see if that makes any difference. Another thing to try would be to create a `cabal.config` with the exact library versions that stack uses; if that reproduces the badness, then it's the libraries, but if it doesn't, then the most likely explanation is that cabal does something wrong. Yet another thing would be to set up two VMs, each of them having only one GHC toolchain installed, one for 8.0.2 and one for 8.2.2, and see if *that* has us reproduce the observed behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 14:26:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 14:26:30 -0000 Subject: [GHC] #14980: Runtime performance regression with binary operations on vectors In-Reply-To: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> References: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> Message-ID: <060.d02ad16afd805459ff1a67942dd740a7@haskell.org> #14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: vector | bitwise operations 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 ttylec): Indeed, sorry I didn't write earlier. But enabling profiling kills the performance boost. I suspect that the order-of-magnitude speedup is due to some really low level optimization. When the analogous code is run as a part of bigger code, the `unboxed vector` version scales across cores linearly up to 20 sth cores, while the `binary packed` does not scale linearly even with 2 cores. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 14:36:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 14:36:29 -0000 Subject: [GHC] #14980: Runtime performance regression with binary operations on vectors In-Reply-To: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> References: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> Message-ID: <060.ba6787844e1d0ac6ca7efaa8571cb176@haskell.org> #14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: vector | bitwise operations 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 ttylec): Moreover, I try to reproduce my previous results (I had plan to switch to hs-gauge from criterion to lighten dependencies) and now I cannot reproduce results on my machine (?!). I consistently get order-of-magnitude speedup with ghc-8.0.2, ghc-8.2.2 (from lts-11.1 and lts-11.15) as well as ghc-8.4.3 (nightly snapshot). I try to figure out what changed... and the only difference I find is the fact that I installed newest ubuntu in mean time. And I have newer version of `stack` tool. This is totally confusing. GHC is installed by stack from binaries too... but I guess that packages tagged with version number don't change in time. BTW, times I get currently: {{{ (zettafox) ➜ ghc-bug stack exec performance-bug-pair-2 "Generated" benchmarking 64 columns/raw unbox vectors time 377.3 μs (372.6 μs .. 383.3 μs) 0.998 R² (0.996 R² .. 0.999 R²) mean 379.4 μs (375.5 μs .. 387.9 μs) std dev 19.02 μs (12.01 μs .. 30.94 μs) variance introduced by outliers: 46% (moderately inflated) benchmarking 64 columns/binary packed time 21.32 μs (21.20 μs .. 21.45 μs) 1.000 R² (0.999 R² .. 1.000 R²) mean 21.21 μs (21.10 μs .. 21.35 μs) std dev 426.0 ns (334.1 ns .. 567.0 ns) variance introduced by outliers: 18% (moderately inflated) benchmarking 256 columns/raw unbox vectors time 373.3 μs (366.7 μs .. 381.9 μs) 0.997 R² (0.994 R² .. 0.999 R²) mean 368.1 μs (365.6 μs .. 374.9 μs) std dev 12.72 μs (8.188 μs .. 22.90 μs) variance introduced by outliers: 29% (moderately inflated) benchmarking 256 columns/binary packed time 27.32 μs (27.14 μs .. 27.53 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 27.30 μs (27.16 μs .. 27.49 μs) std dev 535.0 ns (432.6 ns .. 704.7 ns) variance introduced by outliers: 17% (moderately inflated) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 14:45:00 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 14:45:00 -0000 Subject: [GHC] #15308: Error message prints explicit kinds when it shouldn't In-Reply-To: <050.8a60180d637a0d8f09dfd184e0f165b6@haskell.org> References: <050.8a60180d637a0d8f09dfd184e0f165b6@haskell.org> Message-ID: <065.a6a3d3ffd81072d560b3079837bba636@haskell.org> #15308: Error message prints explicit kinds when it shouldn't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 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): Phab:D4891 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"3d002087dce9c61932dd17047902baa83581f4df/ghc" 3d00208/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3d002087dce9c61932dd17047902baa83581f4df" Add commnent about binder order ...provoked by Trac #15308 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 17:34:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 17:34:01 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.3ff5d82b7c427fd119612311e6a8f4a7@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15290, T15290a Blocked By: | Blocking: 9123 Related Tickets: | Differential Rev(s): Phab:D4895 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 17:34:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 17:34:56 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.7278d90f2da5b67401e4706848eec05a@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15290, T15290a Blocked By: | Blocking: 9123 Related Tickets: | Differential Rev(s): Phab:D4895 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm putting this in merge state since there are already a few patches that need to be backported. However, the issue here isn't quite fixed until Phab:D4895 is merged to `master`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 18:35:00 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 18:35:00 -0000 Subject: [GHC] #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints Message-ID: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- First of all this piece of code: {{{#!hs {-# LANGUAGE RankNTypes, QuantifiedConstraints #-} -- NB: disabling these if enabled: {-# LANGUAGE NoUndecidableInstances, NoUndecidableSuperClasses #-} import Data.Proxy class Class a where method :: a subsume :: (Class a => Class b) => Proxy a -> Proxy b -> ((Class a => Class b) => r) -> r subsume _ _ x = x value :: Proxy a -> a value p = subsume p p method }}} This produces a nonterminating `value` even though nothing warranting recursion was used. Adding: {{{#!hs value' :: Class a => Proxy a -> a value' p = subsume p p method }}} Produces a `value'` that is legitimately equivalent to `method` in that it equals to the value in the dictionary whenever an instance exists (and doesn't typecheck otherwise). Thus two identical expressions in different instance contexts end up having different values (violating coherence?) If we add: {{{#!hs joinSubsume :: Proxy a -> ((Class a => Class a) => r) -> r joinSubsume p x = subsume p p x }}} The fact that this typechecks suggests that GHC is able to infer `Class a => Class a` at will, which doesn't seem wrong. However, the fact that `Class a` is solved from `Class a => Class a` via an infinite loop of implication constraints is questionable. Probably even outright wrong in absence of `UndecidableInstances`. Another issue is the following: {{{#!hs {-# LANGUAGE ConstraintKinds #-} subsume' :: Proxy c -> ((c => c) => r) -> r subsume' _ x = x }}} {{{ • Reduction stack overflow; size = 201 When simplifying the following type: c Use -freduction-depth=0 to disable this check (any upper bound you could choose might fail unpredictably with minor updates to GHC, so disabling the check is recommended if you're sure that type checking should terminate) • In the type signature: subsume' :: Proxy c -> ((c => c) => r) -> r }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jun 26 18:53:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Jun 2018 18:53:53 -0000 Subject: [GHC] #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints In-Reply-To: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> References: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> Message-ID: <059.bc08fbf3708844a361ed4acda852382d@haskell.org> #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints 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 mniip): * version: 8.4.3 => 8.5 Comment: This is actually for version `8.6.0` but there isn't such an option in the box... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 01:03:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 01:03:02 -0000 Subject: [GHC] #14506: Configure Harbormaster to trigger CircleCI builds In-Reply-To: <046.9f61d9ef87c94b26144834dd33459a90@haskell.org> References: <046.9f61d9ef87c94b26144834dd33459a90@haskell.org> Message-ID: <061.9844b681458ad968fd1665fb3ff722b8@haskell.org> #14506: Configure Harbormaster to trigger CircleCI builds -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Continuous | Version: 8.2.1 Integration | 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 => high * owner: bgamari => alpmestan * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 01:08:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 01:08:38 -0000 Subject: [GHC] #14470: CircleCI: Detect number of processors In-Reply-To: <046.012116c89dd22a1fbfc06a0f6d331f82@haskell.org> References: <046.012116c89dd22a1fbfc06a0f6d331f82@haskell.org> Message-ID: <061.5e6cf92356241c1017b57f99da6adb16@haskell.org> #14470: CircleCI: Detect number of processors -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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 alpmestan): * cc: alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 01:15:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 01:15:32 -0000 Subject: [GHC] #14470: CircleCI: Detect number of processors In-Reply-To: <046.012116c89dd22a1fbfc06a0f6d331f82@haskell.org> References: <046.012116c89dd22a1fbfc06a0f6d331f82@haskell.org> Message-ID: <061.ce35f2e3cd17dd3e4617b8891fd26e7c@haskell.org> #14470: CircleCI: Detect number of processors -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: patch Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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:D4897 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * cc: alpmestan (removed) * differential: => Phab:D4897 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 01:15:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 01:15:48 -0000 Subject: [GHC] #14470: CircleCI: Detect number of processors In-Reply-To: <046.012116c89dd22a1fbfc06a0f6d331f82@haskell.org> References: <046.012116c89dd22a1fbfc06a0f6d331f82@haskell.org> Message-ID: <061.dacd032e6616a17f6c063cebd33dfa10@haskell.org> #14470: CircleCI: Detect number of processors -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Continuous | Version: 8.2.1 Integration | 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:D4897 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: alpmestan (added) * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 02:11:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 02:11:24 -0000 Subject: [GHC] #15314: Internal error during typechecking of a hole in GHCi when there's shadowed identifiers In-Reply-To: <044.a38cb36cce530ca78b0769c47739ba35@haskell.org> References: <044.a38cb36cce530ca78b0769c47739ba35@haskell.org> Message-ID: <059.2ed429b206cc27a4e1baf301b93d357d@haskell.org> #15314: Internal error during typechecking of a hole in GHCi when there's shadowed identifiers -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #15007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * status: new => closed * resolution: => duplicate * related: => #15007 Comment: I believe this ticket describes the same bug with #15007. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 04:52:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 04:52:10 -0000 Subject: [GHC] #15317: GHCi panic when trying to avoid GHC_OPTIONS -O warning Message-ID: <047.dc7093c3a8f78101be6e2b09f20a4da3@haskell.org> #15317: GHCi panic when trying to avoid GHC_OPTIONS -O warning -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 7.10.4 Component: GHCi | 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: -------------------------------------+------------------------------------- Following the advice on [https://stackoverflow.com/a/27881726/7208029 an answer to "How can I load optimized code in GHCI?"], I get a GHCi panic. Running `ghc Luhn` succeeds just fine. On running `ghci Luhn`, I get: {{{ $ ghci Luhn GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Luhn ( Luhn.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): floatExpr tick break<15>() Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Contents of `Luhn.hs`: {{{#!hs {-# OPTIONS_GHC -fobject-code -O3 #-} module Luhn (checkLuhn) where import Data.Bits (shiftL) import Data.Char (digitToInt) import Data.List (foldl') -- Quickly gets a list of digits from a nonnegative Integer -- Gives error for negative inputs -- Uses GMP's show for greatly-improved speed over GMP's div and mod toDigits :: Integer -> [Int] {-# INLINE toDigits #-} toDigits = map digitToInt . show -- Quickly gets the same result as iteratively getting the digit sum of a nonnegative Int until the digit sum is only one digit long -- Gives an erroneous value for negative inputs repeatedDigitSum :: Int -> Int {-# INLINE repeatedDigitSum #-} repeatedDigitSum n = (n - 1) `rem` 9 + 1 -- Gets the Luhn sum, which is zero for valid inputs, of a list of digits -- Uses Data.Bits.shiftL to quickly double luhnSum :: [Int] -> Int {-# INLINE luhnSum #-} luhnSum = fromInteger . flip rem 10 . foldl' (+) 0 . zipWith ($) (cycle [toInteger, toInteger . repeatedDigitSum . flip shiftL 1]) -- Checks whether a nonnegative Integer passes the Luhn algorithm -- Negative inputs are False, since the Luhn algorithm is intended for unsigned inputs checkLuhn :: Integer -> Bool {-# INLINABLE checkLuhn #-} checkLuhn n = (n >= 0) && ((== 0) . luhnSum . reverse . toDigits) n }}} Strangely, `ghci -fobject-code -O3 Luhn` works just great, so apparently it's not a problem with the switches? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 05:22:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 05:22:35 -0000 Subject: [GHC] #15317: GHCi panic when trying to avoid GHC_OPTIONS -O warning In-Reply-To: <047.dc7093c3a8f78101be6e2b09f20a4da3@haskell.org> References: <047.dc7093c3a8f78101be6e2b09f20a4da3@haskell.org> Message-ID: <062.72d80ff1c25d2cf38e3704681e330ad0@haskell.org> #15317: GHCi panic when trying to avoid GHC_OPTIONS -O warning -------------------------------+-------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 7.10.4 Component: GHCi | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by ChaiTRex): * failure: None/Unknown => GHCi crash * os: Unknown/Multiple => Linux * architecture: Unknown/Multiple => x86_64 (amd64) Old description: > Following the advice on [https://stackoverflow.com/a/27881726/7208029 an > answer to "How can I load optimized code in GHCI?"], I get a GHCi panic. > Running `ghc Luhn` succeeds just fine. On running `ghci Luhn`, I get: > {{{ > $ ghci Luhn > GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Luhn ( Luhn.hs, interpreted ) > ghc: panic! (the 'impossible' happened) > (GHC version 7.10.3 for x86_64-unknown-linux): > floatExpr tick break<15>() > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > Contents of `Luhn.hs`: > {{{#!hs > {-# OPTIONS_GHC -fobject-code -O3 #-} > > module Luhn (checkLuhn) where > > import Data.Bits (shiftL) > import Data.Char (digitToInt) > import Data.List (foldl') > > -- Quickly gets a list of digits from a nonnegative Integer > -- Gives error for negative inputs > -- Uses GMP's show for greatly-improved speed over GMP's div and mod > toDigits :: Integer -> [Int] > {-# INLINE toDigits #-} > toDigits = map digitToInt . show > > -- Quickly gets the same result as iteratively getting the digit sum of a > nonnegative Int until the digit sum is only one digit long > -- Gives an erroneous value for negative inputs > repeatedDigitSum :: Int -> Int > {-# INLINE repeatedDigitSum #-} > repeatedDigitSum n = (n - 1) `rem` 9 + 1 > > -- Gets the Luhn sum, which is zero for valid inputs, of a list of digits > -- Uses Data.Bits.shiftL to quickly double > luhnSum :: [Int] -> Int > {-# INLINE luhnSum #-} > luhnSum = fromInteger . flip rem 10 . foldl' (+) 0 . zipWith ($) (cycle > [toInteger, toInteger . repeatedDigitSum . flip shiftL 1]) > > -- Checks whether a nonnegative Integer passes the Luhn algorithm > -- Negative inputs are False, since the Luhn algorithm is intended for > unsigned inputs > checkLuhn :: Integer -> Bool > {-# INLINABLE checkLuhn #-} > checkLuhn n = (n >= 0) && ((== 0) . luhnSum . reverse . toDigits) n > }}} > > Strangely, `ghci -fobject-code -O3 Luhn` works just great, so apparently > it's not a problem with the switches? New description: Following the advice on [https://stackoverflow.com/a/27881726/7208029 an answer to "How can I load optimized code in GHCI?"], I get a GHCi panic. Running `ghc Luhn` succeeds just fine. On running `ghci Luhn`, I get: {{{ $ ghci Luhn GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Luhn ( Luhn.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): floatExpr tick break<15>() Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Contents of `Luhn.hs`: {{{#!hs {-# OPTIONS_GHC -fobject-code -O3 #-} module Luhn (checkLuhn) where import Data.Bits (shiftL) import Data.Char (digitToInt) import Data.List (foldl') -- Quickly gets a list of digits from a nonnegative Integer -- Gives error for negative inputs -- Uses GMP's show for greatly-improved speed over GMP's div and mod toDigits :: Integer -> [Int] {-# INLINE toDigits #-} toDigits = map digitToInt . show -- Quickly gets the same result as iteratively getting the digit sum of a nonnegative Int until the digit sum is only one digit long -- Gives an erroneous value for negative inputs repeatedDigitSum :: Int -> Int {-# INLINE repeatedDigitSum #-} repeatedDigitSum n = (n - 1) `rem` 9 + 1 -- Gets the Luhn sum, which is zero for valid inputs, of a list of digits -- Uses Data.Bits.shiftL to quickly double luhnSum :: [Int] -> Int {-# INLINE luhnSum #-} luhnSum = fromInteger . flip rem 10 . foldl' (+) 0 . zipWith ($) (cycle [toInteger, toInteger . repeatedDigitSum . flip shiftL 1]) -- Checks whether a nonnegative Integer passes the Luhn algorithm -- Negative inputs are False, since the Luhn algorithm is intended for unsigned inputs checkLuhn :: Integer -> Bool {-# INLINABLE checkLuhn #-} checkLuhn n = (n >= 0) && ((== 0) . luhnSum . reverse . toDigits) n }}} Strangely, `ghci -fobject-code -O3 Luhn` works just great, so apparently it's not a problem with the switches? ---- `ghc --version`: {{{ The Glorious Glasgow Haskell Compilation System, version 7.10.3 }}} Ubuntu (and presumably Debian) package information: {{{ ghc: Installed: 7.10.3-7 Candidate: 7.10.3-7 Version table: *** 7.10.3-7 500 500 http://mirror.atlantic.net/ubuntu xenial/universe amd64 Packages 100 /var/lib/dpkg/status }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 06:22:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 06:22:30 -0000 Subject: [GHC] #15221: failure to build pandoc on Debian armhf In-Reply-To: <044.c95e2449a6d05724dcf3491a30d3f9d3@haskell.org> References: <044.c95e2449a6d05724dcf3491a30d3f9d3@haskell.org> Message-ID: <059.20b2952d6caeca9ea66b4e50f9e5bece@haskell.org> #15221: failure to build pandoc on Debian armhf ---------------------------------+------------------------------ Reporter: clint | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Changes (by LocutusOfBorg): * status: infoneeded => closed * resolution: => fixed Comment: A simple rebuild made it build correctly... Maybe we can close this one? I would close this one, lets reopen in case somebody still get this issue -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 07:09:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 07:09:46 -0000 Subject: [GHC] #14980: Runtime performance regression with binary operations on vectors In-Reply-To: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> References: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> Message-ID: <060.2e9661dca2e430ce2077a4dfaf125f70@haskell.org> #14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: vector | bitwise operations 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 tdammers): One thing to try would be to delete `~/.stack` and `~/.stack-work` between builds. This should give you a clean slate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 08:51:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 08:51:59 -0000 Subject: [GHC] #14980: Runtime performance regression with binary operations on vectors In-Reply-To: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> References: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> Message-ID: <060.c8ae027545c551b0f4b4f83d3e1572ec@haskell.org> #14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: vector | bitwise operations 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 tdammers): Speaking of clean slates; I just noticed that `$PATH` can mess up the testing, because stack defaults to installing binaries into `~/.local/bin/`, while cabal installs either into `~/.cabal/bin` (if no sandbox is used), or into `./.cabal-sandbox/bin` (if a sandbox is used). So you have to be careful to make sure you're running the correct binary, and just relying on `$PATH` might explain while switching between configurations or build tools might appear to leave some residue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 09:33:09 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 09:33:09 -0000 Subject: [GHC] #14980: Runtime performance regression with binary operations on vectors In-Reply-To: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> References: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> Message-ID: <060.eb36b08856b129975d1defa0754b70a9@haskell.org> #14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: vector | bitwise operations 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 tdammers): Another data point: I dumped stack's `cabal.config` for the LTS 11.1 release into my cabal project and compiled with `--with- compiler=/usr/local/bin/ghc-8.2.2`, and the result I'm getting is this: {{{ "Generated" benchmarking 64 columns/raw unbox vectors time 460.0 μs (447.0 μs .. 473.6 μs) 0.995 R² (0.992 R² .. 0.997 R²) mean 446.4 μs (440.2 μs .. 455.1 μs) std dev 24.42 μs (17.29 μs .. 31.22 μs) variance introduced by outliers: 48% (moderately inflated) benchmarking 64 columns/binary packed time 52.25 μs (51.66 μs .. 53.04 μs) 0.998 R² (0.997 R² .. 0.999 R²) mean 52.60 μs (51.99 μs .. 53.67 μs) std dev 2.665 μs (1.919 μs .. 4.073 μs) variance introduced by outliers: 55% (severely inflated) benchmarking 256 columns/raw unbox vectors time 439.9 μs (434.4 μs .. 447.4 μs) 0.998 R² (0.997 R² .. 1.000 R²) mean 439.0 μs (435.0 μs .. 446.4 μs) std dev 17.95 μs (10.79 μs .. 27.38 μs) variance introduced by outliers: 35% (moderately inflated) benchmarking 256 columns/binary packed time 304.7 μs (288.7 μs .. 330.4 μs) 0.965 R² (0.940 R² .. 0.998 R²) mean 324.1 μs (302.9 μs .. 364.4 μs) std dev 62.33 μs (26.19 μs .. 97.61 μs) variance introduced by outliers: 91% (severely inflated) }}} However, I'm getting the same bad behavior when I pin libraries to LTS 11.15, and also when I don't pin libraries at all. So it's not the libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 10:20:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 10:20:07 -0000 Subject: [GHC] #10789: Notify user when a kind mismatch holds up a type family reduction In-Reply-To: <047.282dd8bb976bc76373d556a5e980ac6e@haskell.org> References: <047.282dd8bb976bc76373d556a5e980ac6e@haskell.org> Message-ID: <062.b0e0befedced9e93cc1153ee5ee6f1a3@haskell.org> #10789: Notify user when a kind mismatch holds up a type family reduction -------------------------------------+------------------------------------- Reporter: goldfire | Owner: v0d1ch Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomer, | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13192 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by v0d1ch): I have determined that in the failure case in this specific example we want the `Role` to be `Nominal` and we get a `[Type]` that looks like this: `[* -> *, Maybe]` while the `TyCon` is `F` How would I precede further with these informations ? I am also wondering if I should introduce new type that will give us the option to customize failure message instead of just `Nothing` ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 10:26:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 10:26:25 -0000 Subject: [GHC] #14980: Runtime performance regression with binary operations on vectors In-Reply-To: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> References: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> Message-ID: <060.6b384eb4aacaad3796b4f5ed975ffeb4@haskell.org> #14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: vector | bitwise operations 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 tdammers): Performed an evil experiment: I put the `cabal.config` from LTS-11.1 into the project, then compiled with cabal, forcing the compiler to 8.0.2. Behavior is "good" (i.e., the 4th benchmark is in the 20-40 μs range. I also get the "good" behavior when compiling with 8.0.2, but without pinning. So it's definitely not the libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 10:48:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 10:48:27 -0000 Subject: [GHC] #14980: Runtime performance regression with binary operations on vectors In-Reply-To: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> References: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> Message-ID: <060.23f29a2af72f6582dfae6896e88bfe30@haskell.org> #14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: vector | bitwise operations 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 ttylec): Replying to [comment:20 tdammers]: This is not totally "bad" behavior. This: > {{{ > "Generated" > benchmarking 64 columns/raw unbox vectors > time 460.0 μs (447.0 μs .. 473.6 μs) > 0.995 R² (0.992 R² .. 0.997 R²) > mean 446.4 μs (440.2 μs .. 455.1 μs) > std dev 24.42 μs (17.29 μs .. 31.22 μs) > variance introduced by outliers: 48% (moderately inflated) > > benchmarking 64 columns/binary packed > time 52.25 μs (51.66 μs .. 53.04 μs) > 0.998 R² (0.997 R² .. 0.999 R²) > mean 52.60 μs (51.99 μs .. 53.67 μs) > std dev 2.665 μs (1.919 μs .. 4.073 μs) > variance introduced by outliers: 55% (severely inflated) > }}} this is "good", we have significant speedup. But this: > {{{ > benchmarking 256 columns/raw unbox vectors > time 439.9 μs (434.4 μs .. 447.4 μs) > 0.998 R² (0.997 R² .. 1.000 R²) > mean 439.0 μs (435.0 μs .. 446.4 μs) > std dev 17.95 μs (10.79 μs .. 27.38 μs) > variance introduced by outliers: 35% (moderately inflated) > > benchmarking 256 columns/binary packed > time 304.7 μs (288.7 μs .. 330.4 μs) > 0.965 R² (0.940 R² .. 0.998 R²) > mean 324.1 μs (302.9 μs .. 364.4 μs) > std dev 62.33 μs (26.19 μs .. 97.61 μs) > variance introduced by outliers: 91% (severely inflated) > }}} is "bad". However, what I observed with the full code of our project, the speed-up is lost when we exceed the specific number of columns... but that number is platform specific (AMD performs worst, Intel is usually good, but then to MacBook Pro i5 CPU seems to be better than in i7 Lenovo on ubuntu). But since on the same platform you get different results for 256 columns, having speedup in with 64 columns, make me wonder, can the system kernel and/or libraries be affecting that? As for me not being able to reproduce my original report: I did try to remove `~/.stack` and `~/.stack-work`. Tried both with `split-obj` in stack config and without. I still can't get "bad" results on my current hardware/software. I am using only stack, I don't have system-wide GHC. I will try to do more tests on different machine (with debian 9); try the macbook at home too. But to sum up what we know until now: libraries are ruled out, compiler version seems to be ruled out too. What's left? GHC binary package, OS kernel, system libs? Does anything of that make sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 12:16:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 12:16:29 -0000 Subject: [GHC] #14980: Runtime performance regression with binary operations on vectors In-Reply-To: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> References: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> Message-ID: <060.0dd36e8cbeecdad9873f92073333ea58@haskell.org> #14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: vector | bitwise operations 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 tdammers): So, to summarize the results I have so far on my own machine (i5, debian): - The 64 columns version sees massive improvement throughout, on any compiler, and with any set of libraries; however, when the 256-columns version performs badly, the 64-columns version is slower by a factor of about 2 (~50 μs vs. ~25 μs). - Whether the improvement is seen or not does not seem to depend on the libraries - the same set of libraries, when forced with cabal, will sometimes show improvement, and sometimes not. - I have both 8.0.2 and 8.2.2 produce "good" and "bad" behavior; however, some of that may be due to accidentally running the wrong binary. The test runs in which I made absolutely sure I was running the correct binaries, and started with a clean slate, do show that 8.0.2 consistently produces "good" code, while 8.2.2 consistently produces "bad" code. So that leaves us with relatively obscure things. One thing to check would be which exact binaries stack pulls in. The GHC versions may match, but the build configuration might not. Kernel and system libs were all identical between my attempts, so I doubt those play a role. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 12:45:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 12:45:30 -0000 Subject: [GHC] #10965: GHC Panic on import with 'OPTIONS_GHC -fobject-code -O' In-Reply-To: <044.d2359d5edaaed9fe3a9870eb9b625099@haskell.org> References: <044.d2359d5edaaed9fe3a9870eb9b625099@haskell.org> Message-ID: <059.5102f7710d99521dd49bf8d6cbf48cce@haskell.org> #10965: GHC Panic on import with 'OPTIONS_GHC -fobject-code -O' ---------------------------------+-------------------------------------- Reporter: Orome | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10549 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: I cannot reproduce this issue with GHC 8.2 and later, so closing. Please reopen if this still happens for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 12:46:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 12:46:48 -0000 Subject: [GHC] #15317: GHCi panic when trying to avoid GHC_OPTIONS -O warning In-Reply-To: <047.dc7093c3a8f78101be6e2b09f20a4da3@haskell.org> References: <047.dc7093c3a8f78101be6e2b09f20a4da3@haskell.org> Message-ID: <062.a9517aa325a720a4961089f152358151@haskell.org> #15317: GHCi panic when trying to avoid GHC_OPTIONS -O warning -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #10965 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * os: Linux => Unknown/Multiple * related: => #10965 * architecture: x86_64 (amd64) => Unknown/Multiple * milestone: 7.10.4 => * resolution: => duplicate Comment: Thanks for the bug report. This is a duplicate of #10965, which has been fixed, so I recommend upgrading to use GHC 8.2 or later, which does not exhibit this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 14:05:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 14:05:51 -0000 Subject: [GHC] #15318: Core Lint error involving newtype family instances with wrappers Message-ID: <050.5e4047b16b9f07feb6a762d8a4dad8f6@haskell.org> #15318: Core Lint error involving newtype family instances with wrappers -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program gives a Core Lint error on GHC 8.4 and later: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} module Bug where data family Sn a newtype instance Sn (Either a b) where SnC :: forall b a. Char -> Sn (Either a b) }}} {{{ $ /opt/ghc/8.4.3/bin/ghc -dcore-lint Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of Tidy Core *** : warning: [in body of lambda with binder dt_aZm :: Char] From-type of Cast differs from type of enclosed expression From-type: R:SnEither a_auS b_auR Type of enclosed expr: Sn (Either a_auS b_auR) Actual enclosed expr: dt_aZm `cast` (Sym (N:R:SnEither[0] _N _N) ; Sym (D:R:SnEither0[0] _N _N) :: (Char :: *) ~R# (Sn (Either a_auS b_auR) :: *)) Coercion used in cast: Sym (D:R:SnEither0[0] _N _N) *** Offending Program *** $WSnC [InlPrag=INLINE[2]] :: forall b a. Char -> Sn (Either a b) [GblId[DataConWrapper], Arity=1, Caf=NoCafRefs, Str=, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=True) Tmpl= \ (@ b_auR) (@ a_auS) (dt_aZm [Occ=Once] :: Char) -> (dt_aZm `cast` (Sym (N:R:SnEither[0] _N _N) ; Sym (D:R:SnEither0[0] _N _N) :: (Char :: *) ~R# (Sn (Either a_auS b_auR) :: *))) `cast` (Sym (D:R:SnEither0[0] _N _N) :: (R:SnEither a_auS b_auR :: *) ~R# (Sn (Either a_auS b_auR) :: *))}] $WSnC = \ (@ b_auR) (@ a_auS) (dt_aZm [Occ=Once] :: Char) -> (dt_aZm `cast` (Sym (N:R:SnEither[0] _N _N) ; Sym (D:R:SnEither0[0] _N _N) :: (Char :: *) ~R# (Sn (Either a_auS b_auR) :: *))) `cast` (Sym (D:R:SnEither0[0] _N _N) :: (R:SnEither a_auS b_auR :: *) ~R# (Sn (Either a_auS b_auR) :: *)) $trModule1_r10g :: Addr# [GblId, Caf=NoCafRefs] $trModule1_r10g = "main"# $trModule2_r10D :: TrName [GblId, Caf=NoCafRefs] $trModule2_r10D = TrNameS $trModule1_r10g $trModule3_r10E :: Addr# [GblId, Caf=NoCafRefs] $trModule3_r10E = "Bug"# $trModule4_r10F :: TrName [GblId, Caf=NoCafRefs] $trModule4_r10F = TrNameS $trModule3_r10E $trModule :: Module [GblId, Caf=NoCafRefs] $trModule = Module $trModule2_r10D $trModule4_r10F $krep_r10G :: KindRep [GblId] $krep_r10G = KindRepTyConApp $tcChar ([] @ KindRep) $krep1_r10H :: KindRep [GblId, Caf=NoCafRefs] $krep1_r10H = KindRepVar 1# $krep2_r10I :: KindRep [GblId, Caf=NoCafRefs] $krep2_r10I = KindRepVar 0# $krep3_r10J :: [KindRep] [GblId, Caf=NoCafRefs] $krep3_r10J = : @ KindRep $krep2_r10I ([] @ KindRep) $krep4_r10K :: [KindRep] [GblId, Caf=NoCafRefs] $krep4_r10K = : @ KindRep $krep1_r10H $krep3_r10J $krep5_r10L :: KindRep [GblId] $krep5_r10L = KindRepTyConApp $tcEither $krep4_r10K $tcSn1_r10M :: Addr# [GblId, Caf=NoCafRefs] $tcSn1_r10M = "Sn"# $tcSn2_r10N :: TrName [GblId, Caf=NoCafRefs] $tcSn2_r10N = TrNameS $tcSn1_r10M $tcSn :: TyCon [GblId] $tcSn = TyCon 461968091845555535## 16320521938866097056## $trModule $tcSn2_r10N 0# krep$*Arr* $krep6_r10O :: [KindRep] [GblId] $krep6_r10O = : @ KindRep $krep5_r10L ([] @ KindRep) $krep7_r10P :: KindRep [GblId] $krep7_r10P = KindRepTyConApp $tcSn $krep6_r10O $krep8_r10Q :: KindRep [GblId] $krep8_r10Q = KindRepFun $krep_r10G $krep7_r10P $tc'SnC1_r10R :: Addr# [GblId, Caf=NoCafRefs] $tc'SnC1_r10R = "'SnC"# $tc'SnC2_r10S :: TrName [GblId, Caf=NoCafRefs] $tc'SnC2_r10S = TrNameS $tc'SnC1_r10R $tc'SnC :: TyCon [GblId] $tc'SnC = TyCon 3818830880305712792## 17484539998814842835## $trModule $tc'SnC2_r10S 2# $krep8_r10Q *** End of Offense *** : error: Compilation had errors }}} If we look at the Core for `$WSnC`, we see the culprit: {{{ $WSnC = \ (@ b_auR) (@ a_auS) (dt_aZm [Occ=Once] :: Char) -> (dt_aZm `cast` (Sym (N:R:SnEither[0] _N _N) ; Sym (D:R:SnEither0[0] _N _N) :: (Char :: *) ~R# (Sn (Either a_auS b_auR) :: *))) `cast` (Sym (D:R:SnEither0[0] _N _N) :: (R:SnEither a_auS b_auR :: *) ~R# (Sn (Either a_auS b_auR) :: *)) }}} The inner cast goes from `Char` to `Sn (Either a b)`, but then the outer cast goes from `R:SnEither a b` to `Sn (Either a b)`, which is not transitive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 14:19:31 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 14:19:31 -0000 Subject: [GHC] #15318: Core Lint error involving newtype family instances with wrappers In-Reply-To: <050.5e4047b16b9f07feb6a762d8a4dad8f6@haskell.org> References: <050.5e4047b16b9f07feb6a762d8a4dad8f6@haskell.org> Message-ID: <065.998563216f5ddfa441fe439a6e8a6160@haskell.org> #15318: Core Lint error involving newtype family instances with wrappers -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 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: | Differential Rev(s): Phab:D4902 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * differential: => Phab:D4902 Comment: See https://phabricator.haskell.org/D4902 Which is Richard's fix cherry-picked. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 14:28:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 14:28:37 -0000 Subject: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable In-Reply-To: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> References: <044.33251b8e69d1b6796ddff38b98a4991e@haskell.org> Message-ID: <059.a64dc12c764d3bf194685a75b0d8d67e@haskell.org> #4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.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:D4783 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.6.1 Comment: This is already present in 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 14:29:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 14:29:59 -0000 Subject: [GHC] #14164: GHC hangs on type family dependency In-Reply-To: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> References: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> Message-ID: <066.2dfa88f2e9fc8b1b4bddc23e124a75bd@haskell.org> #14164: GHC hangs on type family dependency -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T14164 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.6.1 Comment: This is already present in 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 15:30:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 15:30:08 -0000 Subject: [GHC] #12612: Allow kinds of associated types to depend on earlier associated types In-Reply-To: <051.03b4bda1b1ebc27d0a28baf47d735e88@haskell.org> References: <051.03b4bda1b1ebc27d0a28baf47d735e88@haskell.org> Message-ID: <066.792101c37710f60dd4ebb54608e10a4f@haskell.org> #12612: Allow kinds of associated types to depend on earlier associated types -------------------------------------+------------------------------------- Reporter: davemenendez | 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: #11962 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): For what it's worth, a fix for this would also help simplify some of my code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 16:33:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 16:33:47 -0000 Subject: [GHC] #9383: GHCi parser doesn't properly handle -fobject-code In-Reply-To: <047.e6dcdb9c92c2dfd5d3c445e82b3f94d0@haskell.org> References: <047.e6dcdb9c92c2dfd5d3c445e82b3f94d0@haskell.org> Message-ID: <062.b22d4cf50991de6b210ac1bda346b342@haskell.org> #9383: GHCi parser doesn't properly handle -fobject-code -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > My complete Haskell source: > > module Foo where > f x = x > > Shell: > > $ ghci Foo.hs -fobject-code > GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > target ‘-fobject-code’ is not a module name or a source file > Ok, modules loaded: Linker. > Prelude Linker> > > Despite the wanring/error, GHCi *does* generate the object code. This > error also prints when I *load* the compiled Foo object file. New description: My complete Haskell source: module Foo where f x = x Shell: {{{ $ ghci Foo.hs -fobject-code GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. target ‘-fobject-code’ is not a module name or a source file Ok, modules loaded: Linker. Prelude Linker> }}} Despite the wanring/error, GHCi *does* generate the object code. This error also prints when I *load* the compiled Foo object file. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 19:06:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 19:06:32 -0000 Subject: [GHC] #12449: Broken types in identifiers bound by :print In-Reply-To: <044.542a5d089ce4efa7862430871616a137@haskell.org> References: <044.542a5d089ce4efa7862430871616a137@haskell.org> Message-ID: <059.eb6191056562c687223ec7453ab17bc5@haskell.org> #12449: Broken types in identifiers bound by :print -------------------------------------+------------------------------------- Reporter: mniip | 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: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: Closing as duplicate of #9046. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 19:07:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 19:07:30 -0000 Subject: [GHC] #9046: Panic in GHCi when using :print In-Reply-To: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> References: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> Message-ID: <060.cc65c7864bf6972127e8840c0c2f032c@haskell.org> #9046: Panic in GHCi when using :print -------------------------------------+------------------------------------- Reporter: quchen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: | tests/ghci.debugger/scripts/print036 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): Also reported at #12449 and #15299. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 19:27:16 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 19:27:16 -0000 Subject: [GHC] #12922: Kind classes compile with PolyKinds In-Reply-To: <045.cda8d73aa7f5c75c71cb112094b7aabc@haskell.org> References: <045.cda8d73aa7f5c75c71cb112094b7aabc@haskell.org> Message-ID: <060.4b5705f4778ba82a661537fd36923de2@haskell.org> #12922: Kind classes compile with PolyKinds -------------------------------------+------------------------------------- Reporter: Tritlo | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: wontfix | 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 monoidal): * status: new => closed * resolution: => wontfix Comment: We no longer distinguish between `TypeInType` and `PolyKinds`, so I'm closing this ticket. See https://github.com/ghc-proposals/ghc- proposals/blob/master/proposals/0020-no-type-in-type.rst and #15195 for more details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 19:36:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 19:36:07 -0000 Subject: [GHC] #12922: Kind classes compile with PolyKinds In-Reply-To: <045.cda8d73aa7f5c75c71cb112094b7aabc@haskell.org> References: <045.cda8d73aa7f5c75c71cb112094b7aabc@haskell.org> Message-ID: <060.93886ac54eae66dc233d9c86e68f9abd@haskell.org> #12922: Kind classes compile with PolyKinds -------------------------------------+------------------------------------- Reporter: Tritlo | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: wontfix | 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): Hm... I wonder if we should convert the `TypeInType` Trac keyword to `PolyKinds` as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 19:41:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 19:41:45 -0000 Subject: [GHC] #12922: Kind classes compile with PolyKinds In-Reply-To: <045.cda8d73aa7f5c75c71cb112094b7aabc@haskell.org> References: <045.cda8d73aa7f5c75c71cb112094b7aabc@haskell.org> Message-ID: <060.8bfb0f299ebe24bc6f5961c53f2d8665@haskell.org> #12922: Kind classes compile with PolyKinds -------------------------------------+------------------------------------- Reporter: Tritlo | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: wontfix | 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 monoidal): Technically `TypeInType` also covers `DataKinds`. I wouldn't worry about this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 20:22:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 20:22:37 -0000 Subject: [GHC] #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation In-Reply-To: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> References: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> Message-ID: <061.6512070c9d22d9a3aeb79ffa175213ba@haskell.org> #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation -------------------------------------+------------------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: Resolution: | PatternMatchWarnings 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 RyanGlScott): It's unclear to me what can even be done about this. The GADTs Meet Their Match paper is completely silent on the topic of bang patterns, so this seems like a theory bug, not an implementation one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 20:43:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 20:43:02 -0000 Subject: [GHC] #14231: Core lint error "in result of Static argument" In-Reply-To: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> References: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> Message-ID: <064.b9a6b6081d8c13a54939feb530a67cc4@haskell.org> #14231: Core lint error "in result of Static argument" -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | 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: | -------------------------------------+------------------------------------- Comment (by monoidal): Simplification of the bug report: {{{ module Async where bindWith :: (a -> a) -> a -> a bindWith k f = k (bindWith k f) }}} and as previously `ghc -O2 -fno-worker-wrapper -fstatic-argument- transformation -dcore-lint`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jun 27 22:14:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Jun 2018 22:14:57 -0000 Subject: [GHC] #11024: Fix strange parsing of BooleanFormula In-Reply-To: <049.1026878f17212bef28601e22c8ebf782@haskell.org> References: <049.1026878f17212bef28601e22c8ebf782@haskell.org> Message-ID: <064.03c7181651d59e591a638fdad9c63129@haskell.org> #11024: Fix strange parsing of BooleanFormula -------------------------------------+------------------------------------- Reporter: mpickering | Owner: ethercrow Type: task | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | 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: | https://phabricator.haskell.org/D3139 -------------------------------------+------------------------------------- Comment (by monoidal): Should this ticket be closed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 04:28:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 04:28:49 -0000 Subject: [GHC] #10789: Notify user when a kind mismatch holds up a type family reduction In-Reply-To: <047.282dd8bb976bc76373d556a5e980ac6e@haskell.org> References: <047.282dd8bb976bc76373d556a5e980ac6e@haskell.org> Message-ID: <062.fd5ce855a7ed9f04e4b66c478147e959@haskell.org> #10789: Notify user when a kind mismatch holds up a type family reduction -------------------------------------+------------------------------------- Reporter: goldfire | Owner: v0d1ch Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomer, | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13192 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): > How would I proceed further with these informations ? Not quite sure how to answer this. You might need to continue tracing the code path into `tcMatchTys`. > > I am also wondering if I should introduce new type that will give us the option to customize failure message instead of just `Nothing` ? Yes, I think so. For example, instead of `Nothing`, maybe it would work well to return an `Int` that gives the index of the first argument that mismatches. Then, the error-message generator could see if that index corresponds to an invisible argument; if so, suggest `-fprint-explicit- kinds`. Perhaps there's a better design, as well. > -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 05:01:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 05:01:07 -0000 Subject: [GHC] #9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.3c348cb952bb6d90a6006eb888d3715b@haskell.org> #9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Roles, Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T9123{,a} Blocked By: 15290 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Perhaps comment:63 is right. Would it be worth special-casing role-related quantified constraints in GND? These would be easy to spot -- you just look for a type variable used as an argument to another type variable. So I claim it's doable, without really inferring the constraint using GHC's normal inference mechanism. Why do I care? Because it seems putting `join` into `Monad` is a good idea, and GND'ing `Monad` is common, and sometimes doing so will require a quantified constraint. Not inferring it will cause pain for users who just want a `Monad` but don't want to get sucked into the roles swamp. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 08:10:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 08:10:53 -0000 Subject: [GHC] #9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.78000faf7085b0b0d57467b8f8b84e30@haskell.org> #9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Roles, Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T9123{,a} Blocked By: 15290 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > These would be easy to spot -- you just look for a type variable used as an argument to another type variable I'd say "possible" rather than "easy". You'd have something like {{{ [W] m t1 ~R# m t2 }}} and you want to say "one way to prove this would be to assume some additional property of m (the quantified constraint) and, in addition, prove `t1 ~R# t2`". Wildly ad-hoc, but maybe. I wouldn't rush to do it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 08:31:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 08:31:19 -0000 Subject: [GHC] #14231: Core lint error "in result of Static argument" In-Reply-To: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> References: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> Message-ID: <064.62c01d820e980a6b2ca9a3702acceb65@haskell.org> #14231: Core lint error "in result of Static argument" -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | 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 osa1): * version: 8.2.1 => 8.5 Comment: Confirmed on GHC HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 08:33:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 08:33:19 -0000 Subject: [GHC] #14980: Runtime performance regression with binary operations on vectors In-Reply-To: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> References: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> Message-ID: <060.b287f75fddce61865cc9c844513b53db@haskell.org> #14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: vector | bitwise operations 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): This smells to me like a crucial fusion rule not firing. You could try compiling with `-ddump-rule-firings` and see if the "good" and "bad" output differs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 08:34:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 08:34:10 -0000 Subject: [GHC] #15318: Core Lint error involving newtype family instances with wrappers In-Reply-To: <050.5e4047b16b9f07feb6a762d8a4dad8f6@haskell.org> References: <050.5e4047b16b9f07feb6a762d8a4dad8f6@haskell.org> Message-ID: <065.0db3f6f62e6bfe2f0d894adee7e4a43d@haskell.org> #15318: Core Lint error involving newtype family instances with wrappers -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 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: | Differential Rev(s): Phab:D4902 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, Phab:D4902 will fix the bug, but it perpetuates a mistake! Consider {{{ data family S a data family T a data instance S [a] = MkS a newtype instance T [a] = MkT a }}} Currently, we get this: {{{ data SList a = MkS a axiom coS a :: SList a ~ S [a] -- Wrapper for MkS $WMkS :: a -> S [a] $WMkS x = MkS x |> coS a -- newtype TList a = MkT a axiom coTList a :: a ~ TList a axiom coT a :: TList a ~ T [a] -- Worker for MkT MkT :: a -> T [a] MkT x = x |> coTList a |> coT a }}} Notice the inconsistency: the cast that takes us from the representation type to the final user type is done in the ''wrapper'' for data types, but in the ''worker'' for a newtype. (Reminder: for data types the worker isn't an executable function, it's the Core data constructor; but for a newtype the "worker" is an executable function that expands to a cast.) This inconsistency shows up in the `MkId` functions `wrapNewTypeBody` and `unwrapNewTypeBody`. The former wraps two casts (as above) while the latter unwraps only one! I think we can readily remove the inconsistency: * Don't export `wrapNewTypeBody` from `MkId`; it is not used outside. * Remove the extra cast from `wrapNewTypeBody` * Do not make the change to `mkDataConRep` proposed in Phab:D4902. * Make a wrapper for family-instance newtypes. Do this by making `wwrapper_reqd` return `True` for ''all'' types for which `isFamInstTyCon` holds. (Currently that predicate is not tested for newtypes.) I think that might be it. It solves the problem at source, produces less code and less to explain (because it's consistent). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 09:44:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 09:44:52 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.fb9ef529191007ac2169fde1d9225e20@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:44 simonpj]: > * As I wrote above, the motivation for the state hack is functions lie > {{{ > f :: [Int] -> IO () > f xs = print ys >> print xs > where > ys = reverse xs > > test 0 = return () > test n = f [1,n] >> test (n-1) > }}} > which I expected to be much less efficient without the state hack. Would it be worth trying to demonstrate a program that does get worse in this way? I'm still amazed at how good the results are! OK, I did some experimenting, and it seems that the state hack makes absolutely no difference for such programs. Specifically, I used the following fully-fledged example program: {{{#!hs module Main where import System.Environment import System.IO f :: Handle -> [Int] -> IO () f h xs = hPrint h ys >> hPrint h xs where ys = reverse xs test :: Int -> Handle -> IO () test 0 h = return () test n h = f h [1,n] >> test (n-1) h main = do args <- getArgs case args of x:y:_ -> withFile y WriteMode $ test (read x) x:_ -> test (read x) stdout _ -> test 0 stdout }}} This allows us to pass an arbitrary number of rounds to test on the command line, as well as an output file; passing `/dev/null` makes it easier to run the whole thing through `time`. Now given two GHC builds in `ghc-prof` (normal profiling build) and `ghc-prof-nsh` (GHC and boot libs built with `-fno-state-hack`), and with our example program in `bad- ex.hs`, I can run the following session: {{{ tobias at zoidberg:~/well-typed/devel/ghc-7411/ > ./ghc-prof/inplace/bin/ghc- stage2 bad-ex.hs -fforce-recomp -O2 && time ./bad-ex 50000000 /dev/null [1 of 1] Compiling Main ( bad-ex.hs, bad-ex.o ) Linking bad-ex ... ./bad-ex 50000000 /dev/null 53.50s user 0.20s system 99% cpu 53.713 total tobias at zoidberg:~/well-typed/devel/ghc-7411/ > ./ghc-prof-nsh/inplace/bin /ghc-stage2 bad-ex.hs -fforce-recomp -fno-state-hack -O2 && time ./bad-ex 50000000 /dev/null [1 of 1] Compiling Main ( bad-ex.hs, bad-ex.o ) Linking bad-ex ... ./bad-ex 50000000 /dev/null 52.75s user 0.19s system 99% cpu 52.956 total }}} Which suggests that even for a program that is presumably about as bad as it gets, the state hack doesn't make a difference for the better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 09:52:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 09:52:54 -0000 Subject: [GHC] #15319: Configurable/overridable settings file Message-ID: <044.ba7ad8d95aa9a6958eb5b0890b79f3ba@haskell.org> #15319: Configurable/overridable settings file -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- GHC ships with a `settings` file. This file specifies what was known about the C compiler at GHC `./configure` time (whether to pass `-no-pie` etc, the path to the C compiler etc). Fortunately, I can override at least some of the entries of the `settings` file, e.g. to use a different GCC than the one GHC got to know about during the `./configure` phase. This is important because is multi-lingual projects, sometimes the build tool for the C++ part of the code wants a special compiler, which GHC should also be using when compiling C. The problem is that I can't override *everything*. If I supply via `-pgmc` a compiler that doesn't understand `-no-pie`, then I can't tell GHC to not pass `-no-pie`. Because I can't supply my own `settings` file, or (equivalently) there exists no CLI flag that allows me to override that particular entry in the `settings` file. What I'd like is something like: {{{ $ ghc -settings /path/to/settings/file }}} that subsumes `-pgmc` and other such flags. I'd be able to tell GHC in one go which compiler I want to use, and what flags GHC should or should not pass to that compiler depending on the features of the compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 09:59:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 09:59:46 -0000 Subject: [GHC] #14980: Runtime performance regression with binary operations on vectors In-Reply-To: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> References: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> Message-ID: <060.e550307322a37c23525dc463be2dfbf7@haskell.org> #14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: vector | bitwise operations 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 tdammers): Ah yes, great. I had already suspected fusion rules, but hadn't thought of `-ddump-rule-firings`. I'll give it a spin. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 11:08:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 11:08:44 -0000 Subject: [GHC] #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints In-Reply-To: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> References: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> Message-ID: <059.d9672eddda97ad937014a2f64761ab9a@haskell.org> #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints 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 mniip): * cc: simonpj (added) Comment: After reading the paper ( https://i.cs.hku.hk/~bruno/papers/hs2017.pdf ) I've been able to construct a corecursive proof that "P,_L (C => C) ; Gamma |= C". Such nontermination is somewhat addressed in the section 6 of the paper where Paterson conditions are modified to account for the new features, and indeed, if I say: {{{#!hs data D a = D instance (forall a. Show a => Show a) => Show (D a) }}} It complains: {{{ error: * The constraint `Show a' is no smaller than the instance head `Show a' (Use UndecidableInstances to permit this) * In the quantified constraint `forall a. Show a => Show a' In the instance declaration for `Show (D x)' }}} However all of these checks seem to be absent when a higher rank type introduces a local axiom, like in the code in the bug report. The paper also totally ignores higher rank types... This leads to a question: should `forall c. c => c` be an inferrable local axiom schema in absence of `UndecidableInstances`? If yes, then the termination guarantees in the paper don't hold because they assume no axiom violates the Paterson conditions. There's also no clear way to "fix" the termination guarantees -- this is basically equivalent to proving arbitrary theorems in first order logic. Also is there a good way to allow corecursion for `(forall a. Show a => Show (f a)) => Show (Fix f)` but not `(C => C) => C`? Could we corecurse only on the axioms that satisfy paterson conditions? If no, then ekmett's `data a :- b = Sub (a => Dict b)` is a category while `Dict (a => b)` is not. There's also the problem with this type of class that you can find in a few places: {{{#!hs class A a => B a instance A a => B a }}} This gives us two axiom schemas: `forall a. A a => B a` (instance) and `forall a. B a => A a` (superclass). Composing the two we can derive `A a => A a` again. So we can't compose arbitrary implications either... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 12:06:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 12:06:21 -0000 Subject: [GHC] #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints In-Reply-To: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> References: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> Message-ID: <059.a7598cd18963161cbc78b40f935ec137@haskell.org> #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints 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: | -------------------------------------+------------------------------------- Comment (by simonpj): > This leads to a question: should forall c. c => c be an inferrable local axiom schema in absence of UndecidableInstances? I think not. I'm busy adding a check for this case! Agreed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 12:10:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 12:10:04 -0000 Subject: [GHC] #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints In-Reply-To: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> References: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> Message-ID: <059.3f01c46f1d9348208ff75b10adcd252c@haskell.org> #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints 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: | -------------------------------------+------------------------------------- Comment (by mniip): Replying to [comment:3 simonpj]: > > This leads to a question: should forall c. c => c be an inferrable local axiom schema in absence of UndecidableInstances? > > I think not. I'm busy adding a check for this case! Agreed? What kind of check? Just for the `c => c` case? Are you sure there aren't any roundabout ways to achieve similar `fix id`-type corecursion? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 14:01:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 14:01:21 -0000 Subject: [GHC] #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints In-Reply-To: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> References: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> Message-ID: <059.eeb8f768dfcc868e77d8b456e21a560b@haskell.org> #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints 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: | -------------------------------------+------------------------------------- Comment (by simonpj): I meant: * Apply the instance-termination check to every quantified constraint `(cxt => constraint)` appearing anywhere in a type. So `f :: (Show a => Show a) => blah` would be rejected just as {{{ instance Show a => Show a }}} is rejected -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 14:09:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 14:09:28 -0000 Subject: [GHC] #11764: ghc internal error building llvm-general-3.5.1.2 In-Reply-To: <049.1e7850c7fbe53a08db3314e9a97a33fc@haskell.org> References: <049.1e7850c7fbe53a08db3314e9a97a33fc@haskell.org> Message-ID: <064.f65212f42bd1d652f9b89e190352ad12@haskell.org> #11764: ghc internal error building llvm-general-3.5.1.2 -------------------------------------+------------------------------------- Reporter: andrew.wja | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: cabal install | llvm-general Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): So I checked out `llvm-general` from https://github.com/bscarlet/llvm- general (commit 26dac5d35d304f43ffd20fadcbb5175a81ec3f24, which corresponds to `llvm-general-3.5.1.2`) and applied the following patch to allow it to build on GHC 8.4.3: {{{#!diff diff --git a/llvm-general-pure/src/LLVM/General/Internal/PrettyPrint.hs b /llvm-general-pure/src/LLVM/General/Internal/PrettyPrint.hs index 5dae66e..13a79d9 100644 --- a/llvm-general-pure/src/LLVM/General/Internal/PrettyPrint.hs +++ b/llvm-general-pure/src/LLVM/General/Internal/PrettyPrint.hs @@ -1,4 +1,5 @@ {-# LANGUAGE + CPP, TemplateHaskell, QuasiQuotes, ViewPatterns, @@ -8,7 +9,7 @@ module LLVM.General.Internal.PrettyPrint where import LLVM.General.Prelude -import LLVM.General.TH +import LLVM.General.TH import Language.Haskell.TH.Quote import Data.Monoid @@ -42,7 +43,7 @@ defaultPrettyShowEnv = PrettyShowEnv { precedence = 0 } -type Qual a = Reader PrettyShowEnv a +type Qual a = Reader PrettyShowEnv a prec :: Int -> Qual a -> Qual a prec p = local (\env -> env { precedence = p }) @@ -58,6 +59,9 @@ indentGroup = fmap (return . IndentGroup) instance IsString QTree where fromString = return . return . Fixed +instance Semigroup QTree where + (<>) = mappend + instance Monoid QTree where mempty = return mempty mappend a b = mappend <$> a <*> b @@ -71,11 +75,11 @@ renderEx threshold indent env ts = where bit (Fixed s) = (length s, s, s) bit (Variable t f) = (length f, f, concat [ s:(if s == '\n' then ind i else "") | s <- t ]) - bit (IndentGroup tree) = + bit (IndentGroup tree) = let (l, t, f) = fit (i+1) tree in (l, t, if (l < threshold) then t else "\n" ++ ind (i+1) ++ f ++ "\n" ++ ind i) (ls, ts, fs) = unzip3 . map bit $ branches - + render = renderEx 80 " " defaultPrettyShowEnv comma = "," <> variable "\n" " " @@ -161,10 +165,15 @@ simpleName n = do makePrettyShowInstance :: Name -> DecsQ makePrettyShowInstance n = do info <- reify n - let (tvb, cons) = + let (tvb, cons) = case info of +#if __GLASGOW_HASKELL__ >= 800 + TyConI (DataD _ _ tvb _ cons _) -> (tvb, cons) + TyConI (NewtypeD _ _ tvb _ con _) -> (tvb, [con]) +#else TyConI (DataD _ _ tvb cons _) -> (tvb, cons) TyConI (NewtypeD _ _ tvb con _) -> (tvb, [con]) +#endif x -> error $ "unexpected info: " ++ show x cs <- mapM (const $ newName "a") tvb let cvs = map varT cs @@ -177,19 +186,24 @@ makePrettyShowInstance n = do RecC conName (unzip3 -> (ns, _, _)) -> do pvs <- mapM (const $ newName "f") ns let ss = [| record $(simpleName conName) $(listE [[|($(simpleName n), prettyShow $(varE pv))|] | (n, pv) <- zip ns pvs]) |] - match + match (conP conName (map varP pvs)) (normalB ss) [] NormalC conName fs -> do pvs <- mapM (const $ newName "f") fs let ss = [| ctor $(simpleName conName) $(listE [[| prettyShow $(varE pv)|] | pv <- pvs]) |] - match + match (conP conName (map varP pvs)) (normalB ss) [] InfixC (_, n0) conName (_, n1) -> do +#if __GLASGOW_HASKELL__ >= 800 + justFixity <- reifyFixity conName + let Fixity prec _ = fromMaybe defaultFixity justFixity +#else DataConI _ _ _ (Fixity prec _) <- reify conName +#endif let ns = [n0, n1] [p0,p1] <- mapM (const $ newName "f") ns let ss = [| parensIfNeeded prec (prettyShow $(varE p0) <+> $(simpleName conName) <+> prettyShow $(varE p1)) |] @@ -203,5 +217,5 @@ makePrettyShowInstance n = do ] ] - + diff --git a/llvm-general-pure/src/LLVM/General/PrettyPrint.hs b/llvm- general-pure/src/LLVM/General/PrettyPrint.hs index 9f26fff..f8b5148 100644 --- a/llvm-general-pure/src/LLVM/General/PrettyPrint.hs +++ b/llvm-general-pure/src/LLVM/General/PrettyPrint.hs @@ -11,7 +11,7 @@ module LLVM.General.PrettyPrint ( shortPrefixScheme, longPrefixScheme, defaultPrefixScheme, - basePrefixScheme, + basePrefixScheme, shortASTPrefixScheme, longASTPrefixScheme, imports @@ -32,7 +32,7 @@ import qualified LLVM.General.AST.Float as A import qualified LLVM.General.AST.FloatingPointPredicate as A import qualified LLVM.General.AST.IntegerPredicate as A import qualified LLVM.General.AST.FunctionAttribute as A -import qualified LLVM.General.AST.ParameterAttribute as A +import qualified LLVM.General.AST.ParameterAttribute as A import qualified LLVM.General.AST.CallingConvention as A import qualified LLVM.General.AST.Visibility as A import qualified LLVM.General.AST.DLL as A.DLL @@ -107,7 +107,7 @@ showPrettyEx width indent (PrefixScheme ps) = renderEx width indent (defaultPret -- | A 'PrefixScheme' is a mapping between haskell module names and -- the prefixes with which they should be rendered when printing code. newtype PrefixScheme = PrefixScheme (Map String (Maybe String)) - deriving (Eq, Ord, Read, Show, Monoid) + deriving (Eq, Ord, Read, Show, Monoid, Semigroup) -- | a 'PrefixScheme' for types not of llvm-general, but nevertheless used -- in the AST. Useful for building other 'PrefixScheme's. diff --git a/llvm-general/Setup.hs b/llvm-general/Setup.hs index 4a833ae..d9cb25d 100644 --- a/llvm-general/Setup.hs +++ b/llvm-general/Setup.hs @@ -17,16 +17,17 @@ import Distribution.Version import System.Environment import System.SetEnv import Distribution.System +import Distribution.Types.CondTree -- define these selectively in C files (where _not_ using HsFFI.h), -- rather than universally in the ccOptions, because HsFFI.h currently defines them -- without checking they're already defined and so causes warnings. uncheckedHsFFIDefines = ["__STDC_LIMIT_MACROS"] -llvmVersion = Version [3,5] [] +llvmVersion = mkVersion [3,5] llvmConfigNames = [ - "llvm-config-" ++ (intercalate "." . map show . versionBranch $ llvmVersion), + "llvm-config-" ++ (intercalate "." . map show . versionNumbers $ llvmVersion), "llvm-config" ] @@ -67,7 +68,7 @@ instance OldHookable (Args -> PackageDescription -> LocalBuildInfo -> UserHooks llvmProgram :: Program llvmProgram = (simpleProgram "llvm-config") { programFindLocation = programSearch (programFindLocation . simpleProgram), - programFindVersion = + programFindVersion = let stripSuffix suf str = let r = reverse in liftM r (stripPrefix (r suf) (r str)) svnToTag v = maybe v (++"-svn") (stripSuffix "svn" v) @@ -98,10 +99,10 @@ addLLVMToLdLibraryPath configFlags = do llvmConfig <- getLLVMConfig configFlags [libDir] <- liftM lines $ llvmConfig "--libdir" addToLdLibraryPath libDir - + main = do let origUserHooks = simpleUserHooks - + defaultMainWithHooks origUserHooks { hookedPrograms = [ llvmProgram ], @@ -128,12 +129,12 @@ main = do libBuildInfo = mempty { ccOptions = llvmCppFlags } }, condTreeComponents = condTreeComponents libraryCondTree ++ [ - ( - Var (Flag (FlagName "shared-llvm")), - CondNode (mempty { libBuildInfo = mempty { extraLibs = [sharedLib] ++ systemLibs } }) [] [], - Just (CondNode (mempty { libBuildInfo = mempty { extraLibs = staticLibs ++ systemLibs } }) [] []) - ) - ] + CondBranch { + condBranchCondition = Var (Flag (mkFlagName "shared- llvm")), + condBranchIfTrue = CondNode (mempty { libBuildInfo = mempty { extraLibs = [sharedLib] ++ systemLibs } }) [] [], + condBranchIfFalse = Just (CondNode (mempty { libBuildInfo = mempty { extraLibs = staticLibs ++ systemLibs } }) [] []) + } + ] } } configFlags' = configFlags { diff --git a/llvm-general/llvm-general.cabal b/llvm-general/llvm- general.cabal index 05d7554..251c333 100644 --- a/llvm-general/llvm-general.cabal +++ b/llvm-general/llvm-general.cabal @@ -53,6 +53,9 @@ flag debug description: compile C(++) shims with debug info for ease of troubleshooting default: False +custom-setup + setup-depends: base, Cabal, containers, setenv + library build-tools: llvm-config ghc-options: -fwarn-unused-imports diff --git a/llvm-general/src/Control/Monad/Exceptable.hs b/llvm- general/src/Control/Monad/Exceptable.hs index 258797d..b12f2df 100644 --- a/llvm-general/src/Control/Monad/Exceptable.hs +++ b/llvm-general/src/Control/Monad/Exceptable.hs @@ -150,8 +150,10 @@ instance (Read e, Read1 m, Read a) => Read (ExceptableT e m a) where instance (Show e, Show1 m, Show a) => Show (ExceptableT e m a) where showsPrec d (ExceptableT m) = showsUnary1 "ExceptableT" d m +{- instance (Read e, Read1 m) => Read1 (ExceptableT e m) where readsPrec1 = readsPrec instance (Show e, Show1 m) => Show1 (ExceptableT e m) where showsPrec1 = showsPrec +-} runExceptableT :: ExceptableT e m a -> m (Either e a) runExceptableT = Except.runExceptT . unExceptableT diff --git a/llvm-general/src/LLVM/General/Internal/FFI/PassManager.hs b /llvm-general/src/LLVM/General/Internal/FFI/PassManager.hs index 3aaaad5..df4da78 100644 --- a/llvm-general/src/LLVM/General/Internal/FFI/PassManager.hs +++ b/llvm-general/src/LLVM/General/Internal/FFI/PassManager.hs @@ -75,15 +75,15 @@ $(do | h == ''FilePath -> [t| NothingAsEmptyString CString |] _ -> typeMapping t _ -> typeMapping t - foreignDecl + foreignDecl (cName n) ("add" ++ n ++ "Pass") - ([[t| Ptr PassManager |]] + ([[t| Ptr PassManager |]] ++ [[t| Ptr TargetMachine |] | needsTargetMachine n] ++ map passTypeMapping extraParams) (TH.tupleT 0) - TH.TyConI (TH.DataD _ _ _ cons _) <- TH.reify ''G.Pass + TH.TyConI (TH.DataD _ _ _ _ cons _) <- TH.reify ''G.Pass liftM concat $ forM cons $ \con -> case con of TH.RecC n l -> declareForeign n [ t | (_,_,t) <- l ] TH.NormalC n [] -> declareForeign n [] @@ -93,37 +93,37 @@ $(do data PassManagerBuilder foreign import ccall unsafe "LLVMPassManagerBuilderCreate" passManagerBuilderCreate :: - IO (Ptr PassManagerBuilder) + IO (Ptr PassManagerBuilder) foreign import ccall unsafe "LLVMPassManagerBuilderDispose" passManagerBuilderDispose :: Ptr PassManagerBuilder -> IO () foreign import ccall unsafe "LLVMPassManagerBuilderSetOptLevel" passManagerBuilderSetOptLevel :: - Ptr PassManagerBuilder -> CUInt -> IO () + Ptr PassManagerBuilder -> CUInt -> IO () foreign import ccall unsafe "LLVMPassManagerBuilderSetSizeLevel" passManagerBuilderSetSizeLevel :: Ptr PassManagerBuilder -> CUInt -> IO () foreign import ccall unsafe "LLVMPassManagerBuilderSetDisableUnitAtATime" passManagerBuilderSetDisableUnitAtATime :: - Ptr PassManagerBuilder -> LLVMBool -> IO () + Ptr PassManagerBuilder -> LLVMBool -> IO () foreign import ccall unsafe "LLVMPassManagerBuilderSetDisableUnrollLoops" passManagerBuilderSetDisableUnrollLoops :: Ptr PassManagerBuilder -> CUInt -> IO () foreign import ccall unsafe "LLVMPassManagerBuilderSetDisableSimplifyLibCalls" passManagerBuilderSetDisableSimplifyLibCalls :: - Ptr PassManagerBuilder -> LLVMBool -> IO () + Ptr PassManagerBuilder -> LLVMBool -> IO () foreign import ccall unsafe "LLVMPassManagerBuilderUseInlinerWithThreshold" passManagerBuilderUseInlinerWithThreshold :: Ptr PassManagerBuilder -> CUInt -> IO () foreign import ccall unsafe "LLVMPassManagerBuilderPopulateFunctionPassManager" passManagerBuilderPopulateFunctionPassManager :: - Ptr PassManagerBuilder -> Ptr PassManager -> IO () + Ptr PassManagerBuilder -> Ptr PassManager -> IO () foreign import ccall unsafe "LLVMPassManagerBuilderPopulateModulePassManager" passManagerBuilderPopulateModulePassManager :: Ptr PassManagerBuilder -> Ptr PassManager -> IO () foreign import ccall unsafe "LLVMPassManagerBuilderPopulateLTOPassManager" passManagerBuilderPopulateLTOPassManager :: - Ptr PassManagerBuilder -> Ptr PassManager -> CUChar -> CUChar -> IO () + Ptr PassManagerBuilder -> Ptr PassManager -> CUChar -> CUChar -> IO () foreign import ccall unsafe "LLVM_General_PassManagerBuilderSetLibraryInfo" passManagerBuilderSetLibraryInfo :: Ptr PassManagerBuilder -> Ptr TargetLibraryInfo -> IO () diff --git a/llvm-general/src/LLVM/General/Internal/InstructionDefs.hs b /llvm-general/src/LLVM/General/Internal/InstructionDefs.hs index bf19a90..253fcb7 100644 --- a/llvm-general/src/LLVM/General/Internal/InstructionDefs.hs +++ b/llvm-general/src/LLVM/General/Internal/InstructionDefs.hs @@ -27,10 +27,10 @@ import qualified LLVM.General.AST.Constant as A.C $(do let ctorRecs t = do - TH.TyConI (TH.DataD _ _ _ cons _) <- TH.reify t + TH.TyConI (TH.DataD _ _ _ _ cons _) <- TH.reify t TH.dataToExpQ (const Nothing) $ [ (TH.nameBase n, rec) | rec@(TH.RecC n _) <- cons ] - [d| + [d| astInstructionRecs = Map.fromList $(ctorRecs ''A.Instruction) astConstantRecs = Map.fromList $(ctorRecs ''A.C.Constant) |] @@ -53,7 +53,7 @@ outerJoin xs ys = Map.unionWith combine combine (Just a, Nothing) (Nothing, Just b) = (Just a, Just b) combine _ _ = error "outerJoin: the impossible happened" -instrP = TH.QuasiQuoter { +instrP = TH.QuasiQuoter { TH.quoteExp = undefined, TH.quotePat = let m = Map.fromList [ (ID.cAPIName i, ID.cppOpcode i) | i <- ID.instructionDefs ] in TH.dataToPatQ (const Nothing) . (m Map.!), diff --git a/llvm-general/src/LLVM/General/Internal/PassManager.hs b/llvm- general/src/LLVM/General/Internal/PassManager.hs index fec64f9..ecd3c15 100644 --- a/llvm-general/src/LLVM/General/Internal/PassManager.hs +++ b/llvm-general/src/LLVM/General/Internal/PassManager.hs @@ -88,14 +88,14 @@ instance (Monad m, MonadAnyCont IO m) => EncodeM m GCOVVersion CString where createPassManager :: PassSetSpec -> IO (Ptr FFI.PassManager) createPassManager pss = flip runAnyContT return $ do pm <- liftIO $ FFI.createPassManager - forM_ (dataLayout pss) $ \dl -> liftIO $ withFFIDataLayout dl $ FFI.addDataLayoutPass pm + forM_ (dataLayout pss) $ \dl -> liftIO $ withFFIDataLayout dl $ FFI.addDataLayoutPass pm forM_ (targetLibraryInfo pss) $ \(TargetLibraryInfo tli) -> do liftIO $ FFI.addTargetLibraryInfoPass pm tli forM_ (targetMachine pss) $ \(TargetMachine tm) -> liftIO $ FFI.addAnalysisPasses tm pm case pss of s at CuratedPassSetSpec {} -> liftIO $ do bracket FFI.passManagerBuilderCreate FFI.passManagerBuilderDispose $ \b -> do - let handleOption g m = forM_ (m s) (g b <=< encodeM) + let handleOption g m = forM_ (m s) (g b <=< encodeM) handleOption FFI.passManagerBuilderSetOptLevel optLevel handleOption FFI.passManagerBuilderSetSizeLevel sizeLevel handleOption FFI.passManagerBuilderSetDisableUnitAtATime (liftM not . unitAtATime) @@ -108,13 +108,13 @@ createPassManager pss = flip runAnyContT return $ do let tm = maybe nullPtr (\(TargetMachine tm) -> tm) tm' forM_ ps $ \p -> $( do - TH.TyConI (TH.DataD _ _ _ cons _) <- TH.reify ''Pass + TH.TyConI (TH.DataD _ _ _ _ cons _) <- TH.reify ''Pass TH.caseE [| p |] $ flip map cons $ \con -> do let (n, fns) = case con of TH.RecC n fs -> (n, [ TH.nameBase fn | (fn, _, _) <- fs ]) TH.NormalC n [] -> (n, []) - actions = + actions = [ TH.bindS (TH.varP . TH.mkName $ fn) [| encodeM $(TH.dyn fn) |] | fn <- fns ] ++ [ TH.noBindS [| }}} After doing this, I was able to `cabal new-build` the entirety of `llvm- general` without experiencing any sort of panic. In light of this, I'm inclined to close this issue. Does everyone agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 14:10:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 14:10:02 -0000 Subject: [GHC] #14980: Runtime performance regression with binary operations on vectors In-Reply-To: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> References: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> Message-ID: <060.f3328a99863be1d764ecca284fcbfe33@haskell.org> #14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: vector | bitwise operations 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 tdammers): OK, for a very rough first impression of `RULES` that fire in either case, I did this: {{{#!diff tobias at zoidberg:~/well-typed/devel/ghc-T14980/ > diff <(grep '^Rule' ghc- bug-8.0.2/rule-firings | sort -u) <(grep '^Rule' ghc-bug-8.2.2/rule- firings | sed -e 's/\s(.*)$//' | sort -u) -u | grep '^[+-]' --- /proc/self/fd/13 2018-06-28 12:26:37.103065551 +0200 +++ /proc/self/fd/14 2018-06-28 12:26:37.103065551 +0200 -Rule fired: >=# +Rule fired: ==# +Rule fired: ># -Rule fired: Class op < -Rule fired: Class op <*> -Rule fired: Class op >= -Rule fired: Class op fmap +Rule fired: Class op liftA2 -Rule fired: Class op $p1Applicative -Rule fired: eftIntList +Rule fired: divInt# +Rule fired: foldr2/left -Rule fired: narrow32Word# -Rule fired: narrow8Word# -Rule fired: or# -Rule fired: SC:foldlM_loop0 -Rule fired: SC:foldlM_loop1 +Rule fired: SC:go0 -Rule fired: SC:$j1 +Rule fired: SC:$wfoldlM_loop0 -Rule fired: seq of cast +Rule fired: stream/unstream [Vector] +Rule fired: uncheckedShiftL# }}} That is, I compiled the `performance-bug-2` program with both compilers using `-ddump-rule-firings`, and then filtered the dump as follows: 1. Retain only the actual rule firings 2. Sort by rule name 3. Remove duplicates 4. Strip the extra information that is only present in 8.2.2 output 5. Diff 6. Retain only + and - lines. `+` lines are rules that only fire on 8.2.2, `-` lines fire only on 8.0.2. I don't know which of these makes the decisive difference, but I suspect it's one of the built-in rules. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 14:37:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 14:37:32 -0000 Subject: [GHC] #15320: Save the types in the typechecked syntax tree Message-ID: <045.b1f7982e4ba945cea432856f673a60a4@haskell.org> #15320: Save the types in the typechecked syntax tree -------------------------------------+------------------------------------- Reporter: nboldi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- When working on development tools that use the GHC API as a backend, it is useful to have information on the types (or kinds) of the elements of the syntax tree (expressions, patterns, types). I found that the lack of this semantic information is limiting in some cases of refactoring transformations (for example to generate the type signature or extract a subexpression to a binding with type signature), and is necessary for tools that try to fix common programmer errors. But there should be other kind of tools that this little change may help. The type is currently saved for some expressions and most patterns but it would be useful if it would be available uniformly. It could be implemented nicely by adding type information to the `X* GhcTc` type families. I plan to implement these changes, I'm just asking the opinion of the developers about a change in this direction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 15:05:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 15:05:11 -0000 Subject: [GHC] #15061: print022 testcase fails on i386 In-Reply-To: <046.070201c29a49dce5435517538bdcfad1@haskell.org> References: <046.070201c29a49dce5435517538bdcfad1@haskell.org> Message-ID: <061.198ecdd3ccf90d2d6c13010b5546e688@haskell.org> #15061: print022 testcase fails on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: ci-breakage 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 osa1): * owner: bgamari => osa1 Comment: Fixed this bug but run out of time before getting the patch ready for reviews. Will submit it tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 15:08:58 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 15:08:58 -0000 Subject: [GHC] #15320: Save the types in the typechecked syntax tree In-Reply-To: <045.b1f7982e4ba945cea432856f673a60a4@haskell.org> References: <045.b1f7982e4ba945cea432856f673a60a4@haskell.org> Message-ID: <060.a8bff4b70b5158b96ea79fe6febdb37d@haskell.org> #15320: Save the types in the typechecked syntax tree -------------------------------------+------------------------------------- Reporter: nboldi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 mpickering): One way to get the type of an expression is to desugar it using `dsExpr` and then using `exprType`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 15:18:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 15:18:59 -0000 Subject: [GHC] #15320: Save the types in the typechecked syntax tree In-Reply-To: <045.b1f7982e4ba945cea432856f673a60a4@haskell.org> References: <045.b1f7982e4ba945cea432856f673a60a4@haskell.org> Message-ID: <060.e4cd6fb9a01ae4359659ff575c209914@haskell.org> #15320: Save the types in the typechecked syntax tree -------------------------------------+------------------------------------- Reporter: nboldi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 simonpj): Moreover, the post-typechecked tree is ''already'' annotated with enough type information to be able to get its type easily. We just need someone to write `hsExprType :: HsExpr GhcTc -> Type`. It should not be difficult to do this. We already have its near cousin `hsPatType :: Pat GhcTc -> Type`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 15:19:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 15:19:40 -0000 Subject: [GHC] #15320: Save the types in the typechecked syntax tree In-Reply-To: <045.b1f7982e4ba945cea432856f673a60a4@haskell.org> References: <045.b1f7982e4ba945cea432856f673a60a4@haskell.org> Message-ID: <060.f6d34a9838a9b060ac13ec95d7da92fa@haskell.org> #15320: Save the types in the typechecked syntax tree -------------------------------------+------------------------------------- Reporter: nboldi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 goldfire): comment:1 is true, but I can't imagine it's all that difficult to get the type from a `HsExpr GhcTc` directly. I don't think we have that function currently, but I think `hsExprType :: HsExpr GhcTc -> Type` should be quite doable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 15:49:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 15:49:36 -0000 Subject: [GHC] #15321: Typed holes in Template Haskell splices produce bewildering error messages Message-ID: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> #15321: Typed holes in Template Haskell splices produce bewildering error messages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template | Version: 8.4.3 Haskell | Keywords: TypedHoles | 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 compile this program with GHC 8.4 or later: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Bug where foo :: String foo = test bar :: String bar = $(_ "baz") }}} You'll be greeted with a rather strange error message: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:8:7: error: • GHC stage restriction: ‘foo’ is used in a top-level splice, quasi-quote, or annotation, and must be imported, not defined locally • In the untyped splice: $(_ "baz") | 8 | bar = $(_ "baz") | ^^^^^^^^^^ }}} `foo` has nothing do with how `bar`'s RHS should be typechecked, so why is it being mentioned in the error message? In contrast, GHC 8.2 and earlier gives you quite a nice error message: {{{ $ /opt/ghc/8.2.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:8:9: error: • Found hole: _ :: [Char] -> Language.Haskell.TH.Lib.ExpQ • In the expression: _ In the expression: _ "baz" In the untyped splice: $(_ "baz") | 8 | bar = $(_ "baz") | ^ }}} Tritlo, my hunch is that the valid hole fits stuff is the culprit here. Do you think that perhaps when building the subsumption graph, we are trying to check the hole's type against that of `foo`, which causes the stage restriction error? If so, do you think it is possible to work around this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 15:49:50 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 15:49:50 -0000 Subject: [GHC] #15321: Typed holes in Template Haskell splices produce bewildering error messages In-Reply-To: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> References: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> Message-ID: <065.3cefe7ee54140d5eff776992b6dddf61@haskell.org> #15321: Typed holes in Template Haskell splices produce bewildering error messages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: TypedHoles 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): * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 17:01:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 17:01:03 -0000 Subject: [GHC] #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints In-Reply-To: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> References: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> Message-ID: <059.ad96d32f5f40ad2568e768ceb218dd38@haskell.org> #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints 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: | -------------------------------------+------------------------------------- Comment (by mniip): That sounds "sound" to me but not necesasrily "good". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jun 28 19:34:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Jun 2018 19:34:40 -0000 Subject: [GHC] #15320: Save the types in the typechecked syntax tree In-Reply-To: <045.b1f7982e4ba945cea432856f673a60a4@haskell.org> References: <045.b1f7982e4ba945cea432856f673a60a4@haskell.org> Message-ID: <060.51f5f8f0bf2a04e1e97f3e8276e911cb@haskell.org> #15320: Save the types in the typechecked syntax tree -------------------------------------+------------------------------------- Reporter: nboldi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 nboldi): I'm concerned that reconstructing the types of multiple subexpressions/subpatterns takes a lot of calculation time. In my opinion, it would be better to save the types where we have them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 03:54:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 03:54:27 -0000 Subject: [GHC] #15320: Save the types in the typechecked syntax tree In-Reply-To: <045.b1f7982e4ba945cea432856f673a60a4@haskell.org> References: <045.b1f7982e4ba945cea432856f673a60a4@haskell.org> Message-ID: <060.15a014640985ac36d90f64381902eeb1@haskell.org> #15320: Save the types in the typechecked syntax tree -------------------------------------+------------------------------------- Reporter: nboldi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 goldfire): But GHC itself has no need for such information, so it seems that doing this would necessarily slow down every compilation... so I'm worried that everyone will have to pay the cost of this feature. On the other hand, you could define a new pass (an alternative to `GhcTc`) that adds the type information and then calculate all the types once, when you need them, but never again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 06:13:37 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 06:13:37 -0000 Subject: [GHC] #15321: Typed holes in Template Haskell splices produce bewildering error messages In-Reply-To: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> References: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> Message-ID: <065.645cff8d4ae9037caffa42c74dbf90bf@haskell.org> #15321: Typed holes in Template Haskell splices produce bewildering error messages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: TypedHoles 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 mgsloan): I'm trying to get more familiar with working on GHC / TH, so took a look at the trac issues. This one seemed interesting to resolve, so I took a look. Just writing a note here so that y'all know there is work in progress here. I think I've figured it out! Indeed, when searching for valid hole fits, it is considering names that come from the current module, even when in a TH splice. My plan is to check `tcl_th_ctxt` to see if we're in a splice, and in that case omit `lcl` (module locals) from the computation of `locals` in `findValidHoleFits`. `lclBinds` will still be used, since locals within the splice certainly should be checked for fitting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 06:31:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 06:31:32 -0000 Subject: [GHC] #9046: Panic in GHCi when using :print In-Reply-To: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> References: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> Message-ID: <060.24bcc0212c67adfdbe339342d867fd84@haskell.org> #9046: Panic in GHCi when using :print -------------------------------------+------------------------------------- Reporter: quchen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: | tests/ghci.debugger/scripts/print036 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by anarchist666): Probably #9046 not present in 8.4.3, but there are #12449 and #15299. And #15299 is a duplicate #12449. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 06:35:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 06:35:45 -0000 Subject: [GHC] #12449: Broken types in identifiers bound by :print In-Reply-To: <044.542a5d089ce4efa7862430871616a137@haskell.org> References: <044.542a5d089ce4efa7862430871616a137@haskell.org> Message-ID: <059.48cd6e6ad166f46825efc0c5e59b10a2@haskell.org> #12449: Broken types in identifiers bound by :print -------------------------------------+------------------------------------- Reporter: mniip | 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: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by anarchist666): * status: closed => new * resolution: duplicate => Comment: #9046 not present in 8.4.3, but there is #12449. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 06:38:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 06:38:50 -0000 Subject: [GHC] #9046: Panic in GHCi when using :print In-Reply-To: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> References: <045.d24a5c28945d05b49983cb797f4fd30c@haskell.org> Message-ID: <060.8a9da1fe9568d9fd4d5d326ba2d6f625@haskell.org> #9046: Panic in GHCi when using :print -------------------------------------+------------------------------------- Reporter: quchen | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: | tests/ghci.debugger/scripts/print036 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by anarchist666): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 06:44:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 06:44:55 -0000 Subject: [GHC] #15061: print022 testcase fails on i386 In-Reply-To: <046.070201c29a49dce5435517538bdcfad1@haskell.org> References: <046.070201c29a49dce5435517538bdcfad1@haskell.org> Message-ID: <061.2af02d8db60c14166b9cd2ed04a19ba5@haskell.org> #15061: print022 testcase fails on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4906 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D4906 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 07:12:33 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 07:12:33 -0000 Subject: [GHC] #9693: Reloading GHCi with Template Haskell names can panic GHC In-Reply-To: <043.739fde51b47ea4696baf564b0f9ae27e@haskell.org> References: <043.739fde51b47ea4696baf564b0f9ae27e@haskell.org> Message-ID: <058.f7f2c956979b4bd661332c8361905543@haskell.org> #9693: Reloading GHCi with Template Haskell names can panic GHC -------------------------------------+------------------------------------- Reporter: maxs | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Template Haskell | Version: 7.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 mgsloan): Is this still an issue? I cannot reproduce it with latest GHC master. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 07:21:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 07:21:46 -0000 Subject: [GHC] #15320: Save the types in the typechecked syntax tree In-Reply-To: <045.b1f7982e4ba945cea432856f673a60a4@haskell.org> References: <045.b1f7982e4ba945cea432856f673a60a4@haskell.org> Message-ID: <060.518532d46d690ef693fc11458727512a@haskell.org> #15320: Save the types in the typechecked syntax tree -------------------------------------+------------------------------------- Reporter: nboldi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 simonpj): Let's do the `hsExprType` route first. We can always memoise this function in the data structure later -- but I agree with Richard that doing so seems to impose a tax on all users willy-nilly, which sounds unattractive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 07:29:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 07:29:05 -0000 Subject: [GHC] #15320: Save the types in the typechecked syntax tree In-Reply-To: <045.b1f7982e4ba945cea432856f673a60a4@haskell.org> References: <045.b1f7982e4ba945cea432856f673a60a4@haskell.org> Message-ID: <060.f37de9352480168d696828e2614ff4ef@haskell.org> #15320: Save the types in the typechecked syntax tree -------------------------------------+------------------------------------- Reporter: nboldi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 nboldi): Ok, I will try to go for `hsExprType :: HsExpr GhcTc -> Type` and `hsTypeKind :: HsType GhcTc -> Kind`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 07:29:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 07:29:43 -0000 Subject: [GHC] #15321: Typed holes in Template Haskell splices produce bewildering error messages In-Reply-To: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> References: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> Message-ID: <065.9f050f2b0b119746106432fed2da4ec5@haskell.org> #15321: Typed holes in Template Haskell splices produce bewildering error messages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: TypedHoles 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:D4907 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mgsloan): * differential: => Phab:D4907 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 07:35:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 07:35:50 -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.8ccf4af74ad18378efd5257b29d8714e@haskell.org> #14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Runtime System | Version: 8.0.1 (Linker) | 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:D4817 Wiki Page: | -------------------------------------+------------------------------------- Changes (by SantiM): * owner: SantiM => (none) * status: closed => new * resolution: fixed => Comment: Let's leave this open, there's more occurrences of mmap that were not protected in Phab:D4817 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 08:07:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 08:07:45 -0000 Subject: [GHC] #15321: Typed holes in Template Haskell splices produce bewildering error messages In-Reply-To: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> References: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> Message-ID: <065.224a29d7c9ba6fbc2d23339e91ff305a@haskell.org> #15321: Typed holes in Template Haskell splices produce bewildering error messages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: TypedHoles 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 simonpj): * differential: Phab:D4907 => Comment: You're right. In `TcHoleErrors` we see {{{ lookup :: Either Id GlobalRdrElt -> TcM (Maybe Id) lookup (Left id) = return $ Just id lookup (Right el) = do { thing <- tcLookup (gre_name el) ; case thing of }}} That call to `tcLookup` checks for staging errors (it calls `tcLookupGlobal` which calls `notFound`). Easiest solution: something like {{{ lookup (Right el) = tryTcDiscardingErrs (return Nothing) $ do { thing <- tcLookup (gre_name el) ; case thing of }}} The `tryTcDiscardingErrs` does what it sounds like. It's not super-efficient, but it doesn't have to be ... this is in error- message generation only. It needs a `Note` to explain why the lookup can fail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 08:12:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 08:12:04 -0000 Subject: [GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin Message-ID: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> #15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple typeable,knownnat | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #10348 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have the following Haskell code which uses `ghc-typelits-knownnat-0.5` package as a plugin: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -fplugin GHC.TypeLits.KnownNat.Solver #-} module Nats where import Data.Proxy (Proxy (..)) import Data.Typeable (Typeable) import GHC.TypeLits (KnownNat, type (+)) f :: forall n . (Typeable n, KnownNat n) => Proxy n -> () f _ = () f _ = f (Proxy :: Proxy (n + 1)) }}} When I try to compile this code I observe the following error message: {{{ • Could not deduce (Typeable (n + 1)) arising from a use of ‘f’ from the context: (Typeable n, KnownNat n) bound by the type signature for: f :: forall (n :: ghc-prim-0.5.2.0:GHC.Types.Nat). (Typeable n, KnownNat n) => Proxy n -> () at src/Nats.hs:13:1-57 • In the expression: f (Proxy :: Proxy (n + 1)) In an equation for ‘f’: f _ = f (Proxy :: Proxy (n + 1)) | 15 | f _ = f (Proxy :: Proxy (n + 1)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} This code works for both GHC-8.2.2 and GHC-8.0.2. I found similar ticket with exactly this problem but looks like this is broken again: #10348 (bug). Originally reported at Github for `ghc-typelits-knownnat` package: * https://github.com/clash-lang/ghc-typelits-knownnat/issues/21 `ghc-typelits-knownnat` package correctly infers `KnownNat (n + 1)` constraint so GHC should be able to infer `Typeable (n + 1)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 08:13:08 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 08:13:08 -0000 Subject: [GHC] #15321: Typed holes in Template Haskell splices produce bewildering error messages In-Reply-To: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> References: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> Message-ID: <065.8077085d0a523311ade99ccd7016aacb@haskell.org> #15321: Typed holes in Template Haskell splices produce bewildering error messages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: TypedHoles 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 simonpj): PS I missed your patch. I think the approach in comment:4 would be more comprehensible -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 08:47:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 08:47:12 -0000 Subject: [GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin In-Reply-To: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> References: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> Message-ID: <062.0ccb7ef923a4de7723a1507db2586167@haskell.org> #15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | typeable,knownnat Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10348 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: diatchki (added) Comment: #15322 Does this need the plugin to demonstrate the bug? It complicate reproduction, and indeed I'm not sure how to set up the plugin. ------------ I do know a bit about what's going on. I think this bug is a consequence of this patch {{{ commit c41ccbfa8aaeb99dd9a36cb3d99993f0fa039cdc Author: Simon Peyton Jones Date: Tue Sep 26 15:02:09 2017 +0100 Omit Typeable from the "naturally coherent" list In doing something else (Trac #14218) I tripped over the definition of "naturally coherent" classes. This patch - Cocuments properly what that means - Removes Typeable from the list, because now we know what it meams, Typeable clearly doesn't belong. No regressions. (Actually the term "naturally coherent" seems a bit off. More like "invertible" or something. But I left it.) }}} The issue here is this. We have {{{ [G] Typeable n [G] KnownNat n [W] Typeable (n+1) }}} Can we use `TcInteract.doTyLit` to simplify the `[W]` goal, by instead generating `[W] KnownNat (n+1)`? GHC does not do so, because suppose we had instead got: {{{ [G] Typeable x [G] Typeable (F [x]) }}} where `type family F (x::Nat) :: Nat`. Now we don't want to do the `doTyLit` thing because then we'd be stuck... we'd have `[W] KnownNat (F [x])` with no way to solve it. Instead, by deferring that choice, GHC is hoping that later we'll reduce `F [x] --> x` and bingo we'd have `[W] Typeable x` which we can solve from the Given. Background info: this "deferring" business is implmented by this code in `TcInteract`: {{{ matchClassInst dflags inerts clas tys loc -- First check whether there is an in-scope Given that could -- match this constraint. In that case, do not use any instance -- whether top level, or local quantified constraints. -- ee Note [Instance and Given overlap] | not (xopt LangExt.IncoherentInstances dflags) , not (naturallyCoherentClass clas) , let matchable_givens = matchableGivens loc pred inerts , not (isEmptyBag matchable_givens) = do { traceTcS "Delaying instance application" $ vcat [ text "Work item=" <+> pprClassPred clas tys , text "Potential matching givens:" <+> ppr matchable_givens ] ; return NotSure } }}} Returning to the example, I'm pretty suspicous of the whole `doTyLit` thing (introduced by Iavor in Trac #10348). It seems to say that really the ''only'' way to solve `Typeable (ty :: Nat)` is by proving `KnonwNat ty`, which seems to me like replacing a simple goal with a complicated one. One possible workaround for you may be to remove the `Typeable n` constraint since it is (I think) mysteriously implied by `Typeable` (c.f. Trac #10348). I say "mysteriously" because `Typeable` is not a superclass of `KonwnNat`. Iavor, I'm a bit lost here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 10:20:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 10:20:19 -0000 Subject: [GHC] #15321: Typed holes in Template Haskell splices produce bewildering error messages In-Reply-To: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> References: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> Message-ID: <065.464840b03803c35f4dec20b4f9b6eab8@haskell.org> #15321: Typed holes in Template Haskell splices produce bewildering error messages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: TypedHoles 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 mgsloan): Ah, that makes sense Simon, thanks for the input! I have a concern with using `tryTcDiscardingErrors` here - it could hide problems. Errant omission of output is hard to notice in a mechanism like hole fitting - you would need to somehow notice a pattern of omission. Limiting the number of results also contributes to this. Based on this reasoning, here's what I'm thinking should be done: * First, the implementation you suggest. I'm not sure where things are in the release process, but having holes be so broken in GHCi isn't so good (https://ghc.haskell.org/trac/ghc/ticket/15202), and a change related to your suggestion would fix it. * In a subsequent change, using `tryTc` and recording the errors that are encountered, while still getting results for hole fitting. Then, including one of the exceptions as a "Please report this as a GHC bug" type of message. This way, we get hole fitting results, but errors like this get noticed and resolved. Breaking it up into these 2 steps is mainly motivated by the potential for the first portion to be included in the release. Coincidentally, before I read your comment I implemented a change that catches errors for the entire hole fitting process, rather than just portions - https://phabricator.haskell.org/D4908 . I'm favoring abandoning that approach and doing this more fine-grained catching. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 11:22:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 11:22:23 -0000 Subject: [GHC] #12449: Broken types in identifiers bound by :print In-Reply-To: <044.542a5d089ce4efa7862430871616a137@haskell.org> References: <044.542a5d089ce4efa7862430871616a137@haskell.org> Message-ID: <059.970dff0c43a53b91fc971f60cd60b077@haskell.org> #12449: Broken types in identifiers bound by :print -------------------------------------+------------------------------------- Reporter: mniip | 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: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by anarchist666): * status: new => patch Comment: To fix this issue, I sent a ​[https://github.com/ghc/ghc/pull/155 pull- request] to the Github repository. But I'm a new and I'm not sure I'm right. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 12:13:29 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 12:13:29 -0000 Subject: [GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker In-Reply-To: <049.2656489ff85910f6a80bbfa971643315@haskell.org> References: <049.2656489ff85910f6a80bbfa971643315@haskell.org> Message-ID: <064.b609037c20f63b2e45e51fc3b7c15c34@haskell.org> #15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11547 #14052 | Differential Rev(s): #15202 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by Tritlo): * cc: Tritlo (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 12:22:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 12:22:26 -0000 Subject: [GHC] #15321: Typed holes in Template Haskell splices produce bewildering error messages In-Reply-To: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> References: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> Message-ID: <065.e79d5fe05485802eca4fcf60446d987e@haskell.org> #15321: Typed holes in Template Haskell splices produce bewildering error messages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: TypedHoles 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 Tritlo): Oh my, this is bad, especially #15007. I wish that I'd known earlier! I think that the approach mentioned in comment:4 is the way to go for now, as the "include" in "Valid hole fits include" allow us to err on the side of omission, and I hope that we can add this ASAP. I'll then make sure to implement more comprehensive fix, as mentioned in comment:6 later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 13:02:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 13:02:12 -0000 Subject: [GHC] #15321: Typed holes in Template Haskell splices produce bewildering error messages In-Reply-To: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> References: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> Message-ID: <065.2457173e5fcb77d4714258694c462f14@haskell.org> #15321: Typed holes in Template Haskell splices produce bewildering error messages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: TypedHoles 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 Tritlo): I've pushed an intermittent fix in https://phabricator.haskell.org/D4909. It is a bit more comprehensive (discarding ANY candidate that causes an error, not just errors in `tcLookup`), but uses the same approach as suggested in comment:4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 13:28:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 13:28:22 -0000 Subject: [GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin In-Reply-To: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> References: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> Message-ID: <062.f130f15d90c1cfc2e68e4cffa680842e@haskell.org> #15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | typeable,knownnat Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10348 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chshersh): simonpj, thanks a lot for your response. This workaround works perfectly for me! Regarding simpler example: I tried to come up with example which doesn't involve plugin. But didn't manage to do it. I don't know how to launch my example with single `ghc` command. What I did: I created very simple project with `cabal init`, added `ghc-typelits-knownnat == 0.5` to `build- depends` in `.cabal` file and built given source code snippet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 13:30:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 13:30:16 -0000 Subject: [GHC] #9693: Reloading GHCi with Template Haskell names can panic GHC In-Reply-To: <043.739fde51b47ea4696baf564b0f9ae27e@haskell.org> References: <043.739fde51b47ea4696baf564b0f9ae27e@haskell.org> Message-ID: <058.14faf12c882e05dd2d25cbe918acf5a7@haskell.org> #9693: Reloading GHCi with Template Haskell names can panic GHC -------------------------------------+------------------------------------- Reporter: maxs | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Template Haskell | Version: 7.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 RyanGlScott): Indeed, it looks like this was fixed! In that case, we should add a regression test for this in GHC's test suite. mgsloan, do you want to pick up this task? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 14:05:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 14:05:45 -0000 Subject: [GHC] #11764: ghc internal error building llvm-general-3.5.1.2 In-Reply-To: <049.1e7850c7fbe53a08db3314e9a97a33fc@haskell.org> References: <049.1e7850c7fbe53a08db3314e9a97a33fc@haskell.org> Message-ID: <064.5925cfae1ce635d9343947e82b6922e2@haskell.org> #11764: ghc internal error building llvm-general-3.5.1.2 -------------------------------------+------------------------------------- Reporter: andrew.wja | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: cabal install | llvm-general Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: infoneeded => closed * resolution: => fixed Comment: Closing due to inability to reproduce the issue on newer GHCs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 14:09:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 14:09:10 -0000 Subject: [GHC] #15323: mkGadtDecl does not set con_forall correctly Message-ID: <044.5f29299703a0239f45578f0ada455c36@haskell.org> #15323: mkGadtDecl does not set con_forall correctly -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- A GADT declaration surrounded in parens does not det the `con_forall` field correctly. e.g. {{{#!hs data MaybeDefault v where TestParens :: (forall v . (Eq v) => MaybeDefault v) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 14:09:24 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 14:09:24 -0000 Subject: [GHC] #15323: mkGadtDecl does not set con_forall correctly In-Reply-To: <044.5f29299703a0239f45578f0ada455c36@haskell.org> References: <044.5f29299703a0239f45578f0ada455c36@haskell.org> Message-ID: <059.5cebb6e138e8cb889cd3072dc48c68ae@haskell.org> #15323: mkGadtDecl does not set con_forall correctly -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 alanz): * owner: (none) => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 14:22:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 14:22:16 -0000 Subject: [GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker In-Reply-To: <049.2656489ff85910f6a80bbfa971643315@haskell.org> References: <049.2656489ff85910f6a80bbfa971643315@haskell.org> Message-ID: <064.738a00066b64e3d722e0145892acaa1b@haskell.org> #15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11547 #14052 | Differential Rev(s): #15202 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * owner: sighingnow => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 14:26:42 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 14:26:42 -0000 Subject: [GHC] #15320: Save the types in the typechecked syntax tree In-Reply-To: <045.b1f7982e4ba945cea432856f673a60a4@haskell.org> References: <045.b1f7982e4ba945cea432856f673a60a4@haskell.org> Message-ID: <060.e5981c9e1278497ec7bdd2639288742b@haskell.org> #15320: Save the types in the typechecked syntax tree -------------------------------------+------------------------------------- Reporter: nboldi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 goldfire): You'll have a very hard time with the latter: GHC never produces `HsType GhcTc`s. Instead, the kind-checker just produces `TcType`s, which are in the Core AST, not the Haskell one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 14:34:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 14:34:06 -0000 Subject: [GHC] #14025: Object of a dependent c-file is put in wrong directory when this dependent is specified with a path (was: Object file is put in wrong directory when any source has absolute path) In-Reply-To: <046.48759c75ff80de33ebc22ad9a6eaaf3e@haskell.org> References: <046.48759c75ff80de33ebc22ad9a6eaaf3e@haskell.org> Message-ID: <061.4271be83551d8ac72b5a4f45d49eaaae@haskell.org> #14025: Object of a dependent c-file is put in wrong directory when this dependent is specified with a path -------------------------------------+------------------------------------- Reporter: literon | Owner: RolandSenn 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 RolandSenn): This bug has nothing to with absolute pathes! As soon as you specify the dep.c with a directory (different from ./) {{{ ghc -odir myodir A.hs subdir/dep.c }}} then GHC will write the dep.o file to myodir/subdir/dep.o . The bug occurs only if the dependent file is a ''*.c'' (or similar) file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 15:09:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 15:09:05 -0000 Subject: [GHC] #9672: Error message too long (full case statement printed) In-Reply-To: <051.99a860bf6093bb48bfa9c98f3e2d6cd2@haskell.org> References: <051.99a860bf6093bb48bfa9c98f3e2d6cd2@haskell.org> Message-ID: <066.e726c778d1d18b21f85d976a9653858b@haskell.org> #9672: Error message too long (full case statement printed) -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: RolandSenn => (none) Comment: After looking into the code and after reading #8809 I decided to return this ticket. Please feel free to take and solve it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 15:12:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 15:12:10 -0000 Subject: [GHC] #12674: GHC doesn't handle ./ prefixed paths correctly In-Reply-To: <047.897ae5e9c5c47ed13f84034ccb7c5729@haskell.org> References: <047.897ae5e9c5c47ed13f84034ccb7c5729@haskell.org> Message-ID: <062.d1ea89b390ab1adb636f4adae3581d45@haskell.org> #12674: GHC doesn't handle ./ prefixed paths correctly -------------------------------------+------------------------------------- Reporter: dobenour | Owner: RolandSenn Type: bug | Status: new Priority: normal | Milestone: Component: Driver | 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: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn Comment: I'll work on this ticket! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 17:26:17 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 17:26:17 -0000 Subject: [GHC] #12449: Broken types in identifiers bound by :print In-Reply-To: <044.542a5d089ce4efa7862430871616a137@haskell.org> References: <044.542a5d089ce4efa7862430871616a137@haskell.org> Message-ID: <059.10c8305610b36c5e0ff6713de91e8087@haskell.org> #12449: Broken types in identifiers bound by :print -------------------------------------+------------------------------------- Reporter: mniip | 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: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by anarchist666): * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 18:16:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 18:16:09 -0000 Subject: [GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin In-Reply-To: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> References: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> Message-ID: <062.a2a002bc4bf50ab6cf257e11c6cb4d64@haskell.org> #15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | typeable,knownnat Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10348 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by diatchki): My thinking was as follows: we are treating `Nat` and `Symbol` as just infinite families of type constructors. This makes is tricky to define class instances involving them, as we essentially need to write infinitely many instances. For example: {{{ instance MyClass (T 0) where ... instance MyClass (T 1) where ... ...etc... }}} To avoid having to provide some special mechanism for declaring such instances, we just define one special class that captures this pattern, and the instances are "magically" provided by GHC. For `Nat` it is called `KnownNat`: {{{ instance KnownNat 0 where ... instance KnownNat 1 where ... ... etc .. }}} This makes it possible to define "infinite" instances for any class like this: {{{ instance KnownNat n => MyClass (T n) where ... }}} We do the exact same thing for `Typeable`: {{{ instance KnownNat n => Typeable (n :: Nat) where ... }}} The `KnownNat` constraint provides the run-time representation of the number, which is used to build the run-time representation of the type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 19:01:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 19:01:46 -0000 Subject: [GHC] #15323: mkGadtDecl does not set con_forall correctly In-Reply-To: <044.5f29299703a0239f45578f0ada455c36@haskell.org> References: <044.5f29299703a0239f45578f0ada455c36@haskell.org> Message-ID: <059.b40dbd6de1e8766a48d14b5a91ee281e@haskell.org> #15323: mkGadtDecl does not set con_forall correctly -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 Alan Zimmerman ): In [changeset:"6e4e6d1c674a9d0257ca5c6caa26da18edf8ad8c/ghc" 6e4e6d1c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6e4e6d1c674a9d0257ca5c6caa26da18edf8ad8c" Fix mkGadtDecl does not set con_forall correctly A GADT declaration surrounded in parens does not det the con_forall field correctly. e.g. data MaybeDefault v where TestParens :: (forall v . (Eq v) => MaybeDefault v) Closes #15323 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 19:05:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 19:05:39 -0000 Subject: [GHC] #15323: mkGadtDecl does not set con_forall correctly In-Reply-To: <044.5f29299703a0239f45578f0ada455c36@haskell.org> References: <044.5f29299703a0239f45578f0ada455c36@haskell.org> Message-ID: <059.0caee5f597c6eb8a97383c35f3833d2c@haskell.org> #15323: mkGadtDecl does not set con_forall correctly -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 alanz): * status: new => merge Comment: For ghc-8.6, please -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 20:04:31 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 20:04:31 -0000 Subject: [GHC] #15324: -ddump-splices does not parenthesize rank-n contexts correctly Message-ID: <050.ee7a8b6246f694a0997d3f3ae67f6212@haskell.org> #15324: -ddump-splices does not parenthesize rank-n contexts correctly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template | Version: 8.4.3 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Ryan discovers another `-ddump-splices` bug—news at 11: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where $([d| f :: forall a. (Show a => a) -> a f _ = undefined |]) }}} {{{ $ /opt/ghc/8.4.3/bin/ghci Bug.hs -dsuppress-uniques GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(6,3)-(8,6): Splicing declarations [d| f :: forall a. (Show a => a) -> a f _ = undefined |] ======> f :: forall a. Show a => a -> a f _ = undefined }}} Notice that `f`'s type signature is pretty-printed as `forall a. Show a => a -> a`, which is just wrong. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 20:08:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 20:08:27 -0000 Subject: [GHC] #15324: -ddump-splices does not parenthesize rank-n contexts correctly In-Reply-To: <050.ee7a8b6246f694a0997d3f3ae67f6212@haskell.org> References: <050.ee7a8b6246f694a0997d3f3ae67f6212@haskell.org> Message-ID: <065.0ef0d109c9161b9363e2f0c39cb49e0d@haskell.org> #15324: -ddump-splices does not parenthesize rank-n contexts correctly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.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:D4910 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4910 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 20:35:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 20:35:02 -0000 Subject: [GHC] #11024: Fix strange parsing of BooleanFormula In-Reply-To: <049.1026878f17212bef28601e22c8ebf782@haskell.org> References: <049.1026878f17212bef28601e22c8ebf782@haskell.org> Message-ID: <064.1acda16311e08bca5d944e018f48739b@haskell.org> #11024: Fix strange parsing of BooleanFormula -------------------------------------+------------------------------------- Reporter: mpickering | Owner: ethercrow Type: task | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | 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: | https://phabricator.haskell.org/D3139 -------------------------------------+------------------------------------- Comment (by ethercrow): Yes, this can be closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 21:17:01 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 21:17:01 -0000 Subject: [GHC] #11024: Fix strange parsing of BooleanFormula In-Reply-To: <049.1026878f17212bef28601e22c8ebf782@haskell.org> References: <049.1026878f17212bef28601e22c8ebf782@haskell.org> Message-ID: <064.1b9fc92883b3db489628650daf51e14a@haskell.org> #11024: Fix strange parsing of BooleanFormula -------------------------------------+------------------------------------- Reporter: mpickering | Owner: ethercrow Type: task | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | 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): Wiki Page: | https://phabricator.haskell.org/D3139 -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 21:41:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 21:41:12 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.250b38bc6f2ad7c5f6395e0531a72553@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler (Type | Version: None checker) | 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 Crazycolorz5): I'll take a look at implementing this in the fashion suggested in comment 30. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 22:22:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 22:22:06 -0000 Subject: [GHC] #15321: Typed holes in Template Haskell splices produce bewildering error messages In-Reply-To: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> References: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> Message-ID: <065.a9e0cbeb88e8b197f51e83904d467335@haskell.org> #15321: Typed holes in Template Haskell splices produce bewildering error messages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: TypedHoles 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 mgsloan): I've considered this further, and I'm thinking my concerns about masking errors may be unfounded. Problems typechecking candidates are likely to be discovered other ways. On the other hand, this might be an interesting way to have users fuzz testing the typechecker ;) Your change looks good to me. I think something like https://phabricator.haskell.org/D4907 may still make sense, but I'll leave it up to y'all. It is certainly an efficiency / complexity tradeoff. One benefit beyond efficiency is that `-ddump-tc- trace` might be slightly more comprehensible if it isn't evaluating holes that the typechecker errors on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jun 29 22:32:08 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Jun 2018 22:32:08 -0000 Subject: [GHC] #15321: Typed holes in Template Haskell splices produce bewildering error messages In-Reply-To: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> References: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> Message-ID: <065.694a80dad19c87e4c35700e5a004ccdb@haskell.org> #15321: Typed holes in Template Haskell splices produce bewildering error messages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: TypedHoles 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 Tritlo): I agree, it would both be faster and produce better output in the tc trace, but just discarding candidates that cause errors is the right thing to do, since those aren't valid hole fits anyway (since they cause an error). I think that further work to optimize and improve is in order, but I hope that the current patch is small enough to make it into 8.6 without issue, and leave the more thoughtful overhaul for later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 30 00:04:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jun 2018 00:04:05 -0000 Subject: [GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker In-Reply-To: <049.2656489ff85910f6a80bbfa971643315@haskell.org> References: <049.2656489ff85910f6a80bbfa971643315@haskell.org> Message-ID: <064.ad1515d9f38ac574c5a95b4bd2036964@haskell.org> #15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11547 #14052 | Differential Rev(s): #15202 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): This is fixed in https://phabricator.haskell.org/D4909 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 30 05:19:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jun 2018 05:19:32 -0000 Subject: [GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 In-Reply-To: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> References: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> Message-ID: <066.67d67b9ca83170586a18675711e284eb@haskell.org> #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by NathanWaivio): * Attachment "ghc-8.0.2-v.txt" added. verbose output of ghc-8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 30 05:20:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jun 2018 05:20:08 -0000 Subject: [GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 In-Reply-To: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> References: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> Message-ID: <066.1c27137ca0c14d40f1051b251203821d@haskell.org> #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NathanWaivio): I have now been able to analyze the differences between ghc-8.0.2 to ghc-8.2.2. Here is a table of the growth of the number of terms per iteration of the Simplifier: ||= Simplifier Iteration =|| 1 || 2 || 3 || 4 || || ghc-8.0.2 || 118,835 || 138,330 || 172,291 || 516,767 || || ghc-8.2.2 || 149,046 || 185,066 || 15,190,006 || 12,310,166 || Apparently the largest difference occurs in Simplifier Iteration 3. What is going on with Simplifier Iteration 3? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 30 08:39:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jun 2018 08:39:09 -0000 Subject: [GHC] #14471: Certain do blocks cause TH to barf when ApplicativeDo is enabled In-Reply-To: <050.4f7b341f8e72d76f8691291adb62b498@haskell.org> References: <050.4f7b341f8e72d76f8691291adb62b498@haskell.org> Message-ID: <065.b3ef18386db8547afa798018e4477222@haskell.org> #14471: Certain do blocks cause TH to barf when ApplicativeDo is enabled -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: mgsloan Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo 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:D4912 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mgsloan): * owner: (none) => mgsloan * differential: => Phab:D4912 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 30 08:47:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jun 2018 08:47:17 -0000 Subject: [GHC] #14627: qAddTopDecls: can't convert top-level declarations In-Reply-To: <049.485d47f57c339e482133548d02dc333a@haskell.org> References: <049.485d47f57c339e482133548d02dc333a@haskell.org> Message-ID: <064.a21fe7cb0a4895ad3c2ffb36ba8cb03b@haskell.org> #14627: qAddTopDecls: can't convert top-level declarations -------------------------------------+------------------------------------- Reporter: tianxiaogu | Owner: mgsloan Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.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 mgsloan): * owner: (none) => mgsloan -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 30 14:38:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jun 2018 14:38:12 -0000 Subject: [GHC] #15325: Panic in getIdFromTrivialExpr with -fdefer-type-errors Message-ID: <050.bf11294bfa46fbb2d7747b428a80c7a3@haskell.org> #15325: Panic in getIdFromTrivialExpr with -fdefer-type-errors -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- == Steps to reproduce: Put this in `bug.hs`: (It's a very failed attempt to make a polymorphic list maker function.) {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} module PolyvariadicFunctions where class PolyList e a where polyList :: ([e] -> [e]) -> a -- instance PolyList e [e] where -- polyList dl = dl [] instance (e ~ e2, PolyList e a) => PolyList e (e2 -> a) where polyList dl x = polyList ((x :) . dl) plh :: [Integer] plh = polyList 1 2 3 4 5 }}} Load it in GHCi with `-fdefer-type-errors` to get the following output. Note the 'panic' in the end, and also note that the last `>` line is a no- module-loaded GHCi prompt. The question marks `?` seem to be encoding related and not relevant. This panic not seem to occur with GHC the compiler. The rest of the error messages seem otherwise identical. {{{ GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> :set -fdefer-type-errors Prelude> :l bug.hs [1 of 1] Compiling PolyvariadicFunctions ( bug.hs, interpreted ) bug.hs:17:7: warning: [-Wdeferred-type-errors] ? No instance for (PolyList t0 [Integer]) arising from a use of ‘polyList’ ? In the expression: polyList 1 2 3 4 5 In an equation for ‘plh’: plh = polyList 1 2 3 4 5 | 17 | plh = polyList 1 2 3 4 5 | ^^^^^^^^^^^^^^^^^^ bug.hs:17:16: warning: [-Wdeferred-type-errors] ? No instance for (Num ([t0] -> [t0])) arising from the literal ‘1’ (maybe you haven't applied a function to enough arguments?) ? In the first argument of ‘polyList’, namely ‘1’ In the expression: polyList 1 2 3 4 5 In an equation for ‘plh’: plh = polyList 1 2 3 4 5 | 17 | plh = polyList 1 2 3 4 5 | ^ bug.hs:17:18: warning: [-Wdeferred-type-errors] ? Ambiguous type variable ‘t0’ arising from the literal ‘2’ prevents the constraint ‘(Num t0)’ from being solved. Probable fix: use a type annotation to specify what ‘t0’ should be. These potential instances exist: instance Num Integer -- Defined in ‘GHC.Num’ instance Num Double -- Defined in ‘GHC.Float’ instance Num Float -- Defined in ‘GHC.Float’ ...plus two others (use -fprint-potential-instances to see them all) ? In the second argument of ‘polyList’, namely ‘2’ In the expression: polyList 1 2 3 4 5 In an equation for ‘plh’: plh = polyList 1 2 3 4 5 | 17 | plh = polyList 1 2 3 4 5 | ^ ghc.exe: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-mingw32): getIdFromTrivialExpr case $dNum_a1Be of wild_00 { } Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler\utils\Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler\\coreSyn\\CoreUtils.hs:883:18 in ghc:CoreUtils 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 Jun 30 15:39:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jun 2018 15:39:02 -0000 Subject: [GHC] #15325: GHCi panic in getIdFromTrivialExpr with -fdefer-type-errors (was: Panic in getIdFromTrivialExpr with -fdefer-type-errors) In-Reply-To: <050.bf11294bfa46fbb2d7747b428a80c7a3@haskell.org> References: <050.bf11294bfa46fbb2d7747b428a80c7a3@haskell.org> Message-ID: <065.8dc281c63500f0215cc43f5ec993b407@haskell.org> #15325: GHCi panic in getIdFromTrivialExpr with -fdefer-type-errors -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 30 15:41:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jun 2018 15:41:58 -0000 Subject: [GHC] #3160: No exception safety in Control.Concurrent.QSem QSemN and SampleVar In-Reply-To: <053.70a1854543dd01f0108efd70a01e67de@haskell.org> References: <053.70a1854543dd01f0108efd70a01e67de@haskell.org> Message-ID: <068.5a4a9cd251d87dd0c654db97ae4945c1@haskell.org> #3160: No exception safety in Control.Concurrent.QSem QSemN and SampleVar -------------------------------------+------------------------------------- Reporter: ChrisKuklewicz | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 7.0.2 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: | -------------------------------------+------------------------------------- Comment (by domenkozar): For reference see https://ghc.haskell.org/trac/ghc/ticket/7417#comment:5 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 30 16:29:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jun 2018 16:29:00 -0000 Subject: [GHC] #15326: Add option to disable error message expression context (the 'In the expression' things) Message-ID: <050.d8b5750cd390deaca2bcecfe092d3c9f@haskell.org> #15326: Add option to disable error message expression context (the 'In the expression' things) -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- A typical error looks like this: {{{ bug.hs:17:7: warning: [-Wdeferred-type-errors] ? No instance for (PolyList t0 [Integer]) arising from a use of ‘polyList’ ? In the expression: polyList 1 2 3 4 5 In an equation for ‘plh’: plh = polyList 1 2 3 4 5 | 17 | plh = polyList 1 2 3 4 5 | ^^^^^^^^^^^^^^^^^^ }}} Note the two lines starting with `In`. They waste two lines of error message space and now provides near zero utility since: 1. There's a caret view right below that context. 2. There are editor integrations that show squiggles right in the editor. Now we have an option `-f[no-]diagnostics-show-caret` that disables the caret. It would be great to have one that disables those code context lines too. As for naming. I'm thinking about `-f[no-]diagnostics-show-context`, which may be confused with constraint contexts, and `-f[no-]diagnostics-show- code-context`, which is a bit too long. I don't really know what those context lines are properly called, so maybe someone can come up with a more precise one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 30 16:31:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jun 2018 16:31:45 -0000 Subject: [GHC] #15326: Add option to disable error message expression context (the 'In the expression' things) In-Reply-To: <050.d8b5750cd390deaca2bcecfe092d3c9f@haskell.org> References: <050.d8b5750cd390deaca2bcecfe092d3c9f@haskell.org> Message-ID: <065.2a9775b85a0c92f87678dacce1627956@haskell.org> #15326: Add option to disable error message expression context (the 'In the expression' things) -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 dramforever: Old description: > A typical error looks like this: > > {{{ > bug.hs:17:7: warning: [-Wdeferred-type-errors] > ? No instance for (PolyList t0 [Integer]) > arising from a use of ‘polyList’ > ? In the expression: polyList 1 2 3 4 5 > In an equation for ‘plh’: plh = polyList 1 2 3 4 5 > | > 17 | plh = polyList 1 2 3 4 5 > | ^^^^^^^^^^^^^^^^^^ > }}} > > Note the two lines starting with `In`. They waste two lines of error > message space and now provides near zero utility since: > > 1. There's a caret view right below that context. > 2. There are editor integrations that show squiggles right in the editor. > > Now we have an option `-f[no-]diagnostics-show-caret` that disables the > caret. It would be great to have one that disables those code context > lines too. > > As for naming. I'm thinking about `-f[no-]diagnostics-show-context`, > which may be confused with constraint contexts, and `-f[no-]diagnostics- > show-code-context`, which is a bit too long. I don't really know what > those context lines are properly called, so maybe someone can come up > with a more precise one. New description: A typical error looks like this: {{{ bug.hs:17:7: warning: [-Wdeferred-type-errors] ? No instance for (PolyList t0 [Integer]) arising from a use of ‘polyList’ ? In the expression: polyList 1 2 3 4 5 In an equation for ‘plh’: plh = polyList 1 2 3 4 5 | 17 | plh = polyList 1 2 3 4 5 | ^^^^^^^^^^^^^^^^^^ }}} Note the two lines starting with `In`. They waste two lines of error message space and now provides near zero utility since: 1. There's a caret view right below that context. 2. There are editor integrations that show squiggles right in the editor. Now we have an option `-f[no-]diagnostics-show-caret` that disables the caret. It would be great to have one that disables those code context lines too. This would make code errors shorter and easier to scroll through and read. And in editor integration, this would make the, say, error message popup less of a 'wall of text'. As for naming. I'm thinking about `-f[no-]diagnostics-show-context`, which may be confused with constraint contexts, and `-f[no-]diagnostics-show- code-context`, which is a bit too long. I don't really know what those context lines are properly called, so maybe someone can come up with a more precise one. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 30 18:11:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jun 2018 18:11:06 -0000 Subject: [GHC] #15325: GHCi panic in getIdFromTrivialExpr with -fdefer-type-errors In-Reply-To: <050.bf11294bfa46fbb2d7747b428a80c7a3@haskell.org> References: <050.bf11294bfa46fbb2d7747b428a80c7a3@haskell.org> Message-ID: <065.c3cbf997dcbc2bc041a9643a2efae53d@haskell.org> #15325: GHCi panic in getIdFromTrivialExpr with -fdefer-type-errors -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 monoidal): Confirmed in master, here's a simpler case: {{{ #!hs module T15325 where class PolyList e where polyList :: e -> () f :: PolyList e => e -> () f x = polyList x plh :: () plh = f 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 30 20:28:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jun 2018 20:28:43 -0000 Subject: [GHC] #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) In-Reply-To: <046.b48445f821d50909a0ec2f285f6886c0@haskell.org> References: <046.b48445f821d50909a0ec2f285f6886c0@haskell.org> Message-ID: <061.2e048b2d4db26770ceb207cdb5c929c6@haskell.org> #8695: Arithmetic overflow from (minBound :: Int) `quot` (-1) -------------------------------------+------------------------------------- Reporter: rleslie | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #1042 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: nh2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 30 20:46:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jun 2018 20:46:23 -0000 Subject: [GHC] #15327: Optimize remainders by powers of two for Integer and Natural Message-ID: <047.622e50c19a30545c881539436f767344@haskell.org> #15327: Optimize remainders by powers of two for Integer and Natural -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.4.3 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14437 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It appears that GHC does not optimise `even (n :: Integer)` to a bitwise check, as it does for `Int` and `Word` (#14437). Here is a benchmark: {{{#!hs import Data.Time.Clock evenRem :: Integer -> Bool evenRem n = fromIntegral n `rem` 2 == (0 :: Word) lim :: Integer lim = 100000000 main :: IO () main = do t0 <- getCurrentTime print $ maximum $ filter even [1..lim] t1 <- getCurrentTime putStrLn "even" print $ diffUTCTime t1 t0 t0 <- getCurrentTime print $ maximum $ filter evenRem [1..lim] t1 <- getCurrentTime putStrLn "evenRem" print $ diffUTCTime t1 t0 }}} {{{ $ ghc -O2 Even.hs [1 of 1] Compiling Main ( Even.hs, Even.o ) Linking Even ... $ ./Even 100000000 even 6.367393s 100000000 evenRem 4.35664s }}} The reason is that `even (n :: Integer)` results in `remInteger` call in CMM, which remains unoptimized. One possible solution is to add a special case of divisor 2 to `GHC.Integer.Type.remInteger`. Or perhaps even something like {{{#!hs remInteger n (S# d#) | isPowerOfTwo (I# d#) = fromIntegral (fromIntegral n `rem` I# d#) isPowerOfTwo :: Int -> Bool isPowerOfTwo d = d /= 0 && d .&. (complement d + 1) == d }}} Since `remInteger` is not inlined during Core pipeline, such implementation of `even` will pattern-match in runtime, which is a bit suboptimal. On my machine it benchmarks halfway between `even` and `evenRem` above. Alternative approach is to add new rules to `PrelRules.builtinIntegerRules` to avoid any possible runtime slowdown. Is is appropriate? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 30 21:01:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jun 2018 21:01:08 -0000 Subject: [GHC] #15325: GHCi panic in getIdFromTrivialExpr with -fdefer-type-errors In-Reply-To: <050.bf11294bfa46fbb2d7747b428a80c7a3@haskell.org> References: <050.bf11294bfa46fbb2d7747b428a80c7a3@haskell.org> Message-ID: <065.8f8107b8716ef7fbf7960286a0553650@haskell.org> #15325: GHCi panic in getIdFromTrivialExpr with -fdefer-type-errors -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) Comment: This is a regression from GHC 8.2.2, which did not exhibit this panic. The offending commit is 33452dfc6cf891b59d63fa9fe138b18cbce4df81 (`Refactor the Mighty Simplifier`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 30 21:11:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jun 2018 21:11:23 -0000 Subject: [GHC] #15328: cpphs: internal error: evacuate(static): strange closure type 8440 Message-ID: <044.e7d3083ced1a98874e271c4b45548264@haskell.org> #15328: cpphs: internal error: evacuate(static): strange closure type 8440 -------------------------------------+------------------------------------- Reporter: cnmne | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Package | Version: 8.4.3 system | Keywords: cabal, cpphs, | Operating System: MacOS X strange closure | Type of failure: Building GHC Architecture: x86 | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Attempting to install Agda via Cabal fails. I've installed cpphs through Cabal and {{{~/Library/Haskell/bin}}} is in my path. {{{~/.cabal/config}}} is default, but in {{{/Library/Frameworks/GHC.framework/Versions/8.4.3-x86_64/usr/lib/ghc-8.4.3 /settings}}} I have changed only {{{("C compiler supports -no- pie","NO")}}} (from "YES") because that was giving me errors earlier. The log states: "Please report this as a GHC bug..." so here I am :] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 30 21:12:33 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jun 2018 21:12:33 -0000 Subject: [GHC] #15328: cpphs: internal error: evacuate(static): strange closure type 8440 In-Reply-To: <044.e7d3083ced1a98874e271c4b45548264@haskell.org> References: <044.e7d3083ced1a98874e271c4b45548264@haskell.org> Message-ID: <059.85fef6c3ec323eb00d60cb9fe7430c56@haskell.org> #15328: cpphs: internal error: evacuate(static): strange closure type 8440 -------------------------------------+------------------------------------- Reporter: cnmne | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Package system | Version: 8.4.3 Resolution: | Keywords: cabal, cpphs, | strange closure Operating System: MacOS X | Architecture: x86 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by cnmne): * Attachment "Agda-2.5.4-8dEVcms4EEl7BLLd7N0hcZ.log" added. Cabal failure to build Agda log file -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 30 23:32:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jun 2018 23:32:32 -0000 Subject: [GHC] #15329: Cannot parse `type (*)` in fixity declaration Message-ID: <047.29f9825bd03c372c5062f690254f7bbf@haskell.org> #15329: Cannot parse `type (*)` in fixity declaration -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- Vanessa McHale posts: The parser seems to be broken. Attempting to build [http://hackage.haskell.org/package/basement basement] yields: {{{ Basement/Nat.hs:15:46: error: parse error on input ‘*’ | 15 | , type (<=), type (<=?), type (+), type (*), type (^), type (-) | ^ }}} This is actually in 8.6.0, but there is no version option for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jun 30 23:35:44 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Jun 2018 23:35:44 -0000 Subject: [GHC] #15329: Cannot parse `type (*)` in fixity declaration In-Reply-To: <047.29f9825bd03c372c5062f690254f7bbf@haskell.org> References: <047.29f9825bd03c372c5062f690254f7bbf@haskell.org> Message-ID: <062.519250d4908a9371f1258e9317e85d50@haskell.org> #15329: Cannot parse `type (*)` in fixity declaration -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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): There's already a patch in head.hackage which fixes this. https://github.com/bgamari/head.hackage/blob/master/patches/basement-0.0.7.patch -- Ticket URL: GHC The Glasgow Haskell Compiler