From ghc-devs at haskell.org Thu Oct 1 04:34:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Oct 2015 04:34:27 -0000 Subject: [GHC] #10923: GHC should recompile if flags change Message-ID: <045.701a073c5a04ad8846380b456c6613ef@haskell.org> #10923: GHC should recompile if flags change -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- Example: {{{ ezyang at sabre:~$ rm B.hi ezyang at sabre:~$ Dev/ghc-7.10.2/usr/bin/ghc -c B.hs ezyang at sabre:~$ Dev/ghc-7.10.2/usr/bin/ghc -c B.hs -O compilation IS NOT required }}} Pretty minor, but would be nice to have fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 1 04:35:20 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Oct 2015 04:35:20 -0000 Subject: [GHC] #10915: Statistical profiling support in the RTS In-Reply-To: <046.7220ccda33e87c4faaaf43cf13abd1b6@haskell.org> References: <046.7220ccda33e87c4faaaf43cf13abd1b6@haskell.org> Message-ID: <061.57bdf68d17786d421943da58a804c674@haskell.org> #10915: Statistical profiling support in the RTS -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1215, | Phab:D1214 -------------------------------------+------------------------------------- Changes (by rrnewton): * cc: rrnewton (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 1 04:36:34 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Oct 2015 04:36:34 -0000 Subject: [GHC] #10915: Statistical profiling support in the RTS In-Reply-To: <046.7220ccda33e87c4faaaf43cf13abd1b6@haskell.org> References: <046.7220ccda33e87c4faaaf43cf13abd1b6@haskell.org> Message-ID: <061.9e493f8cc661d124a8c1270537241f96@haskell.org> #10915: Statistical profiling support in the RTS -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1215, | Phab:D1214 -------------------------------------+------------------------------------- Comment (by rrnewton): At ICFP, didn't @tibbe report that someone was already using some kind of statistical profiling tools with GHC? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 1 13:34:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Oct 2015 13:34:32 -0000 Subject: [GHC] #10914: Bad symbol resolution on Darwin when using DYLD_FORCE_FLAT_NAMESPACE=1 In-Reply-To: <047.9268eb7f03934b85eb39681f4890afc7@haskell.org> References: <047.9268eb7f03934b85eb39681f4890afc7@haskell.org> Message-ID: <062.44228bdcaad32586b115b6f0503aefd9@haskell.org> #10914: Bad symbol resolution on Darwin when using DYLD_FORCE_FLAT_NAMESPACE=1 -------------------------------------+------------------------------------- Reporter: jacereda | Owner: Type: bug | Status: patch Priority: high | Milestone: Component: Runtime System | Version: 7.10.2 (Linker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by jacereda): Just finished compiling HEAD. Will resend the patches to Phabricator. As for the test, I'm not sure how to handle that. I guess adding Data.Hashable to the suite just for this is overkill... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 1 13:39:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Oct 2015 13:39:00 -0000 Subject: [GHC] #8279: bad alignment in code gen yields substantial perf issue In-Reply-To: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> References: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> Message-ID: <060.8f0d7d6728af521007e8ad2c41915f95@haskell.org> #8279: bad alignment in code gen yields substantial perf issue -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8082 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by rwbarton): Some related reading material: * "Producing Wrong Data Without Doing Anything Obviously Wrong!", http://sape.inf.usi.ch/publications/asplos09 * Stabilizer, http://plasma.cs.umass.edu/emery/stabilizer * MAO - an Extensible Micro-Architectural Optimizer, http://research.google.com/pubs/pub37077.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 1 14:36:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Oct 2015 14:36:15 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.792ca1ee88df76a52751ce8bd448957b@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) ---------------------------------+-------------------------------------- Reporter: rleslie | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ---------------------------------+-------------------------------------- Comment (by mboes): This issue is preventing `stack repl` or `cabal repl` from working in the inline-r package of the HaskellR project. It is therefore not currently possible to hack on inline-r code in GHCi. Any chance a fix for this will make it into 7.10.3? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 1 15:44:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Oct 2015 15:44:13 -0000 Subject: [GHC] #10900: Suggestions for improvement of the PatternSynonyms chapter in the User's Guide In-Reply-To: <045.3ca8c7c70c117f1fbb26e794adbec55f@haskell.org> References: <045.3ca8c7c70c117f1fbb26e794adbec55f@haskell.org> Message-ID: <060.fac89e28b407041c0eac16f7c07c5ee3@haskell.org> #10900: Suggestions for improvement of the PatternSynonyms chapter in the User's Guide -------------------------------------+------------------------------------- Reporter: thomie | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.2 Resolution: | Keywords: | PatternSynonms Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by mpickering): >> so function f is rejected because the type signature is Maybe > I tried this example, and f is not rejected at all. Bug? I'm working through this now, if you add the type signature it suggests then it does fail to compile. However, the most general type works fine which I imagine is what you discovered. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 1 16:36:20 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Oct 2015 16:36:20 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.865b0d04f922fea29085d3a2892dcc98@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: trommler Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Changes (by trommler): * status: new => patch * differential: => Phab:D1296 Comment: I have uploaded a first attempt into Phabricator. It validates on Linux x86_64. On powerpc64 (big endian) I see no more errors than before in validate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 1 16:51:36 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Oct 2015 16:51:36 -0000 Subject: [GHC] #1831: reify never provides the declaration of variables In-Reply-To: <044.a26292943bffdeb4bdb3ded03525ce1f@haskell.org> References: <044.a26292943bffdeb4bdb3ded03525ce1f@haskell.org> Message-ID: <059.a7c6b7892f1fc3d9f57f09cbb55ad0c6@haskell.org> #1831: reify never provides the declaration of variables -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.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): -------------------------------------+------------------------------------- Comment (by tomberek): I will +1 polkovnikov.ph's comments. Especially with regards to translation libraries and generalized arrows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 1 17:38:09 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Oct 2015 17:38:09 -0000 Subject: [GHC] #10912: Support for out of the box static linking In-Reply-To: <045.dd87a2c5256e85911413677e3011cd99@haskell.org> References: <045.dd87a2c5256e85911413677e3011cd99@haskell.org> Message-ID: <060.29d69a68392add30291b08b9d2d79d92@haskell.org> #10912: Support for out of the box static linking -------------------------------------+------------------------------------- Reporter: crb002 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by rwbarton): Is `-optl-static` not enough? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 1 17:40:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Oct 2015 17:40:48 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.ab91ecd68442cdf6f42df5ae571a7c9b@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) ---------------------------------+-------------------------------------- Reporter: rleslie | Owner: trommler Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ---------------------------------+-------------------------------------- Changes (by trommler): * owner: => trommler Comment: Replying to [comment:5 rwbarton]: > I'm a little worried about whether the obvious fix for this (adding `-lfoo` to the gcc command line for building the temporary shared objects for each library `-lfoo` specified on the ghci command line) might cause #8935 to occur again in some configurations. The right way to build a shared library would be to add `-lfoo`. Haskell libraries are linked with `-Bsymbolic` and I wonder if that would indeed make #8935 come back. Perhaps it is better to go for option one in my comment:12 and load C Libraries with `RTLD_GLOBAL` after all. I'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 1 18:48:59 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Oct 2015 18:48:59 -0000 Subject: [GHC] #10912: Support for out of the box static linking In-Reply-To: <045.dd87a2c5256e85911413677e3011cd99@haskell.org> References: <045.dd87a2c5256e85911413677e3011cd99@haskell.org> Message-ID: <060.411679d912df8aa287e7899519074583@haskell.org> #10912: Support for out of the box static linking -------------------------------------+------------------------------------- Reporter: crb002 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by crb002): No. You need static versions of the libraries that you bring in. That's a wget from http://libfoo.org/, configure;make; make install for each libfoo.a you are missing in your Haskell dev toolchain. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 1 19:00:34 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Oct 2015 19:00:34 -0000 Subject: [GHC] #10912: Support for out of the box static linking In-Reply-To: <045.dd87a2c5256e85911413677e3011cd99@haskell.org> References: <045.dd87a2c5256e85911413677e3011cd99@haskell.org> Message-ID: <060.a9e6df0d3e07742ee32f1b941ad2e063@haskell.org> #10912: Support for out of the box static linking -------------------------------------+------------------------------------- Reporter: crb002 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by rwbarton): Well of course ghc is not going to do the wget for you, and this is the ghc bug tracker. To put it another way: What concrete change to ghc are you asking for? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 1 21:14:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Oct 2015 21:14:10 -0000 Subject: [GHC] #10924: Template variable unbound in rewrite rule Message-ID: <047.723a648571c518eb9cf0f244f8acc218@haskell.org> #10924: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: singletons, | Operating System: Unknown/Multiple templatehaskell | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- The only ticket I see with this issues that *isn't* resolved in 7.10.2 is #10689. Might be a dup. Compiling with -O1 succeeds, but `ghc -O2` fails: {{{ {-# LANGUAGE DataKinds, GADTs, PolyKinds, ScopedTypeVariables, TemplateHaskell, TypeFamilies, UndecidableInstances #-} module Bug where -- needed to use Nat's Num instance for + import qualified GHC.Num as Num import Data.Singletons.Prelude import Data.Singletons.TH import Data.Type.Natural import Data.Typeable -- | Copied from Data.Type.Natural because the data-level version -- is not exported there. (<<=) :: Nat -> Nat -> Bool Z <<= _ = True S _ <<= Z = False S n <<= S m = n <<= m singletons [d| newtype PrimePower = PP (Nat,Nat) deriving (Eq,Show,Typeable) |] singletons [d| ppMul :: PrimePower -> [PrimePower] -> [PrimePower] ppMul x [] = [x] ppMul x@(PP(p,e)) pps@(PP (p',e'):pps') | p == p' = PP(p,e Num.+ e'):pps' | p <<= p' = x:pps | otherwise = (PP(p',e')):ppMul x pps' |] }}} {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Template variable unbound in rewrite rule t_XexU [t_aev4, t_aev5, n0_aeyH, n1_aeyI, n0_aeyV, n1_aeyW, ipv_sfxT, sc_sg53, sc_sg54, sg_sg55, sg_sg56, sc_sg57] [t_XexU, t_XexW, n0_XeBz, n1_XeBB, n0_XeBP, n1_XeBR, ipv_XfAP, sc_Xg80, sc_Xg82, sg_Xg84, sg_Xg86, sc_Xg88] [TYPE Let1627437970XSym7 n0_aeyH n1_aeyI n0_aeyV n1_aeyW ipv_sfxT t_aev4 t_aev5, TYPE ipv_sfxT, (SPP @ ('PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)) @ ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI) @~ <'PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)>_N ((STuple2 @ Nat @ Nat @ '(n0_aeyH, n1_aeyI) @ n0_aeyH @ n1_aeyI @~ <'(n0_aeyH, n1_aeyI)>_N sc_sg53 sc_sg54) `cast` (sg_sg55 :: R:Sing(,)z '(n0_aeyH, n1_aeyI) ~R# Sing (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI)))) `cast` (sg_sg56 :: R:SingPrimePowerz ('PP (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI)) ~R# Sing (Apply PPSym0 (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI))), sc_sg57] [TYPE Let1627437970XSym7 n0_aeyH n1_aeyI n0_XeB0 n1_XeB2 ipv_XfzF (Let1627437970XSym7 n0_aeyH n1_aeyI n0_aeyV n1_aeyW ipv_sfxT t_aev4 t_aev5) ipv_sfxT, TYPE ipv_XfzF, (SPP @ ('PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)) @ ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI) @~ <'PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)>_N ((STuple2 @ Nat @ Nat @ '(n0_aeyH, n1_aeyI) @ n0_aeyH @ n1_aeyI @~ <'(n0_aeyH, n1_aeyI)>_N sc_sg53 sc_sg54) `cast` (Sub (Sym (TFCo:R:Sing(,)z[0] _N _N)) (Sym (TFCo:R:Apply(,)kTuple2Sym1l0[0] _N _N _N _N) ; (Apply (Sym (TFCo:R:Apply(->)kTuple2Sym0l0[0] _N _N _N)) _N)_N) :: R:Sing(,)z (Tuple2Sym2 n0_aeyH n1_aeyI) ~R# Sing (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI)))) `cast` (Sub (Sym TFCo:R:SingPrimePowerz[0]) (Sym (TFCo:R:ApplyPrimePower(,)PPSym0l0[0] <(Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI>_N)) :: R:SingPrimePowerz (PPSym1 ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)) ~R# Sing (Apply PPSym0 ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI))), ipv_sfxW] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 1 21:15:34 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Oct 2015 21:15:34 -0000 Subject: [GHC] #10924: Template variable unbound in rewrite rule In-Reply-To: <047.723a648571c518eb9cf0f244f8acc218@haskell.org> References: <047.723a648571c518eb9cf0f244f8acc218@haskell.org> Message-ID: <062.b2b277b7e19eedd7fdbd49357e555a9b@haskell.org> #10924: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: singletons, | templatehaskell Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Description changed by crockeea: Old description: > The only ticket I see with this issues that *isn't* resolved in 7.10.2 is > #10689. Might be a dup. > > Compiling with -O1 succeeds, but `ghc -O2` fails: > > {{{ > {-# LANGUAGE DataKinds, GADTs, PolyKinds, ScopedTypeVariables, > TemplateHaskell, TypeFamilies, UndecidableInstances #-} > > module Bug where > > -- needed to use Nat's Num instance for + > import qualified GHC.Num as Num > > import Data.Singletons.Prelude > import Data.Singletons.TH > import Data.Type.Natural > import Data.Typeable > > -- | Copied from Data.Type.Natural because the data-level version > -- is not exported there. > (<<=) :: Nat -> Nat -> Bool > Z <<= _ = True > S _ <<= Z = False > S n <<= S m = n <<= m > > singletons [d| > > newtype PrimePower = PP (Nat,Nat) deriving (Eq,Show,Typeable) > > |] > singletons [d| > > ppMul :: PrimePower -> [PrimePower] -> [PrimePower] > ppMul x [] = [x] > ppMul x@(PP(p,e)) pps@(PP (p',e'):pps') > | p == p' = PP(p,e Num.+ e'):pps' > | p <<= p' = x:pps > | otherwise = (PP(p',e')):ppMul x pps' > > |] > }}} > > > {{{ > ghc: panic! (the 'impossible' happened) > (GHC version 7.10.2 for x86_64-unknown-linux): > Template variable unbound in rewrite rule > t_XexU > [t_aev4, t_aev5, n0_aeyH, n1_aeyI, n0_aeyV, n1_aeyW, ipv_sfxT, > sc_sg53, sc_sg54, sg_sg55, sg_sg56, sc_sg57] > [t_XexU, t_XexW, n0_XeBz, n1_XeBB, n0_XeBP, n1_XeBR, ipv_XfAP, > sc_Xg80, sc_Xg82, sg_Xg84, sg_Xg86, sc_Xg88] > [TYPE Let1627437970XSym7 > n0_aeyH n1_aeyI n0_aeyV n1_aeyW ipv_sfxT t_aev4 t_aev5, > TYPE ipv_sfxT, > (SPP > @ ('PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)) > @ ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI) > @~ <'PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)>_N > ((STuple2 > @ Nat > @ Nat > @ '(n0_aeyH, n1_aeyI) > @ n0_aeyH > @ n1_aeyI > @~ <'(n0_aeyH, n1_aeyI)>_N > sc_sg53 > sc_sg54) > `cast` (sg_sg55 > :: R:Sing(,)z '(n0_aeyH, n1_aeyI) > ~R# Sing (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI)))) > `cast` (sg_sg56 > :: R:SingPrimePowerz > ('PP (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI)) > ~R# Sing > (Apply PPSym0 (Apply (Apply Tuple2Sym0 n0_aeyH) > n1_aeyI))), > sc_sg57] > [TYPE Let1627437970XSym7 > n0_aeyH > n1_aeyI > n0_XeB0 > n1_XeB2 > ipv_XfzF > (Let1627437970XSym7 > n0_aeyH n1_aeyI n0_aeyV n1_aeyW ipv_sfxT t_aev4 t_aev5) > ipv_sfxT, > TYPE ipv_XfzF, > (SPP > @ ('PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)) > @ ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI) > @~ <'PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)>_N > ((STuple2 > @ Nat > @ Nat > @ '(n0_aeyH, n1_aeyI) > @ n0_aeyH > @ n1_aeyI > @~ <'(n0_aeyH, n1_aeyI)>_N > sc_sg53 > sc_sg54) > `cast` (Sub (Sym (TFCo:R:Sing(,)z[0] _N _N)) (Sym > (TFCo:R:Apply(,)kTuple2Sym1l0[0] > _N > _N > _N > _N) > ; (Apply > (Sym > (TFCo:R:Apply(->)kTuple2Sym0l0[0] > _N > _N > _N)) > _N)_N) > :: R:Sing(,)z (Tuple2Sym2 n0_aeyH n1_aeyI) > ~R# Sing (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI)))) > `cast` (Sub (Sym TFCo:R:SingPrimePowerz[0]) (Sym > (TFCo:R:ApplyPrimePower(,)PPSym0l0[0] > <(Tuple2Sym0 @@ > n0_aeyH) @@ n1_aeyI>_N)) > :: R:SingPrimePowerz (PPSym1 ((Tuple2Sym0 @@ n0_aeyH) @@ > n1_aeyI)) > ~R# Sing (Apply PPSym0 ((Tuple2Sym0 @@ n0_aeyH) @@ > n1_aeyI))), > ipv_sfxW] > }}} New description: The only ticket I see with this issues that *isn't* resolved in 7.10.2 is #10689. Might be a dup. Compiling with -O1 succeeds, but `ghc -O2` fails: {{{ {-# LANGUAGE DataKinds, GADTs, PolyKinds, ScopedTypeVariables, TemplateHaskell, TypeFamilies, UndecidableInstances #-} module Bug where -- needed to use Nat's Num instance for + import qualified GHC.Num as Num import Data.Singletons.Prelude import Data.Singletons.TH import Data.Type.Natural import Data.Typeable -- | Copied from Data.Type.Natural because the data-level version -- is not exported there. (<<=) :: Nat -> Nat -> Bool Z <<= _ = True S _ <<= Z = False S n <<= S m = n <<= m singletons [d| newtype PrimePower = PP (Nat,Nat) deriving (Eq,Show,Typeable) |] singletons [d| ppMul :: PrimePower -> [PrimePower] -> [PrimePower] ppMul x [] = [x] ppMul x@(PP(p,e)) pps@(PP (p',e'):pps') | p == p' = PP(p,e Num.+ e'):pps' | p <<= p' = x:pps | otherwise = (PP(p',e')):ppMul x pps' |] }}} {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Template variable unbound in rewrite rule t_XexU [t_aev4, t_aev5, n0_aeyH, n1_aeyI, n0_aeyV, n1_aeyW, ipv_sfxT, sc_sg53, sc_sg54, sg_sg55, sg_sg56, sc_sg57] [t_XexU, t_XexW, n0_XeBz, n1_XeBB, n0_XeBP, n1_XeBR, ipv_XfAP, sc_Xg80, sc_Xg82, sg_Xg84, sg_Xg86, sc_Xg88] [TYPE Let1627437970XSym7 n0_aeyH n1_aeyI n0_aeyV n1_aeyW ipv_sfxT t_aev4 t_aev5, TYPE ipv_sfxT, (SPP @ ('PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)) @ ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI) @~ <'PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)>_N ((STuple2 @ Nat @ Nat @ '(n0_aeyH, n1_aeyI) @ n0_aeyH @ n1_aeyI @~ <'(n0_aeyH, n1_aeyI)>_N sc_sg53 sc_sg54) `cast` (sg_sg55 :: R:Sing(,)z '(n0_aeyH, n1_aeyI) ~R# Sing (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI)))) `cast` (sg_sg56 :: R:SingPrimePowerz ('PP (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI)) ~R# Sing (Apply PPSym0 (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI))), sc_sg57] [TYPE Let1627437970XSym7 n0_aeyH n1_aeyI n0_XeB0 n1_XeB2 ipv_XfzF (Let1627437970XSym7 n0_aeyH n1_aeyI n0_aeyV n1_aeyW ipv_sfxT t_aev4 t_aev5) ipv_sfxT, TYPE ipv_XfzF, (SPP @ ('PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)) @ ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI) @~ <'PP ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)>_N ((STuple2 @ Nat @ Nat @ '(n0_aeyH, n1_aeyI) @ n0_aeyH @ n1_aeyI @~ <'(n0_aeyH, n1_aeyI)>_N sc_sg53 sc_sg54) `cast` (Sub (Sym (TFCo:R:Sing(,)z[0] _N _N)) (Sym (TFCo:R:Apply(,)kTuple2Sym1l0[0] _N _N _N _N) ; (Apply (Sym (TFCo:R:Apply(->)kTuple2Sym0l0[0] _N _N _N)) _N)_N) :: R:Sing(,)z (Tuple2Sym2 n0_aeyH n1_aeyI) ~R# Sing (Apply (Apply Tuple2Sym0 n0_aeyH) n1_aeyI)))) `cast` (Sub (Sym TFCo:R:SingPrimePowerz[0]) (Sym (TFCo:R:ApplyPrimePower(,)PPSym0l0[0] <(Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI>_N)) :: R:SingPrimePowerz (PPSym1 ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI)) ~R# Sing (Apply PPSym0 ((Tuple2Sym0 @@ n0_aeyH) @@ n1_aeyI))), ipv_sfxW] }}} I'd love a workaround if possible; I've been unable to find one. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 1 21:50:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Oct 2015 21:50:51 -0000 Subject: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern checking In-Reply-To: <047.bea78f01cbb904765ad77c751bc8d3af@haskell.org> References: <047.bea78f01cbb904765ad77c751bc8d3af@haskell.org> Message-ID: <062.538dd9880a45746a115dced260eb055b@haskell.org> #595: Overhaul GHC's overlapping/non-exhaustive pattern checking -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by cheecheeo): * cc: cheecheeo@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 1 23:00:37 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Oct 2015 23:00:37 -0000 Subject: [GHC] #10912: Support for out of the box static linking In-Reply-To: <045.dd87a2c5256e85911413677e3011cd99@haskell.org> References: <045.dd87a2c5256e85911413677e3011cd99@haskell.org> Message-ID: <060.d8a83b77837563629bd31d8d5c21db36@haskell.org> #10912: Support for out of the box static linking -------------------------------------+------------------------------------- Reporter: crb002 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by crb002): http://downloads.haskell.org/~ghc/7.10.2/ghc-7.10.2-x86_64-unknown-linux- centos66.tar.bz2 needs to include the static versions of libffi, libgmp, and other standard libraries that GHC links to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 06:23:20 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 06:23:20 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.34e066bd9910f874368081ab7ed56d5c@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: hvr Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1284 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"03b380428c128b12aef07a9b67341803ef0bea76/ghc" 03b38042/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="03b380428c128b12aef07a9b67341803ef0bea76" Add Data.Semigroup and Data.List.NonEmpty (re #10365) This implements phase 1 of the semigroup-as-monoid-superclass proposal (https://ghc.haskell.org/wiki/Proposal/SemigroupMonoid). The modules were migrated from the `semigroups-0.17` release mostly as-is, except for dropping several trivial `{-# INLINE #-}`s, removing CPP usage, and instances for types & classes provided outside of `base` (e.g. `containers`, `deepseq`, `hashable`, `tagged`, `bytestring`, `text`) Differential Revision: https://phabricator.haskell.org/D1284 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 06:29:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 06:29:02 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.ee55f79bd4bbf1d84d7a1ed5d5dd44a9@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1284 -------------------------------------+------------------------------------- Changes (by hvr): * owner: hvr => quchen Comment: For the record, David is working on the warning-feature -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 10:18:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 10:18:17 -0000 Subject: [GHC] #8582: Record syntax for pattern synonyms In-Reply-To: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> References: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> Message-ID: <060.4849fa9deeafce45ece30e86d1a1d3f4@haskell.org> #8582: Record syntax for pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1152 -------------------------------------+------------------------------------- Comment (by simonpj): Matthew, I feel bad about this but I still don't understand the ''specification''. I honestly don't know what it means to say "a pattern synonym should behave like the relevant data constructor". The [wiki:PatternSynonyms#Design wiki page] does not even give a syntax. I think it may be something like this {{{ patsyndecl ::= 'pattern' con var1 .. varn <- pat | 'pattern' con '{' var1 ',' ... ',' varn '}' <- pat | ... more for bidirectional ... }}} where the second line is the new bit. Is that right? Just writing out the syntax would be very helpful. We need semantics as well as syntax. In comment:11 I tried to give some concrete pointers for what a specification might look like. It has to say * What the syntax is * What it means to use such a pattern synonym as a constructor * What it means to match against such a synonym I don't think any of this is very hard to do. But until it is done I don't know what the feature is, so it's hard to review the implementation. On the implementation front, I believe that you are stuck on a particular point. There's a long comment stream on the Phab ticket so I'm not sure what you are stuck on. Can you just identify the sticking point? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 10:29:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 10:29:51 -0000 Subject: [GHC] #7253: Top-level bindings in ghci In-Reply-To: <048.88d72a7323b37dac89e81e376b48b907@haskell.org> References: <048.88d72a7323b37dac89e81e376b48b907@haskell.org> Message-ID: <063.4554e1c3f0d9bbb189e7334380ae3865@haskell.org> #7253: Top-level bindings in ghci -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: roshats Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1299 -------------------------------------+------------------------------------- Changes (by roshats): * owner: => roshats * differential: => Phab:D1299 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 11:37:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 11:37:59 -0000 Subject: [GHC] #8582: Record syntax for pattern synonyms In-Reply-To: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> References: <045.711f298e5aa28ce184df85985d614bd2@haskell.org> Message-ID: <060.501f2c7c3a3177ebc1a1ea05bc6bf174@haskell.org> #8582: Record syntax for pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: mpickering Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1152 -------------------------------------+------------------------------------- Comment (by mpickering): Simon, I didn't want to write an explicit specification for this patch because it would amount to copying the specification for records. Which bit did you find confusing in the example I gave? In retrospect, the phrase "relevant data constructor" is confusing. So to explain, by "relevant" I mean an isomorphic (normally defined) data constructor. Does the example not make this any clearer? The problem with the implementation is with the record updates. Pattern synonym builders have required constraints which normal data constructors don't have. When the record update is desugared, it is necessary to provide the dictionaries for these constraints to the builder. My question was, how was I meant to do this. I ended up adding a field to the RecordUpd constructor which carried around the HsWrapper which then applied the dictionaries. More details are to be found in the last comment on the phab ticket. I don't have much time anymore to work on this ticket but I would be very disappointed it if did make it into GHC 8.0 as I started working on it several months ago. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 12:00:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 12:00:23 -0000 Subject: [GHC] #10925: GHC should inform where unknown identifiers originate whenever possible Message-ID: <050.67e8a010e570fd4083eac05305ab41d5@haskell.org> #10925: GHC should inform where unknown identifiers originate whenever possible -------------------------------------+------------------------------------- Reporter: hanshoglund | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: imports, | Operating System: Unknown/Multiple error messages | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- Assume I have a module Foo, using implicit imports and unqualified identifiers (minimalistic example, actual cases could have hundreds of imported modules). {{{ module Foo import Data.List foo = intersperse ... }}} If I decide to switch to explicit imports, I have two options. I could import Data.List as qualified, or add an explicit export list. In both cases the origin of 'intersperse' will be unambiguous. If I choose qualified imports, GHC will helpfully tell me where all now unqualified identifiers originated. {{{ Not in scope: type constructor or class ?intersperse? Perhaps you meant one of these: ?Data.List.intersperse? }}} However, If I chose to add an explicit import list to the 'Data.List' import, I will have no such help. Again, if the number of imported modules is long, there is no obvious way to tell which module should have the explicit import by just looking at the code. On the other hand, as the above case shows GHC is obviously able to infer this. I can accomplish it by manually duplicating my import list, and adding a qualified import of every imported module, but this is a lot of manual work in modules with many imports. I suggest that for the purposes of error messages, top-level identifiers not in scope should be searched for in every module as if it had been imported qualified, and an error message akin to the following should be generated. Obviously, if the identifier is availble from a a qualified import, the above error message should take precedence. {{{ Not in scope: type constructor or class ?intersperse?. It is available but not imported from the following modules: ?Data.List.intersperse? To bring the identifier into scope, import it from the one of the above modules, or use a qualified import. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 12:10:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 12:10:46 -0000 Subject: [GHC] #10926: wrong signature of atomic builtins Message-ID: <045.bcea973b69c7d9792e6dc5ce0503d185@haskell.org> #10926: wrong signature of atomic builtins --------------------------------+---------------------------------------- Reporter: schwab | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: aarch64 | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | --------------------------------+---------------------------------------- {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -optc-fno-builtin -this-package-key ghcpr_8TmvWUcS1U1IKHT0levwg3 -hide- all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist- install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries /ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist- install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package-key rts -this-package-key ghc-prim -XHaskell2010 -O -no-user- package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim /dist-install/build -dynamic-too -c libraries/ghc-prim/dist- install/build/GHC/PrimopWrappers.hs -o libraries/ghc-prim/dist- install/build/GHC/PrimopWrappers.o -dyno libraries/ghc-prim/dist- install/build/GHC/PrimopWrappers.dyn_o /tmp/ghc1492_0/ghc_1.hc: In function 'ghczmprim_GHCziPrimopWrappers_fetchXorIntArrayzh_entry': /tmp/ghc1492_0/ghc_1.hc:2844:25: warning: passing argument 1 of 'hs_atomic_xor64' makes pointer from integer without a cast [-Wint-conversion] _c1Ho = hs_atomic_xor64((*Sp) + (((Sp[1]) << 0x3UL) + 0x10UL), Sp[2]); ^ In file included from /home/abuild/rpmbuild/BUILD/ghc-7.10.2/includes/Stg.h:273:0: 0, from /tmp/ghc1492_0/ghc_1.hc:3: /home/abuild/rpmbuild/BUILD/ghc-7.10.2/includes/stg/Prim.h:41:11: note: expected 'volatile StgWord64 * {aka volatile long unsigned int *}' but argument is of type 'long unsigned int' StgWord64 hs_atomic_xor64(volatile StgWord64 *x, StgWord64 val); ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 12:13:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 12:13:35 -0000 Subject: [GHC] #10927: IndexError: pop from empty list Message-ID: <045.caca6922033a1cb1a5f73e4552615a1e@haskell.org> #10927: IndexError: pop from empty list -------------------------------------+------------------------------------- Reporter: schwab | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- ==== Zum Reproduzieren ==== W?hrend der Ausf?hrung von GET auf `/attachment/ticket/10926/` hat Trac einen internen Fehler gemeldet. ''(Bitte geben Sie hier weitere Details an)'' Anfrageparameter: {{{ {u'action': u'new', 'path': u'10926/', 'realm': u'ticket'} }}} User agent: `Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.21 (KHTML, like Gecko) konqueror/4.14.9 Safari/537.21` ==== Systeminformationen ==== ''Systeminformation nicht verf?gbar'' ==== Aktive Plugins ==== ''Plugininformation nicht verf?gbar'' ==== Python-Zur?ckverfolgungsinformationen ==== {{{ Traceback (most recent call last): File "/usr/local/lib/python2.7/dist- packages/Trac-1.0.9-py2.7.egg/trac/web/main.py", line 554, in _dispatch_request dispatcher.dispatch(req) File "/usr/local/lib/python2.7/dist- packages/Trac-1.0.9-py2.7.egg/trac/web/main.py", line 267, in dispatch iterable=chrome.use_chunked_encoding) File "/usr/local/lib/python2.7/dist- packages/Trac-1.0.9-py2.7.egg/trac/web/chrome.py", line 1111, in render_template encoding='utf-8') File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 184, in render return encode(generator, method=method, encoding=encoding, out=out) File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 58, in encode for chunk in iterator: File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 350, in __call__ for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 829, in __call__ for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 669, in __call__ for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 774, in __call__ for kind, data, pos in chain(stream, [(None, None, None)]): File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 594, in __call__ for ev in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist- packages/Trac-1.0.9-py2.7.egg/trac/web/chrome.py", line 1309, in _strip_accesskeys for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist- packages/Trac-1.0.9-py2.7.egg/trac/web/chrome.py", line 1298, in _generate for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 706, in _unmark for mark, event in stream: File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 1101, in __call__ for mark, event in stream: File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 118, in __iter__ event = self.stream.next() File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 734, in __call__ for mark, event in stream: File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 702, in _mark for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 378, in _match ctxt, start=idx + 1, **vars): File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 378, in _match ctxt, start=idx + 1, **vars): File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 362, in _match content = list(content) File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 326, in _match for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 315, in _strip event = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 558, in _flatten for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/path.py", line 588, in _generate subevent = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 315, in _strip event = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 558, in _flatten for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/path.py", line 588, in _generate subevent = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 315, in _strip event = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 558, in _flatten for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/filters/i18n.py", line 178, in _generate for event in msgbuf.translate(gettext(msgbuf.format())): File "/usr/local/lib/python2.7/dist-packages/genshi/filters/i18n.py", line 1051, in translate events = self.events[order].pop(0) IndexError: pop from empty list }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 12:21:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 12:21:12 -0000 Subject: [GHC] #10926: wrong signature of atomic builtins In-Reply-To: <045.bcea973b69c7d9792e6dc5ce0503d185@haskell.org> References: <045.bcea973b69c7d9792e6dc5ce0503d185@haskell.org> Message-ID: <060.f312d4b2c4c034bc9bca524487d7eb51@haskell.org> #10926: wrong signature of atomic builtins ----------------------------------------+------------------------------- Reporter: schwab | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ----------------------------------------+------------------------------- Comment (by schwab): {{{ From 970d13089f08bfd9a967524b8ab58ab1a1bed7a8 Mon Sep 17 00:00:00 2001 From: Andreas Schwab Date: Fri, 2 Oct 2015 14:11:49 +0200 Subject: [PATCH] Fix signature of atomic builtins --- includes/stg/Prim.h | 72 ++++++------ libraries/ghc-prim/cbits/atomic.c | 224 +++++++++++++++++++------------------- 2 files changed, 148 insertions(+), 148 deletions(-) diff --git a/includes/stg/Prim.h b/includes/stg/Prim.h index b07e177..9872512 100644 --- a/includes/stg/Prim.h +++ b/includes/stg/Prim.h @@ -15,42 +15,42 @@ #define PRIM_H /* libraries/ghc-prim/cbits/atomic.c */ -StgWord hs_atomic_add8(volatile StgWord8 *x, StgWord val); -StgWord hs_atomic_add16(volatile StgWord16 *x, StgWord val); -StgWord hs_atomic_add32(volatile StgWord32 *x, StgWord val); -StgWord64 hs_atomic_add64(volatile StgWord64 *x, StgWord64 val); -StgWord hs_atomic_sub8(volatile StgWord8 *x, StgWord val); -StgWord hs_atomic_sub16(volatile StgWord16 *x, StgWord val); -StgWord hs_atomic_sub32(volatile StgWord32 *x, StgWord val); -StgWord64 hs_atomic_sub64(volatile StgWord64 *x, StgWord64 val); -StgWord hs_atomic_and8(volatile StgWord8 *x, StgWord val); -StgWord hs_atomic_and16(volatile StgWord16 *x, StgWord val); -StgWord hs_atomic_and32(volatile StgWord32 *x, StgWord val); -StgWord64 hs_atomic_and64(volatile StgWord64 *x, StgWord64 val); -StgWord hs_atomic_nand8(volatile StgWord8 *x, StgWord val); -StgWord hs_atomic_nand16(volatile StgWord16 *x, StgWord val); -StgWord hs_atomic_nand32(volatile StgWord32 *x, StgWord val); -StgWord64 hs_atomic_nand64(volatile StgWord64 *x, StgWord64 val); -StgWord hs_atomic_or8(volatile StgWord8 *x, StgWord val); -StgWord hs_atomic_or16(volatile StgWord16 *x, StgWord val); -StgWord hs_atomic_or32(volatile StgWord32 *x, StgWord val); -StgWord64 hs_atomic_or64(volatile StgWord64 *x, StgWord64 val); -StgWord hs_atomic_xor8(volatile StgWord8 *x, StgWord val); -StgWord hs_atomic_xor16(volatile StgWord16 *x, StgWord val); -StgWord hs_atomic_xor32(volatile StgWord32 *x, StgWord val); -StgWord64 hs_atomic_xor64(volatile StgWord64 *x, StgWord64 val); -StgWord hs_cmpxchg8(volatile StgWord8 *x, StgWord old, StgWord new_); -StgWord hs_cmpxchg16(volatile StgWord16 *x, StgWord old, StgWord new_); -StgWord hs_cmpxchg32(volatile StgWord32 *x, StgWord old, StgWord new_); -StgWord hs_cmpxchg64(volatile StgWord64 *x, StgWord64 old, StgWord64 new_); -StgWord hs_atomicread8(volatile StgWord8 *x); -StgWord hs_atomicread16(volatile StgWord16 *x); -StgWord hs_atomicread32(volatile StgWord32 *x); -StgWord64 hs_atomicread64(volatile StgWord64 *x); -void hs_atomicwrite8(volatile StgWord8 *x, StgWord val); -void hs_atomicwrite16(volatile StgWord16 *x, StgWord val); -void hs_atomicwrite32(volatile StgWord32 *x, StgWord val); -void hs_atomicwrite64(volatile StgWord64 *x, StgWord64 val); +StgWord hs_atomic_add8(StgWord x, StgWord val); +StgWord hs_atomic_add16(StgWord x, StgWord val); +StgWord hs_atomic_add32(StgWord x, StgWord val); +StgWord64 hs_atomic_add64(StgWord x, StgWord64 val); +StgWord hs_atomic_sub8(StgWord x, StgWord val); +StgWord hs_atomic_sub16(StgWord x, StgWord val); +StgWord hs_atomic_sub32(StgWord x, StgWord val); +StgWord64 hs_atomic_sub64(StgWord x, StgWord64 val); +StgWord hs_atomic_and8(StgWord x, StgWord val); +StgWord hs_atomic_and16(StgWord x, StgWord val); +StgWord hs_atomic_and32(StgWord x, StgWord val); +StgWord64 hs_atomic_and64(StgWord x, StgWord64 val); +StgWord hs_atomic_nand8(StgWord x, StgWord val); +StgWord hs_atomic_nand16(StgWord x, StgWord val); +StgWord hs_atomic_nand32(StgWord x, StgWord val); +StgWord64 hs_atomic_nand64(StgWord x, StgWord64 val); +StgWord hs_atomic_or8(StgWord x, StgWord val); +StgWord hs_atomic_or16(StgWord x, StgWord val); +StgWord hs_atomic_or32(StgWord x, StgWord val); +StgWord64 hs_atomic_or64(StgWord x, StgWord64 val); +StgWord hs_atomic_xor8(StgWord x, StgWord val); +StgWord hs_atomic_xor16(StgWord x, StgWord val); +StgWord hs_atomic_xor32(StgWord x, StgWord val); +StgWord64 hs_atomic_xor64(StgWord x, StgWord64 val); +StgWord hs_cmpxchg8(StgWord x, StgWord old, StgWord new_); +StgWord hs_cmpxchg16(StgWord x, StgWord old, StgWord new_); +StgWord hs_cmpxchg32(StgWord x, StgWord old, StgWord new_); +StgWord hs_cmpxchg64(StgWord x, StgWord64 old, StgWord64 new_); +StgWord hs_atomicread8(StgWord x); +StgWord hs_atomicread16(StgWord x); +StgWord hs_atomicread32(StgWord x); +StgWord64 hs_atomicread64(StgWord x); +void hs_atomicwrite8(StgWord x, StgWord val); +void hs_atomicwrite16(StgWord x, StgWord val); +void hs_atomicwrite32(StgWord x, StgWord val); +void hs_atomicwrite64(StgWord x, StgWord64 val); /* libraries/ghc-prim/cbits/bswap.c */ StgWord16 hs_bswap16(StgWord16 x); diff --git a/libraries/ghc-prim/cbits/atomic.c b/libraries/ghc- prim/cbits/atomic.c index 01cc458..2ecbf34 100644 --- a/libraries/ghc-prim/cbits/atomic.c +++ b/libraries/ghc-prim/cbits/atomic.c @@ -11,97 +11,97 @@ // FetchAddByteArrayOp_Int -extern StgWord hs_atomic_add8(volatile StgWord8 *x, StgWord val); +extern StgWord hs_atomic_add8(StgWord x, StgWord val); StgWord -hs_atomic_add8(volatile StgWord8 *x, StgWord val) +hs_atomic_add8(StgWord x, StgWord val) { - return __sync_fetch_and_add(x, (StgWord8) val); + return __sync_fetch_and_add((volatile StgWord8 *) x, (StgWord8) val); } -extern StgWord hs_atomic_add16(volatile StgWord16 *x, StgWord val); +extern StgWord hs_atomic_add16(StgWord x, StgWord val); StgWord -hs_atomic_add16(volatile StgWord16 *x, StgWord val) +hs_atomic_add16(StgWord x, StgWord val) { - return __sync_fetch_and_add(x, (StgWord16) val); + return __sync_fetch_and_add((volatile StgWord16 *) x, (StgWord16) val); } -extern StgWord hs_atomic_add32(volatile StgWord32 *x, StgWord val); +extern StgWord hs_atomic_add32(StgWord x, StgWord val); StgWord -hs_atomic_add32(volatile StgWord32 *x, StgWord val) +hs_atomic_add32(StgWord x, StgWord val) { - return __sync_fetch_and_add(x, (StgWord32) val); + return __sync_fetch_and_add((volatile StgWord32 *) x, (StgWord32) val); } #if WORD_SIZE_IN_BITS == 64 -extern StgWord64 hs_atomic_add64(volatile StgWord64 *x, StgWord64 val); +extern StgWord64 hs_atomic_add64(StgWord x, StgWord64 val); StgWord64 -hs_atomic_add64(volatile StgWord64 *x, StgWord64 val) +hs_atomic_add64(StgWord x, StgWord64 val) { - return __sync_fetch_and_add(x, val); + return __sync_fetch_and_add((volatile StgWord64 *) x, val); } #endif // FetchSubByteArrayOp_Int -extern StgWord hs_atomic_sub8(volatile StgWord8 *x, StgWord val); +extern StgWord hs_atomic_sub8(StgWord x, StgWord val); StgWord -hs_atomic_sub8(volatile StgWord8 *x, StgWord val) +hs_atomic_sub8(StgWord x, StgWord val) { - return __sync_fetch_and_sub(x, (StgWord8) val); + return __sync_fetch_and_sub((volatile StgWord8 *) x, (StgWord8) val); } -extern StgWord hs_atomic_sub16(volatile StgWord16 *x, StgWord val); +extern StgWord hs_atomic_sub16(StgWord x, StgWord val); StgWord -hs_atomic_sub16(volatile StgWord16 *x, StgWord val) +hs_atomic_sub16(StgWord x, StgWord val) { - return __sync_fetch_and_sub(x, (StgWord16) val); + return __sync_fetch_and_sub((volatile StgWord16 *) x, (StgWord16) val); } -extern StgWord hs_atomic_sub32(volatile StgWord32 *x, StgWord val); +extern StgWord hs_atomic_sub32(StgWord x, StgWord val); StgWord -hs_atomic_sub32(volatile StgWord32 *x, StgWord val) +hs_atomic_sub32(StgWord x, StgWord val) { - return __sync_fetch_and_sub(x, (StgWord32) val); + return __sync_fetch_and_sub((volatile StgWord32 *) x, (StgWord32) val); } #if WORD_SIZE_IN_BITS == 64 -extern StgWord64 hs_atomic_sub64(volatile StgWord64 *x, StgWord64 val); +extern StgWord64 hs_atomic_sub64(StgWord x, StgWord64 val); StgWord64 -hs_atomic_sub64(volatile StgWord64 *x, StgWord64 val) +hs_atomic_sub64(StgWord x, StgWord64 val) { - return __sync_fetch_and_sub(x, val); + return __sync_fetch_and_sub((volatile StgWord64 *) x, val); } #endif // FetchAndByteArrayOp_Int -extern StgWord hs_atomic_and8(volatile StgWord8 *x, StgWord val); +extern StgWord hs_atomic_and8(StgWord x, StgWord val); StgWord -hs_atomic_and8(volatile StgWord8 *x, StgWord val) +hs_atomic_and8(StgWord x, StgWord val) { - return __sync_fetch_and_and(x, (StgWord8) val); + return __sync_fetch_and_and((volatile StgWord8 *) x, (StgWord8) val); } -extern StgWord hs_atomic_and16(volatile StgWord16 *x, StgWord val); +extern StgWord hs_atomic_and16(StgWord x, StgWord val); StgWord -hs_atomic_and16(volatile StgWord16 *x, StgWord val) +hs_atomic_and16(StgWord x, StgWord val) { - return __sync_fetch_and_and(x, (StgWord16) val); + return __sync_fetch_and_and((volatile StgWord16 *) x, (StgWord16) val); } -extern StgWord hs_atomic_and32(volatile StgWord32 *x, StgWord val); +extern StgWord hs_atomic_and32(StgWord x, StgWord val); StgWord -hs_atomic_and32(volatile StgWord32 *x, StgWord val) +hs_atomic_and32(StgWord x, StgWord val) { - return __sync_fetch_and_and(x, (StgWord32) val); + return __sync_fetch_and_and((volatile StgWord32 *) x, (StgWord32) val); } #if WORD_SIZE_IN_BITS == 64 -extern StgWord64 hs_atomic_and64(volatile StgWord64 *x, StgWord64 val); +extern StgWord64 hs_atomic_and64(StgWord x, StgWord64 val); StgWord64 -hs_atomic_and64(volatile StgWord64 *x, StgWord64 val) +hs_atomic_and64(StgWord x, StgWord64 val) { - return __sync_fetch_and_and(x, val); + return __sync_fetch_and_and((volatile StgWord64 *) x, val); } #endif @@ -117,204 +117,204 @@ hs_atomic_and64(volatile StgWord64 *x, StgWord64 val) return tmp; \ } -extern StgWord hs_atomic_nand8(volatile StgWord8 *x, StgWord val); +extern StgWord hs_atomic_nand8(StgWord x, StgWord val); StgWord -hs_atomic_nand8(volatile StgWord8 *x, StgWord val) +hs_atomic_nand8(StgWord x, StgWord val) { #ifdef __clang__ - CAS_NAND(x, (StgWord8) val) + CAS_NAND((volatile StgWord8 *) x, (StgWord8) val) #else - return __sync_fetch_and_nand(x, (StgWord8) val); + return __sync_fetch_and_nand((volatile StgWord8 *) x, (StgWord8) val); #endif } -extern StgWord hs_atomic_nand16(volatile StgWord16 *x, StgWord val); +extern StgWord hs_atomic_nand16(StgWord x, StgWord val); StgWord -hs_atomic_nand16(volatile StgWord16 *x, StgWord val) +hs_atomic_nand16(StgWord x, StgWord val) { #ifdef __clang__ - CAS_NAND(x, (StgWord16) val); + CAS_NAND((volatile StgWord16 *) x, (StgWord16) val); #else - return __sync_fetch_and_nand(x, (StgWord16) val); + return __sync_fetch_and_nand((volatile StgWord16 *) x, (StgWord16) val); #endif } -extern StgWord hs_atomic_nand32(volatile StgWord32 *x, StgWord val); +extern StgWord hs_atomic_nand32(StgWord x, StgWord val); StgWord -hs_atomic_nand32(volatile StgWord32 *x, StgWord val) +hs_atomic_nand32(StgWord x, StgWord val) { #ifdef __clang__ - CAS_NAND(x, (StgWord32) val); + CAS_NAND((volatile StgWord32 *) x, (StgWord32) val); #else - return __sync_fetch_and_nand(x, (StgWord32) val); + return __sync_fetch_and_nand((volatile StgWord32 *) x, (StgWord32) val); #endif } #if WORD_SIZE_IN_BITS == 64 -extern StgWord64 hs_atomic_nand64(volatile StgWord64 *x, StgWord64 val); +extern StgWord64 hs_atomic_nand64(StgWord x, StgWord64 val); StgWord64 -hs_atomic_nand64(volatile StgWord64 *x, StgWord64 val) +hs_atomic_nand64(StgWord x, StgWord64 val) { #ifdef __clang__ - CAS_NAND(x, val); + CAS_NAND((volatile StgWord64 *) x, val); #else - return __sync_fetch_and_nand(x, val); + return __sync_fetch_and_nand((volatile StgWord64 *) x, val); #endif } #endif // FetchOrByteArrayOp_Int -extern StgWord hs_atomic_or8(volatile StgWord8 *x, StgWord val); +extern StgWord hs_atomic_or8(StgWord x, StgWord val); StgWord -hs_atomic_or8(volatile StgWord8 *x, StgWord val) +hs_atomic_or8(StgWord x, StgWord val) { - return __sync_fetch_and_or(x, (StgWord8) val); + return __sync_fetch_and_or((volatile StgWord8 *) x, (StgWord8) val); } -extern StgWord hs_atomic_or16(volatile StgWord16 *x, StgWord val); +extern StgWord hs_atomic_or16(StgWord x, StgWord val); StgWord -hs_atomic_or16(volatile StgWord16 *x, StgWord val) +hs_atomic_or16(StgWord x, StgWord val) { - return __sync_fetch_and_or(x, (StgWord16) val); + return __sync_fetch_and_or((volatile StgWord16 *) x, (StgWord16) val); } -extern StgWord hs_atomic_or32(volatile StgWord32 *x, StgWord val); +extern StgWord hs_atomic_or32(StgWord x, StgWord val); StgWord -hs_atomic_or32(volatile StgWord32 *x, StgWord val) +hs_atomic_or32(StgWord x, StgWord val) { - return __sync_fetch_and_or(x, (StgWord32) val); + return __sync_fetch_and_or((volatile StgWord32 *) x, (StgWord32) val); } #if WORD_SIZE_IN_BITS == 64 -extern StgWord64 hs_atomic_or64(volatile StgWord64 *x, StgWord64 val); +extern StgWord64 hs_atomic_or64(StgWord x, StgWord64 val); StgWord64 -hs_atomic_or64(volatile StgWord64 *x, StgWord64 val) +hs_atomic_or64(StgWord x, StgWord64 val) { - return __sync_fetch_and_or(x, val); + return __sync_fetch_and_or((volatile StgWord64 *) x, val); } #endif // FetchXorByteArrayOp_Int -extern StgWord hs_atomic_xor8(volatile StgWord8 *x, StgWord val); +extern StgWord hs_atomic_xor8(StgWord x, StgWord val); StgWord -hs_atomic_xor8(volatile StgWord8 *x, StgWord val) +hs_atomic_xor8(StgWord x, StgWord val) { - return __sync_fetch_and_xor(x, (StgWord8) val); + return __sync_fetch_and_xor((volatile StgWord8 *) x, (StgWord8) val); } -extern StgWord hs_atomic_xor16(volatile StgWord16 *x, StgWord val); +extern StgWord hs_atomic_xor16(StgWord x, StgWord val); StgWord -hs_atomic_xor16(volatile StgWord16 *x, StgWord val) +hs_atomic_xor16(StgWord x, StgWord val) { - return __sync_fetch_and_xor(x, (StgWord16) val); + return __sync_fetch_and_xor((volatile StgWord16 *) x, (StgWord16) val); } -extern StgWord hs_atomic_xor32(volatile StgWord32 *x, StgWord val); +extern StgWord hs_atomic_xor32(StgWord x, StgWord val); StgWord -hs_atomic_xor32(volatile StgWord32 *x, StgWord val) +hs_atomic_xor32(StgWord x, StgWord val) { - return __sync_fetch_and_xor(x, (StgWord32) val); + return __sync_fetch_and_xor((volatile StgWord32 *) x, (StgWord32) val); } #if WORD_SIZE_IN_BITS == 64 -extern StgWord64 hs_atomic_xor64(volatile StgWord64 *x, StgWord64 val); +extern StgWord64 hs_atomic_xor64(StgWord x, StgWord64 val); StgWord64 -hs_atomic_xor64(volatile StgWord64 *x, StgWord64 val) +hs_atomic_xor64(StgWord x, StgWord64 val) { - return __sync_fetch_and_xor(x, val); + return __sync_fetch_and_xor((volatile StgWord64 *) x, val); } #endif // CasByteArrayOp_Int -extern StgWord hs_cmpxchg8(volatile StgWord8 *x, StgWord old, StgWord new); +extern StgWord hs_cmpxchg8(StgWord x, StgWord old, StgWord new); StgWord -hs_cmpxchg8(volatile StgWord8 *x, StgWord old, StgWord new) +hs_cmpxchg8(StgWord x, StgWord old, StgWord new) { - return __sync_val_compare_and_swap(x, (StgWord8) old, (StgWord8) new); + return __sync_val_compare_and_swap((volatile StgWord8 *) x, (StgWord8) old, (StgWord8) new); } -extern StgWord hs_cmpxchg16(volatile StgWord16 *x, StgWord old, StgWord new); +extern StgWord hs_cmpxchg16(StgWord x, StgWord old, StgWord new); StgWord -hs_cmpxchg16(volatile StgWord16 *x, StgWord old, StgWord new) +hs_cmpxchg16(StgWord x, StgWord old, StgWord new) { - return __sync_val_compare_and_swap(x, (StgWord16) old, (StgWord16) new); + return __sync_val_compare_and_swap((volatile StgWord16 *) x, (StgWord16) old, (StgWord16) new); } -extern StgWord hs_cmpxchg32(volatile StgWord32 *x, StgWord old, StgWord new); +extern StgWord hs_cmpxchg32(StgWord x, StgWord old, StgWord new); StgWord -hs_cmpxchg32(volatile StgWord32 *x, StgWord old, StgWord new) +hs_cmpxchg32(StgWord x, StgWord old, StgWord new) { - return __sync_val_compare_and_swap(x, (StgWord32) old, (StgWord32) new); + return __sync_val_compare_and_swap((volatile StgWord32 *) x, (StgWord32) old, (StgWord32) new); } #if WORD_SIZE_IN_BITS == 64 -extern StgWord hs_cmpxchg64(volatile StgWord64 *x, StgWord64 old, StgWord64 new); +extern StgWord hs_cmpxchg64(StgWord x, StgWord64 old, StgWord64 new); StgWord -hs_cmpxchg64(volatile StgWord64 *x, StgWord64 old, StgWord64 new) +hs_cmpxchg64(StgWord x, StgWord64 old, StgWord64 new) { - return __sync_val_compare_and_swap(x, old, new); + return __sync_val_compare_and_swap((volatile StgWord64 *) x, old, new); } #endif // AtomicReadByteArrayOp_Int -extern StgWord hs_atomicread8(volatile StgWord8 *x); +extern StgWord hs_atomicread8(StgWord x); StgWord -hs_atomicread8(volatile StgWord8 *x) +hs_atomicread8(StgWord x) { - return *x; + return *(volatile StgWord8 *) x; } -extern StgWord hs_atomicread16(volatile StgWord16 *x); +extern StgWord hs_atomicread16(StgWord x); StgWord -hs_atomicread16(volatile StgWord16 *x) +hs_atomicread16(StgWord x) { - return *x; + return *(volatile StgWord16 *) x; } -extern StgWord hs_atomicread32(volatile StgWord32 *x); +extern StgWord hs_atomicread32(StgWord x); StgWord -hs_atomicread32(volatile StgWord32 *x) +hs_atomicread32(StgWord x) { - return *x; + return *(volatile StgWord32 *) x; } -extern StgWord64 hs_atomicread64(volatile StgWord64 *x); +extern StgWord64 hs_atomicread64(StgWord x); StgWord64 -hs_atomicread64(volatile StgWord64 *x) +hs_atomicread64(StgWord x) { - return *x; + return *(volatile StgWord64 *) x; } // AtomicWriteByteArrayOp_Int -extern void hs_atomicwrite8(volatile StgWord8 *x, StgWord val); +extern void hs_atomicwrite8(StgWord x, StgWord val); void -hs_atomicwrite8(volatile StgWord8 *x, StgWord val) +hs_atomicwrite8(StgWord x, StgWord val) { - *x = (StgWord8) val; + *(volatile StgWord8 *) x = (StgWord8) val; } -extern void hs_atomicwrite16(volatile StgWord16 *x, StgWord val); +extern void hs_atomicwrite16(StgWord x, StgWord val); void -hs_atomicwrite16(volatile StgWord16 *x, StgWord val) +hs_atomicwrite16(StgWord x, StgWord val) { - *x = (StgWord16) val; + *(volatile StgWord16 *) x = (StgWord16) val; } -extern void hs_atomicwrite32(volatile StgWord32 *x, StgWord val); +extern void hs_atomicwrite32(StgWord x, StgWord val); void -hs_atomicwrite32(volatile StgWord32 *x, StgWord val) +hs_atomicwrite32(StgWord x, StgWord val) { - *x = (StgWord32) val; + *(volatile StgWord32 *) x = (StgWord32) val; } -extern void hs_atomicwrite64(volatile StgWord64 *x, StgWord64 val); +extern void hs_atomicwrite64(StgWord x, StgWord64 val); void -hs_atomicwrite64(volatile StgWord64 *x, StgWord64 val) +hs_atomicwrite64(StgWord x, StgWord64 val) { - *x = (StgWord64) val; + *(volatile StgWord64 *) x = (StgWord64) val; } -- 2.6.0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 13:20:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 13:20:10 -0000 Subject: [GHC] #10926: wrong signature of atomic builtins In-Reply-To: <045.bcea973b69c7d9792e6dc5ce0503d185@haskell.org> References: <045.bcea973b69c7d9792e6dc5ce0503d185@haskell.org> Message-ID: <060.ed91174c847dc9887c228dd83b16df75@haskell.org> #10926: wrong signature of atomic builtins ----------------------------------------+---------------------------------- Reporter: schwab | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1300 ----------------------------------------+---------------------------------- Changes (by bgamari): * cc: bgamari (added) * status: new => patch * differential: => Phab:D1300 Comment: Andreas, I've posted this patch for review on Phabricator, Phab:D1300. Let's continue the process there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 13:47:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 13:47:43 -0000 Subject: [GHC] #10392: typo in Debug.Trace.traceShowM example In-Reply-To: <048.7a8a138fe18cc1cc48d044dd03dfc1d1@haskell.org> References: <048.7a8a138fe18cc1cc48d044dd03dfc1d1@haskell.org> Message-ID: <063.d8cc47e895b2dd756f899c55b8e590f3@haskell.org> #10392: typo in Debug.Trace.traceShowM example -------------------------------------+------------------------------------- Reporter: sebastian | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.0.1 Component: Documentation | Version: 7.10.1 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): -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 14:32:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 14:32:26 -0000 Subject: [GHC] #10215: Optimizer has bugs regarding handling of -0.0 In-Reply-To: <045.bec2708cfecaad6939bf692a32bcb7aa@haskell.org> References: <045.bec2708cfecaad6939bf692a32bcb7aa@haskell.org> Message-ID: <060.4028d37d9b546d2192b41aa3cccf8d17@haskell.org> #10215: Optimizer has bugs regarding handling of -0.0 -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9238 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"eb975d2eec349429e735c272d46a7becccf393c6/ghc" eb975d2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eb975d2eec349429e735c272d46a7becccf393c6" Fix treatment of -0.0 Here we fix a few mis-optimizations that could occur in code with floating point comparisons with -0.0. These issues arose from our insistence on rewriting equalities into case analyses and the simplifier's ignorance of floating-point semantics. For instance, in Trac #10215 (and the similar issue Trac #9238) we turned `ds == 0.0` into a case analysis, ``` case ds of __DEFAULT -> ... 0.0 -> ... ``` Where the second alternative matches where `ds` is +0.0 and *also* -0.0. However, the simplifier doesn't realize this and will introduce a local inlining of `ds = -- +0.0` as it believes this is the only value that matches this pattern. Instead of teaching the simplifier about floating-point semantics we simply prohibit case analysis on floating-point scrutinees and keep this logic in the comparison primops, where it belongs. We do several things here, - Add test cases from relevant tickets - Clean up a bit of documentation - Desugar literal matches against floats into applications of the appropriate equality primitive instead of case analysis - Add a CoreLint to ensure we don't pattern match on floats in Core Test Plan: validate with included testcases Reviewers: goldfire, simonpj, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1061 GHC Trac Issues: #10215, #9238 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 14:32:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 14:32:26 -0000 Subject: [GHC] #9238: Negative zero broken In-Reply-To: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> References: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> Message-ID: <062.b35d99afd7bed439e89af7d8db4da7df@haskell.org> #9238: Negative zero broken -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7858, #9451, | Differential Rev(s): Phab:D1061 #10215 | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"eb975d2eec349429e735c272d46a7becccf393c6/ghc" eb975d2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eb975d2eec349429e735c272d46a7becccf393c6" Fix treatment of -0.0 Here we fix a few mis-optimizations that could occur in code with floating point comparisons with -0.0. These issues arose from our insistence on rewriting equalities into case analyses and the simplifier's ignorance of floating-point semantics. For instance, in Trac #10215 (and the similar issue Trac #9238) we turned `ds == 0.0` into a case analysis, ``` case ds of __DEFAULT -> ... 0.0 -> ... ``` Where the second alternative matches where `ds` is +0.0 and *also* -0.0. However, the simplifier doesn't realize this and will introduce a local inlining of `ds = -- +0.0` as it believes this is the only value that matches this pattern. Instead of teaching the simplifier about floating-point semantics we simply prohibit case analysis on floating-point scrutinees and keep this logic in the comparison primops, where it belongs. We do several things here, - Add test cases from relevant tickets - Clean up a bit of documentation - Desugar literal matches against floats into applications of the appropriate equality primitive instead of case analysis - Add a CoreLint to ensure we don't pattern match on floats in Core Test Plan: validate with included testcases Reviewers: goldfire, simonpj, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1061 GHC Trac Issues: #10215, #9238 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 14:32:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 14:32:26 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.2514172f86823e944e082cb187d34a03@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: trommler Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b29f20edb1ca7f1763ceb001e2bb2d5f2f11bec3/ghc" b29f20e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b29f20edb1ca7f1763ceb001e2bb2d5f2f11bec3" nativeGen PPC: fix > 16 bit offsets in stack handling Implement access to spill slots at offsets larger than 16 bits. Also allocation and deallocation of spill slots was restricted to 16 bit offsets. Now 32 bit offsets are supported on all PowerPC platforms. The implementation of 32 bit offsets requires more than one instruction but the native code generator wants one instruction. So we implement pseudo-instructions that are pretty printed into multiple assembly instructions. With pseudo-instructions for spill slot allocation and deallocation we can also implement handling of the back chain pointer according to the ELF ABIs. Test Plan: validate (especially on powerpc (32 bit)) Reviewers: bgamari, austin, erikd Reviewed By: erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1296 GHC Trac Issues: #7830 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 14:32:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 14:32:26 -0000 Subject: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? In-Reply-To: <045.ccd82245c78d0eab2e30b4e2bcec2782@haskell.org> References: <045.ccd82245c78d0eab2e30b4e2bcec2782@haskell.org> Message-ID: <060.0529c23b14bd14b43e3e16cffb138978@haskell.org> #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.9 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:D1282 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"bd41eb2ad9507d3f408e25c8dece61f389f11a2a/ghc" bd41eb2a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bd41eb2ad9507d3f408e25c8dece61f389f11a2a" LLVM: Implement atomic operations in terms of LLVM primitives This fixes Trac #7883. This adds proper support for, * `MO_AtomicRMW` * `MO_AtomicWrite` * `MO_CmpXChg` Test Plan: Validate Reviewers: rrnewton, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1282 GHC Trac Issues: #7883 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 14:54:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 14:54:15 -0000 Subject: [GHC] #10925: GHC should inform where unknown identifiers originate whenever possible In-Reply-To: <050.67e8a010e570fd4083eac05305ab41d5@haskell.org> References: <050.67e8a010e570fd4083eac05305ab41d5@haskell.org> Message-ID: <065.87dfc40179899b23f0a63f15c639ef8f@haskell.org> #10925: GHC should inform where unknown identifiers originate whenever possible -------------------------------------+------------------------------------- Reporter: hanshoglund | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: imports, | error messages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by simonpj): Very reasonable idea. Not hard to implement. I can advise. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 16:06:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 16:06:10 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.4c6ea2e0574fe7c5ca252748feddffa7@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: trommler Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 16:06:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 16:06:27 -0000 Subject: [GHC] #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? In-Reply-To: <045.ccd82245c78d0eab2e30b4e2bcec2782@haskell.org> References: <045.ccd82245c78d0eab2e30b4e2bcec2782@haskell.org> Message-ID: <060.158ec381ef9471cbe16e34dfaf546025@haskell.org> #7883: enable GHC LLVM backend to use LLVM provided CAS / Atomicity primitives? -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.9 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:D1282 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 16:07:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 16:07:12 -0000 Subject: [GHC] #9238: Negative zero broken In-Reply-To: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> References: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> Message-ID: <062.262586e7fa5641a18008a02dc407066b@haskell.org> #9238: Negative zero broken -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7858, #9451, | Differential Rev(s): Phab:D1061 #10215 | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge Comment: Fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 16:38:40 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 16:38:40 -0000 Subject: [GHC] #10475: detabify User's Guide In-Reply-To: <047.1e4a60602b92fd833c83e920802a19a6@haskell.org> References: <047.1e4a60602b92fd833c83e920802a19a6@haskell.org> Message-ID: <062.9ebac0c1eb5c73917bbe38ea154ee46a@haskell.org> #10475: detabify User's Guide -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: thoughtpolice Type: task | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by thomie): Fixed in Phab:D1294. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 16:38:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 16:38:51 -0000 Subject: [GHC] #10475: detabify User's Guide In-Reply-To: <047.1e4a60602b92fd833c83e920802a19a6@haskell.org> References: <047.1e4a60602b92fd833c83e920802a19a6@haskell.org> Message-ID: <062.043c36ecb108f4f6a90276a58e650949@haskell.org> #10475: detabify User's Guide -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: thoughtpolice Type: task | Status: closed Priority: low | Milestone: Component: Documentation | Version: 7.10.1 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): -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 20:17:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 20:17:08 -0000 Subject: [GHC] #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages In-Reply-To: <047.046a9f83230d0273c9346cd501403845@haskell.org> References: <047.046a9f83230d0273c9346cd501403845@haskell.org> Message-ID: <062.9f6f2bf0fb69622f82acc1f0310cd25c@haskell.org> #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: snoyberg Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Linking) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #8596 #9685 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by bgamari): This was merged to `ghc-7.10` as 6b08e42ad99bb7857b631f28db869def046bff35. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 20:26:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 20:26:04 -0000 Subject: [GHC] #10745: Error in fusion when compiling Data.Yaml In-Reply-To: <046.37d8d5c0695542a7552f6e9c30a12ec8@haskell.org> References: <046.37d8d5c0695542a7552f6e9c30a12ec8@haskell.org> Message-ID: <061.21560695dd0d540fcf41efcbdd2e7433@haskell.org> #10745: Error in fusion when compiling Data.Yaml ---------------------------------+-------------------------------------- Reporter: nclarke | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ---------------------------------+-------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: The patch referenced by simonpj in comment:3 has been merged to `ghc-7.10` as db85cbc689b50b52b08ae6326b51ff5d6f50932e. Closing. Reopen if you find this still occurs with the to-be-released 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 21:03:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 21:03:01 -0000 Subject: [GHC] #10926: wrong signature of atomic builtins In-Reply-To: <045.bcea973b69c7d9792e6dc5ce0503d185@haskell.org> References: <045.bcea973b69c7d9792e6dc5ce0503d185@haskell.org> Message-ID: <060.50854d7da7d6cd25c893803a2688dd57@haskell.org> #10926: wrong signature of atomic builtins ----------------------------------------+---------------------------------- Reporter: schwab | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1300 ----------------------------------------+---------------------------------- Comment (by Ben Gamari ): In [changeset:"e3d2bab86fc89113f8ee65800fdfac81d8d54851/ghc" e3d2bab8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e3d2bab86fc89113f8ee65800fdfac81d8d54851" Fix signature of atomic builtins This patch is due to Andreas Schwab. This fixes #10926, which reports (on AArch64) errors of the form, ``` /tmp/ghc1492_0/ghc_1.hc:2844:25: warning: passing argument 1 of 'hs_atomic_xor64' makes pointer from integer without a cast [-Wint-conversion] _c1Ho = hs_atomic_xor64((*Sp) + (((Sp[1]) << 0x3UL) + 0x10UL), Sp[2]); ^ In file included from /home/abuild/rpmbuild/BUILD/ghc-7.10.2/includes/Stg.h:273:0: 0, from /tmp/ghc1492_0/ghc_1.hc:3: /home/abuild/rpmbuild/BUILD/ghc-7.10.2/includes/stg/Prim.h:41:11: note: expected 'volatile StgWord64 * {aka volatile long unsigned int *}' but argument is of type 'long unsigned int' StgWord64 hs_atomic_xor64(volatile StgWord64 *x, StgWord64 val); ^ ``` Test Plan: Validate Reviewers: austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1300 GHC Trac Issues: #10926 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 21:03:42 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 21:03:42 -0000 Subject: [GHC] #10926: wrong signature of atomic builtins In-Reply-To: <045.bcea973b69c7d9792e6dc5ce0503d185@haskell.org> References: <045.bcea973b69c7d9792e6dc5ce0503d185@haskell.org> Message-ID: <060.9d20a7fc919d4badfdf031c1b82b2524@haskell.org> #10926: wrong signature of atomic builtins ----------------------------------------+---------------------------------- Reporter: schwab | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1300 ----------------------------------------+---------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged. Thanks Andreas! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 2 22:42:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Oct 2015 22:42:17 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.d10e83563cfc702c410805e3c53840a7@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: trommler Type: bug | Status: closed Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Changes (by erikd): * milestone: 8.0.1 => 7.10.3 Comment: Building git HEAD (with @trommler's patch applied) using ghc-7.10.2 still fails because the stage-0 compiler (ghc-7.10.2) doesn't have this patch. However, building git HEAD with ghc-7.8.4 works fine. Therefore requesting a back port of this patch to the 7.10 branch. Unfortunately @trommler's patch doesn't apply to the 7.10 branch so I'll get something working and attach it here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 05:22:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 05:22:44 -0000 Subject: [GHC] #10904: C finalizer may be called on re-used memory In-Reply-To: <046.82d7a624ac5d38e3fd81c14129ab8c8d@haskell.org> References: <046.82d7a624ac5d38e3fd81c14129ab8c8d@haskell.org> Message-ID: <061.7a8981223134df150d4266a9eeefd5dd@haskell.org> #10904: C finalizer may be called on re-used memory -------------------------------------+------------------------------------- Reporter: bherzog | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Runtime System | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1275 -------------------------------------+------------------------------------- Comment (by asr): I couldn't reproduce the Agda issue pointed out in the above description, i.e. Agda issue [https://github.com/agda/agda/issues/1518 1518], after this bug was fixed. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 07:40:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 07:40:45 -0000 Subject: [GHC] #9238: Negative zero broken In-Reply-To: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> References: <047.56415c116f5d14a35293c7c7b01ed1ce@haskell.org> Message-ID: <062.1f7c4984d3f2ba80247fe701ac40f0a5@haskell.org> #9238: Negative zero broken -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.8.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: #7858, #9451, | Differential Rev(s): Phab:D1061 #10215 | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` as 293bf83f209ed6202a131456bf93fd472a790b13. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 07:47:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 07:47:05 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.3f1f9ce26acbff6da8df8916105e1a30@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: closed Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Rev(s): Phab:D1123 #10435 | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Is there any reason why we *need* the toolchain upgrade for 7.10.3? Austin has pointed out to me that this sort of change carries with it substantial risk. Given that we want to ensure that 7.10.3 is stable, I think it is reasonable to be a bit conservative here. I'm going to close this for now as 296bc70b5ff6c853f2782e9ec5aa47a52110345e has been merged. If someone has a compelling reason why we need to update the toolchain then feel free to reopen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 07:48:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 07:48:44 -0000 Subject: [GHC] #10700: include/stg/Prim.h isn't C++ compatible In-Reply-To: <045.8e82f2e96f7b839c9a73a7c13e4442bc@haskell.org> References: <045.8e82f2e96f7b839c9a73a7c13e4442bc@haskell.org> Message-ID: <060.11a40dd1c99d06185a1aff41be144c15@haskell.org> #10700: include/stg/Prim.h isn't C++ compatible -------------------------------------+------------------------------------- Reporter: Fabian | Owner: rasen Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler (FFI) | Version: 7.10.1 Resolution: fixed | Keywords: FFI, | newcomers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1107 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Merged to `ghc-7.10` as 5c1fff2acdb57300411c3e803fbf6a9caaf2580b. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 07:50:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 07:50:28 -0000 Subject: [GHC] #10810: Data constructor operators mis-printed in Template Haskell In-Reply-To: <047.9a0eacfe35e8d9bc3ca01ce57985f5f2@haskell.org> References: <047.9a0eacfe35e8d9bc3ca01ce57985f5f2@haskell.org> Message-ID: <062.74e31a1c726a6d673e7d2b8b56a43255@haskell.org> #10810: Data constructor operators mis-printed in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10810 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-7.10` as cbd1ccbebd830476119e46330096c8bc38bfbfa0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 07:50:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 07:50:41 -0000 Subject: [GHC] #10810: Data constructor operators mis-printed in Template Haskell In-Reply-To: <047.9a0eacfe35e8d9bc3ca01ce57985f5f2@haskell.org> References: <047.9a0eacfe35e8d9bc3ca01ce57985f5f2@haskell.org> Message-ID: <062.e8dd3581c33caf12ff5f3459d9798205@haskell.org> #10810: Data constructor operators mis-printed in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Template Haskell | Version: 7.10.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10810 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 08:36:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 08:36:00 -0000 Subject: [GHC] #4370: Bring back monad comprehensions In-Reply-To: <046.49abdb223a4732cf8eac6690239b5924@haskell.org> References: <046.49abdb223a4732cf8eac6690239b5924@haskell.org> Message-ID: <061.fc900be643adf2444b8feb8bf9e396b7@haskell.org> #4370: Bring back monad comprehensions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.12.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): -------------------------------------+------------------------------------- Changes (by Slavon8): * Attachment "d40bd6a41276ebb3795cb50422975481.jpg" added. [http://kidkraftaccessories.tumblr.com/ was] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 10:25:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 10:25:04 -0000 Subject: [GHC] #10607: Auto derive from top to bottom In-Reply-To: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> References: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> Message-ID: <060.b23379271364a49a60359c85cfd32cec@haskell.org> #10607: Auto derive from top to bottom -------------------------------------+------------------------------------- Reporter: songzh | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: deriving, | typeclass, auto Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by songzh): Replying to [comment:5 goldfire]: > Yes -- TH struggles a bit with instance lookup and such. Implementing new querying features shouldn't be hard though, if you can suggest an API. > > Why do you need fancy querying capabilities for your use case? Where does `reifyInstances` fail for you? As for type synonyms, you can check out the `th-expand-syns` package. `th-desugar` also does (limited) type family expansion (among other, larger features). Replying to [comment:5 goldfire]: > Yes -- TH struggles a bit with instance lookup and such. Implementing new querying features shouldn't be hard though, if you can suggest an API. > > Why do you need fancy querying capabilities for your use case? Where does `reifyInstances` fail for you? As for type synonyms, you can check out the `th-expand-syns` package. `th-desugar` also does (limited) type family expansion (among other, larger features). Hi Richard I tried to implement a prototype of this top down deriving scheme with standalone deriving. The project is on https://github.com/HaskellZhangSong/TopdownDerive However, I have 3 problems about it. 1. It forces me to use `KindSignatures`, `ConstraintKind` and other extension which should not be needed.(please see `TopDownDeriveTest.hs` file) 2. For type synonym, I want to do it without using TypeSynonymInstance, but I am not sure how to get the arity of a type constructor. For example: `type T a = (a,a,a,a,a)` I need to generate (Eq a , Eq b, Eq c ,Eq d, Eq e) => (a,b,c,d,e). 3. When I derive some instances that based on Generic class like Binary or FromJSON it gives me a type error: {{{ Could not deduce (G.Generic a) arising from a use of `binary-0.7.6.1:Data.Binary.Class.$gdmget' from the context (B.Binary a) bound by the instance declaration }}} while I think `deriving instance (Binary a ,Binary b) => Binary (A a b)` should work fine. Why do I have to write `deriving instance (B.Binary a, G.Generic a) => (B.Binary (B a))`? And could you give me some suggestions to solve it. Thanks Song -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 10:26:47 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 10:26:47 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.5c8c9d13c2dfc8d33c6f6f34757c60b0@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: closed Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Rev(s): Phab:D1123 #10435 | -------------------------------------+------------------------------------- Comment (by bgamari): I've spoken to Phyx- about this issue. It seems there may be compelling reasons to merge (and thomie agrees), * The current GCC contains a bug where it can?t call itself recursively with response files: this means that Michael Snoyman?s response file patch (#8596) is essentially useless without a newer toolchain * The upgrade enables programs to run on Windows Server. As Phyx- said in `#ghc`, > since starting with Server 2008 SEHOP is enabled by default and the 32bit version of GHC (which was using a very old mingw GCC) did not correctly handle the exceptions. So windows would block the executable * Phyx- also said, > under the misc category we get a lot of different bug fixes for binutils. But I am not aware of any specific reported issues reported. Perhaps we could try merging and rope some Windows users into thorough testing pre-release? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 11:02:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 11:02:18 -0000 Subject: [GHC] #10342: Convert User Guide from DocBook to AsciiDoc In-Reply-To: <047.a035ea91c12271763d1f9dbbec183a42@haskell.org> References: <047.a035ea91c12271763d1f9dbbec183a42@haskell.org> Message-ID: <062.c6642506697aad61212c0e2760965e41@haskell.org> #10342: Convert User Guide from DocBook to AsciiDoc -------------------------------------+------------------------------------- Reporter: dmbergey | Owner: dmbergey Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.10.1 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): -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: In 4fd6207ec6960c429e6a1bcbe0282f625010f52a: {{{ Author: Ben Gamari <> Date: Thu Oct 1 01:08:41 2015 +0200 Move user's guide to ReStructuredText }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 11:04:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 11:04:19 -0000 Subject: [GHC] #365: GHC dies silently with faulty preprocessor In-Reply-To: <045.970f5372032e408119e71a3210b4ecaf@haskell.org> References: <045.970f5372032e408119e71a3210b4ecaf@haskell.org> Message-ID: <060.059ac16a11efc8e4fad31aafb88ddbc0@haskell.org> #365: GHC dies silently with faulty preprocessor ---------------------------------+---------------------------------------- Reporter: josefs | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: T365 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1256 ---------------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"b6f76b9aaca49df0fb06d8bad2f7edc5b5b8c095/ghc" b6f76b9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b6f76b9aaca49df0fb06d8bad2f7edc5b5b8c095" Prevent GHC from silently dying when preprocessor is not found The Windows preprocessor code calls `runInteractiveProcess` but does not check if an exception is thrown. `runInteractiveProcess` calls `CreateProcess` which when given a format the system loader does not know about will throw an exception. This is what makes #9399 fail. Ultimately we should not use any `CreateProcess` based calls but instead `ShellExecuteEx` as this would allow us to run applications that the shell knows about instead of just the loader. More details on #365. This patch removes `PhaseFailed` and throws `ProgramError` instead. `PhaseFailed` was largely unneeded since it never gave very useful information aside from the `errorcode` which was almost always `1`. `IOErrors` have also been eliminated and `GhcExceptions` thrown in their place wherever possible. Updates haddock submodule. Test Plan: `./validate` to make sure anything didn't break and `make TESTS="T365"` to test that an error is now properly thrown Reviewers: austin, thomie, bgamari Reviewed By: thomie, bgamari Subscribers: #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D1256 GHC Trac Issues: #365 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 11:04:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 11:04:19 -0000 Subject: [GHC] #9399: CPP does not process test case enum01.hs correctly In-Reply-To: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> References: <042.8bd2b8ed84f95b67c9cae49884c4f662@haskell.org> Message-ID: <057.4acd365ebd3da15bdf8fa8244239935a@haskell.org> #9399: CPP does not process test case enum01.hs correctly -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Resolution: | Keywords: cpp Operating System: Windows | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: enum01.hs Blocked By: | Blocking: Related Tickets: #365 | Differential Rev(s): Phab:D957 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b6f76b9aaca49df0fb06d8bad2f7edc5b5b8c095/ghc" b6f76b9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b6f76b9aaca49df0fb06d8bad2f7edc5b5b8c095" Prevent GHC from silently dying when preprocessor is not found The Windows preprocessor code calls `runInteractiveProcess` but does not check if an exception is thrown. `runInteractiveProcess` calls `CreateProcess` which when given a format the system loader does not know about will throw an exception. This is what makes #9399 fail. Ultimately we should not use any `CreateProcess` based calls but instead `ShellExecuteEx` as this would allow us to run applications that the shell knows about instead of just the loader. More details on #365. This patch removes `PhaseFailed` and throws `ProgramError` instead. `PhaseFailed` was largely unneeded since it never gave very useful information aside from the `errorcode` which was almost always `1`. `IOErrors` have also been eliminated and `GhcExceptions` thrown in their place wherever possible. Updates haddock submodule. Test Plan: `./validate` to make sure anything didn't break and `make TESTS="T365"` to test that an error is now properly thrown Reviewers: austin, thomie, bgamari Reviewed By: thomie, bgamari Subscribers: #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D1256 GHC Trac Issues: #365 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 11:10:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 11:10:40 -0000 Subject: [GHC] #365: GHC dies silently with faulty preprocessor In-Reply-To: <045.970f5372032e408119e71a3210b4ecaf@haskell.org> References: <045.970f5372032e408119e71a3210b4ecaf@haskell.org> Message-ID: <060.990ba0c5277b22f270a5ca077ccab282@haskell.org> #365: GHC dies silently with faulty preprocessor ---------------------------------+---------------------------------------- Reporter: josefs | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: T365 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1256 ---------------------------------+---------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 13:07:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 13:07:31 -0000 Subject: [GHC] #10928: Refine pattern synonym sigantures Message-ID: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> #10928: Refine pattern synonym sigantures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- > I think that the current state of pattern synonym signatures is quite > confusing, especially regarding the constraints. For those unfamiliar, > a signature looks like the following, > > {{{ > pattern ExNumPat :: (Show b) => (Num a, Eq a) => b -> T a > }}} > > The first constraint being the "provided constraints" and the second > the "required constraints". > > My main concern is when only a single constraint is specified then > these are treated as the provided constraints. The manual gives the > reason that this is the "more common" choice. It seems that this > motivation is driven by the original ticket which had a lengthy > discussion about GADTs. In my experience, the opposite is true, it is > more common to have required constraints. > > This is true especially in a few common cases such as `pattern Foo = > 27`, where users define pattern synonyms which have (overloaded) > literals on the RHS. The most general signature for such a pattern is > `pattern :: () => (Eq a, Num a) => a`. > > For this reason, I think it would be better if either > > 1. Only specifying one constraint corresponded to the required constraints > 2. We required users to specify both sets of constraints, even if the > provided constraints are empty. > > In terms of breakage, I don't think that pattern synonym signatures > are widely used yet. In both schemes it is possible to write backwards > compatible code by writing both sets of constraints. > > I think a lot of the confusion also arises from the unusual form of > the signature, it is unusual to specify two sets of constraints and I > suspect users tends to assume that a single set of constraints is > either provided or required depending on what they want it to mean. > Forcing the specification of both, forces the user to make the > distinction earlier rather than trying to decipher error messages. > This is copied from a message sent to ghc-devs. This ticket is to track the progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 14:47:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 14:47:22 -0000 Subject: [GHC] #10929: Enumeration-empty warning not firing for `[Integer]` Message-ID: <042.77b1c3c687824b00f5bd3d3fb7b3fd3e@haskell.org> #10929: Enumeration-empty warning not firing for `[Integer]` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- {{{ GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help ?:2> [10..4] :: [Integer] [] it :: [Integer] ?:3> [10..4] :: [Int] :3:1: Warning: Enumeration is empty [] it :: [Int] ?:4> [10..4] :: [Word] :4:1: Warning: Enumeration is empty [] it :: [Word] }}} (Trivial to fix, patch following shortly) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 14:47:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 14:47:30 -0000 Subject: [GHC] #10929: Enumeration-empty warning not firing for `[Integer]` In-Reply-To: <042.77b1c3c687824b00f5bd3d3fb7b3fd3e@haskell.org> References: <042.77b1c3c687824b00f5bd3d3fb7b3fd3e@haskell.org> Message-ID: <057.fc4c479329823ed1080e131e4ef16e78@haskell.org> #10929: Enumeration-empty warning not firing for `[Integer]` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by hvr): * owner: => hvr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 14:57:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 14:57:43 -0000 Subject: [GHC] #10929: Enumeration-empty warning not firing for `[Integer]` In-Reply-To: <042.77b1c3c687824b00f5bd3d3fb7b3fd3e@haskell.org> References: <042.77b1c3c687824b00f5bd3d3fb7b3fd3e@haskell.org> Message-ID: <057.54c2f34c93b1ca075dd13a0e57a82168@haskell.org> #10929: Enumeration-empty warning not firing for `[Integer]` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7881 | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by hvr): * related: => #7881 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 15:01:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 15:01:24 -0000 Subject: [GHC] #10929: Enumeration-empty warning not firing for `[Integer]` In-Reply-To: <042.77b1c3c687824b00f5bd3d3fb7b3fd3e@haskell.org> References: <042.77b1c3c687824b00f5bd3d3fb7b3fd3e@haskell.org> Message-ID: <057.a1d3412bcdbbce22e3b28d1da29604ae@haskell.org> #10929: Enumeration-empty warning not firing for `[Integer]` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | numeric/should_compile/T10929.hs Blocked By: | Blocking: Related Tickets: #7881 | Differential Rev(s): Phab:D1305 -------------------------------------+------------------------------------- Changes (by hvr): * testcase: => numeric/should_compile/T10929.hs * differential: => Phab:D1305 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 15:01:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 15:01:30 -0000 Subject: [GHC] #10929: Enumeration-empty warning not firing for `[Integer]` In-Reply-To: <042.77b1c3c687824b00f5bd3d3fb7b3fd3e@haskell.org> References: <042.77b1c3c687824b00f5bd3d3fb7b3fd3e@haskell.org> Message-ID: <057.27b463dd4d8ab3cd0010e341de83df63@haskell.org> #10929: Enumeration-empty warning not firing for `[Integer]` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: bug | Status: patch Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | numeric/should_compile/T10929.hs Blocked By: | Blocking: Related Tickets: #7881 | Differential Rev(s): Phab:D1305 -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 15:02:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 15:02:34 -0000 Subject: [GHC] #10930: missing empty-Enumeration warning for `Natural` Message-ID: <042.2b93c01d2c091805f9e006b42184d16c@haskell.org> #10930: missing empty-Enumeration warning for `Natural` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #7881, #10929 Differential Rev(s): | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 15:06:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 15:06:26 -0000 Subject: [GHC] #10930: missing empty-Enumeration warning for `Natural` In-Reply-To: <042.2b93c01d2c091805f9e006b42184d16c@haskell.org> References: <042.2b93c01d2c091805f9e006b42184d16c@haskell.org> Message-ID: <057.debf82b428d24c7ecca0c1a9d513dbc9@haskell.org> #10930: missing empty-Enumeration warning for `Natural` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7881, #10929 | Differential Rev(s): Phab:D1306 -------------------------------------+------------------------------------- Changes (by hvr): * owner: => hvr * differential: => Phab:D1306 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 16:33:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 16:33:07 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.16351c73f62bb87af75b7284620f0f89@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: closed Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Rev(s): Phab:D1123 #10435 | -------------------------------------+------------------------------------- Comment (by hanjoosten): There are several reports of problems with using windows and ghc 7.10.*. (see https://github.com/commercialhaskell/stack/issues/466 ). When using sandboxes on not too small program, these problems arise. Currently, our project too cannot use ghc 7.10 because of this. I am prefectly willing to do some testing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 16:34:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 16:34:42 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.adc5e156f4b7a604eeb215b343094e75@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Rev(s): Phab:D1123 #10435 | -------------------------------------+------------------------------------- Changes (by hanjoosten): * owner: Phyx- => * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 17:37:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 17:37:31 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures (was: Refine pattern synonym sigantures) In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.5ffc130d158a753e86c6d7a7cff67109@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.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): -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Other -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 18:01:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 18:01:24 -0000 Subject: [GHC] #10868: Make GHC generics capable of handling unboxed types In-Reply-To: <050.27f7f36fe7ccd6ec83005e9e4d3a8968@haskell.org> References: <050.27f7f36fe7ccd6ec83005e9e4d3a8968@haskell.org> Message-ID: <065.c62b1ecf3b8003eb7ef3c02a8da84df1@haskell.org> #10868: Make GHC generics capable of handling unboxed types -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8468 | Differential Rev(s): Phab:D1239 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6cde981a8788b225819be28659caddc35b77972d/ghc" 6cde981/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6cde981a8788b225819be28659caddc35b77972d" Make GHC generics capable of handling unboxed types This adds a data family (`URec`) and six data family instances (`UAddr`, `UChar`, `UDouble`, `UFloat`, `UInt`, and `UWord`) which a `deriving Generic(1)` clause will generate if it sees `Addr#`, `Char#`, `Double#`, `Float#`, `Int#`, or `Word#`, respectively. The programmer can then provide instances for these data family instances to provide custom implementations for unboxed types, similar to how derived `Eq`, `Ord`, and `Show` instances currently special-case unboxed types. Fixes #10868. Test Plan: ./validate Reviewers: goldfire, dreixel, bgamari, austin, hvr, kosmikus Reviewed By: dreixel, kosmikus Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1239 GHC Trac Issues: #10868 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 18:44:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 18:44:53 -0000 Subject: [GHC] #7881: Warning for pointless ranges like [5..2] In-Reply-To: <042.3f52e3278786af8796764c4631823af7@haskell.org> References: <042.3f52e3278786af8796764c4631823af7@haskell.org> Message-ID: <057.e98b7db253e3dfe21fe006d34ed5c706@haskell.org> #7881: Warning for pointless ranges like [5..2] -------------------------------------+--------------------------------- Reporter: mpe | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: beginner,warning Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- Comment (by Ben Gamari ): In [changeset:"0eb8fcd94b29ee9997b386e64203037bdf2aaa04/ghc" 0eb8fcd9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0eb8fcd94b29ee9997b386e64203037bdf2aaa04" Enable `Enumeration is empty` warnings for `Integer` This warning was implemented via abb3a9faa88fad3562ac41a148dd683765f47565 for addressing #7881. The bounded H2010 integral types were handled, but the `Integer` type was missed for the enumeration warning. Fixes #10929 Test Plan: reused T7881 testcase Reviewers: thomie, bgamari, austin Reviewed By: thomie, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1305 GHC Trac Issues: #10929 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 18:44:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 18:44:53 -0000 Subject: [GHC] #10929: Enumeration-empty warning not firing for `[Integer]` In-Reply-To: <042.77b1c3c687824b00f5bd3d3fb7b3fd3e@haskell.org> References: <042.77b1c3c687824b00f5bd3d3fb7b3fd3e@haskell.org> Message-ID: <057.9383364526baa1ac4778ef12830fde0e@haskell.org> #10929: Enumeration-empty warning not firing for `[Integer]` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: bug | Status: patch Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | numeric/should_compile/T10929.hs Blocked By: | Blocking: Related Tickets: #7881 | Differential Rev(s): Phab:D1305 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0eb8fcd94b29ee9997b386e64203037bdf2aaa04/ghc" 0eb8fcd9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0eb8fcd94b29ee9997b386e64203037bdf2aaa04" Enable `Enumeration is empty` warnings for `Integer` This warning was implemented via abb3a9faa88fad3562ac41a148dd683765f47565 for addressing #7881. The bounded H2010 integral types were handled, but the `Integer` type was missed for the enumeration warning. Fixes #10929 Test Plan: reused T7881 testcase Reviewers: thomie, bgamari, austin Reviewed By: thomie, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1305 GHC Trac Issues: #10929 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 18:44:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 18:44:53 -0000 Subject: [GHC] #10361: DeriveAnyClass does not fill in associated type defaults In-Reply-To: <047.18f32bb2aaf0fd43551e26193c9cadf9@haskell.org> References: <047.18f32bb2aaf0fd43551e26193c9cadf9@haskell.org> Message-ID: <062.0eb505be6dbd08ed2c77a4a18af62d15@haskell.org> #10361: DeriveAnyClass does not fill in associated type defaults -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1283 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2f74be9c8af1e167b21df1a27b96b6626cd446a9/ghc" 2f74be9c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2f74be9c8af1e167b21df1a27b96b6626cd446a9" Fill in associated type defaults with DeriveAnyClass Summary: Unlike `-XDefaultSignatures`, `-XDeriveAnyClass` would not fill in associated type family defaults when deriving a class which contained them. In order to fix this properly, `tcATDefault` needed to be used from `TcGenDeriv`. To avoid a module import cycle, `tcATDefault` was moved from `TcInstDcls` to `TcClsDcl`. Fixes #10361. Test Plan: ./validate Reviewers: kosmikus, dreixel, bgamari, austin, simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1283 GHC Trac Issues: #10361 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 18:45:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 18:45:43 -0000 Subject: [GHC] #10361: DeriveAnyClass does not fill in associated type defaults In-Reply-To: <047.18f32bb2aaf0fd43551e26193c9cadf9@haskell.org> References: <047.18f32bb2aaf0fd43551e26193c9cadf9@haskell.org> Message-ID: <062.b0babfe695f5b1957cd0e065e80479a0@haskell.org> #10361: DeriveAnyClass does not fill in associated type defaults -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: dreixel Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: fixed | 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): Phab:D1283 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 19:33:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 19:33:28 -0000 Subject: [GHC] #10929: Enumeration-empty warning not firing for `[Integer]` In-Reply-To: <042.77b1c3c687824b00f5bd3d3fb7b3fd3e@haskell.org> References: <042.77b1c3c687824b00f5bd3d3fb7b3fd3e@haskell.org> Message-ID: <057.ff7e23321675809201a028f74e85ece4@haskell.org> #10929: Enumeration-empty warning not firing for `[Integer]` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: bug | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | numeric/should_compile/T10929.hs Blocked By: | Blocking: Related Tickets: #7881 | Differential Rev(s): Phab:D1305 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 20:33:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 20:33:44 -0000 Subject: [GHC] #10672: GHCi linker does not understand C++ exception tables on Windows In-Reply-To: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> References: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> Message-ID: <060.ce8c50b60cc277f09c38800b4031e6ba@haskell.org> #10672: GHCi linker does not understand C++ exception tables on Windows -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Phyx- Type: bug | Status: patch Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9297 #10563 | Differential Rev(s): Phab:D1244 #8237 #9907 | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"620fc6f909cd6e51b5613454097ec1c9f323839a/ghc" 620fc6f9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="620fc6f909cd6e51b5613454097ec1c9f323839a" Make Windows linker more robust to unknown sections The Windows Linker has 3 main parts that this patch changes. 1) Identification and classification of sections 2) Adding of symbols to the symbols tables 3) Reallocation of sections 1. Previously section identification used to be done on a whitelisted basis. It was also exclusively being done based on the names of the sections. This meant that there was a bit of a cat and mouse game between `GCC` and `GHC`. Every time `GCC` added new sections there was a good chance `GHC` would break. Luckily this hasn't happened much in the past because the `GCC` versions `GHC` used were largely unchanged. The new code instead treats all new section as `CODE` or `DATA` sections, and changes the classifications based on the `Characteristics` flag in the PE header. By doing so we no longer have the fragility of changing section names. The one exception to this is the `.ctors` section, which has no differentiating flag in the PE header, but we know we need to treat it as initialization data. The check to see if the sections are aligned by `4` has been removed. The reason is that debug sections often time are `1 aligned` but do have relocation symbols. In order to support relocations of `.debug` sections this check needs to be gone. Crucially this assumption doesn't seem to be in the rest of the code. We only check if there are at least 4 bytes to realign further down the road. 2. The second loop is iterating of all the symbols in the file and trying to add them to the symbols table. Because the classification of the sections we did previously are (currently) not available in this phase we still have to exclude the sections by hand. If they don't we will load in symbols from sections we've explicitly ignored the in # 1. This whole part should rewritten to avoid this. But didn't want to do it in this commit. 3. Finally the sections are relocated. But for some reason the PE files contain a Linux relocation constant in them `0x0011` This constant as far as I can tell does not come from GHC (or I couldn't find where it's being set). I believe this is probably a bug in GAS. But because the constant is in the output we have to handle it. I am thus mapping it to the constant I think it should be `0x0003`. Finally, static linking *should* work, but won't. At least not if you want to statically link `libgcc` with exceptions support. Doing so would require you to link `libgcc` and `libstd++` but also `libmingwex`. The problem is that `libmingwex` also defines a lot of symbols that the RTS automatically injects into the symbol table. Presumably because they're symbols that it needs. like `coshf`. The these symbols are not in a section that is declared with weak symbols support. So if we ever want to get this working, we should either a) Ask mingw to declare the section as such, or b) treat all a imported symbols as being weak. Though this doesn't seem like it's a good idea.. Test Plan: Running ./validate for both x86 and x86_64 Also running the specific test case for #10672 make TESTS="T10672_x86 T10672_x64" Reviewed By: ezyang, thomie, austin Differential Revision: https://phabricator.haskell.org/D1244 GHC Trac Issues: #9907, #10672, #10563 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 20:33:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 20:33:44 -0000 Subject: [GHC] #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows In-Reply-To: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> References: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> Message-ID: <066.9e3738ccd04ca6a9dac4d4e6053abc7b@haskell.org> #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7103, #10051, | Differential Rev(s): Phab:D1244 #7056, #8546 | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"620fc6f909cd6e51b5613454097ec1c9f323839a/ghc" 620fc6f9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="620fc6f909cd6e51b5613454097ec1c9f323839a" Make Windows linker more robust to unknown sections The Windows Linker has 3 main parts that this patch changes. 1) Identification and classification of sections 2) Adding of symbols to the symbols tables 3) Reallocation of sections 1. Previously section identification used to be done on a whitelisted basis. It was also exclusively being done based on the names of the sections. This meant that there was a bit of a cat and mouse game between `GCC` and `GHC`. Every time `GCC` added new sections there was a good chance `GHC` would break. Luckily this hasn't happened much in the past because the `GCC` versions `GHC` used were largely unchanged. The new code instead treats all new section as `CODE` or `DATA` sections, and changes the classifications based on the `Characteristics` flag in the PE header. By doing so we no longer have the fragility of changing section names. The one exception to this is the `.ctors` section, which has no differentiating flag in the PE header, but we know we need to treat it as initialization data. The check to see if the sections are aligned by `4` has been removed. The reason is that debug sections often time are `1 aligned` but do have relocation symbols. In order to support relocations of `.debug` sections this check needs to be gone. Crucially this assumption doesn't seem to be in the rest of the code. We only check if there are at least 4 bytes to realign further down the road. 2. The second loop is iterating of all the symbols in the file and trying to add them to the symbols table. Because the classification of the sections we did previously are (currently) not available in this phase we still have to exclude the sections by hand. If they don't we will load in symbols from sections we've explicitly ignored the in # 1. This whole part should rewritten to avoid this. But didn't want to do it in this commit. 3. Finally the sections are relocated. But for some reason the PE files contain a Linux relocation constant in them `0x0011` This constant as far as I can tell does not come from GHC (or I couldn't find where it's being set). I believe this is probably a bug in GAS. But because the constant is in the output we have to handle it. I am thus mapping it to the constant I think it should be `0x0003`. Finally, static linking *should* work, but won't. At least not if you want to statically link `libgcc` with exceptions support. Doing so would require you to link `libgcc` and `libstd++` but also `libmingwex`. The problem is that `libmingwex` also defines a lot of symbols that the RTS automatically injects into the symbol table. Presumably because they're symbols that it needs. like `coshf`. The these symbols are not in a section that is declared with weak symbols support. So if we ever want to get this working, we should either a) Ask mingw to declare the section as such, or b) treat all a imported symbols as being weak. Though this doesn't seem like it's a good idea.. Test Plan: Running ./validate for both x86 and x86_64 Also running the specific test case for #10672 make TESTS="T10672_x86 T10672_x64" Reviewed By: ezyang, thomie, austin Differential Revision: https://phabricator.haskell.org/D1244 GHC Trac Issues: #9907, #10672, #10563 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 20:33:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 20:33:44 -0000 Subject: [GHC] #10563: GHC 7.10.1 Win7 x86_64 crash when building reflex-dom-0.1.1 In-Reply-To: <044.865cad2cae7a0515bb63b8ae4cd3b513@haskell.org> References: <044.865cad2cae7a0515bb63b8ae4cd3b513@haskell.org> Message-ID: <059.70d5e1578edd9e4e8a166ab6d30fae30@haskell.org> #10563: GHC 7.10.1 Win7 x86_64 crash when building reflex-dom-0.1.1 -------------------------------------+------------------------------------- Reporter: tejon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #10672 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"620fc6f909cd6e51b5613454097ec1c9f323839a/ghc" 620fc6f9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="620fc6f909cd6e51b5613454097ec1c9f323839a" Make Windows linker more robust to unknown sections The Windows Linker has 3 main parts that this patch changes. 1) Identification and classification of sections 2) Adding of symbols to the symbols tables 3) Reallocation of sections 1. Previously section identification used to be done on a whitelisted basis. It was also exclusively being done based on the names of the sections. This meant that there was a bit of a cat and mouse game between `GCC` and `GHC`. Every time `GCC` added new sections there was a good chance `GHC` would break. Luckily this hasn't happened much in the past because the `GCC` versions `GHC` used were largely unchanged. The new code instead treats all new section as `CODE` or `DATA` sections, and changes the classifications based on the `Characteristics` flag in the PE header. By doing so we no longer have the fragility of changing section names. The one exception to this is the `.ctors` section, which has no differentiating flag in the PE header, but we know we need to treat it as initialization data. The check to see if the sections are aligned by `4` has been removed. The reason is that debug sections often time are `1 aligned` but do have relocation symbols. In order to support relocations of `.debug` sections this check needs to be gone. Crucially this assumption doesn't seem to be in the rest of the code. We only check if there are at least 4 bytes to realign further down the road. 2. The second loop is iterating of all the symbols in the file and trying to add them to the symbols table. Because the classification of the sections we did previously are (currently) not available in this phase we still have to exclude the sections by hand. If they don't we will load in symbols from sections we've explicitly ignored the in # 1. This whole part should rewritten to avoid this. But didn't want to do it in this commit. 3. Finally the sections are relocated. But for some reason the PE files contain a Linux relocation constant in them `0x0011` This constant as far as I can tell does not come from GHC (or I couldn't find where it's being set). I believe this is probably a bug in GAS. But because the constant is in the output we have to handle it. I am thus mapping it to the constant I think it should be `0x0003`. Finally, static linking *should* work, but won't. At least not if you want to statically link `libgcc` with exceptions support. Doing so would require you to link `libgcc` and `libstd++` but also `libmingwex`. The problem is that `libmingwex` also defines a lot of symbols that the RTS automatically injects into the symbol table. Presumably because they're symbols that it needs. like `coshf`. The these symbols are not in a section that is declared with weak symbols support. So if we ever want to get this working, we should either a) Ask mingw to declare the section as such, or b) treat all a imported symbols as being weak. Though this doesn't seem like it's a good idea.. Test Plan: Running ./validate for both x86 and x86_64 Also running the specific test case for #10672 make TESTS="T10672_x86 T10672_x64" Reviewed By: ezyang, thomie, austin Differential Revision: https://phabricator.haskell.org/D1244 GHC Trac Issues: #9907, #10672, #10563 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 20:39:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 20:39:49 -0000 Subject: [GHC] #10672: GHCi linker does not understand C++ exception tables on Windows In-Reply-To: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> References: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> Message-ID: <060.1014daf92458d49343bdd68deb30f5fd@haskell.org> #10672: GHCi linker does not understand C++ exception tables on Windows -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Phyx- Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | rts/T10672/T10672_x86 T10672_x64 Blocked By: | Blocking: Related Tickets: #9297 #10563 | Differential Rev(s): Phab:D1244 #8237 #9907 | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => merge * testcase: => rts/T10672/T10672_x86 T10672_x64 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 20:49:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 20:49:17 -0000 Subject: [GHC] #10563: GHC 7.10.1 Win7 x86_64 crash when building reflex-dom-0.1.1 In-Reply-To: <044.865cad2cae7a0515bb63b8ae4cd3b513@haskell.org> References: <044.865cad2cae7a0515bb63b8ae4cd3b513@haskell.org> Message-ID: <059.bfc2dc22494e97f6ee1b69e2b37c6d0b@haskell.org> #10563: GHC 7.10.1 Win7 x86_64 crash when building reflex-dom-0.1.1 -------------------------------------+------------------------------------- Reporter: tejon | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 (Linking) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #10672 | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 7.10.3 Comment: This should be fixed in the next release. See #10672. If not, please reopen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 20:51:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 20:51:50 -0000 Subject: [GHC] #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows In-Reply-To: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> References: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> Message-ID: <066.e94d75341bd9dd6004e706b067793245@haskell.org> #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7103, #10051, | Differential Rev(s): Phab:D1244 #7056, #8546 | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed Comment: Should be really fixed now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 21:21:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 21:21:06 -0000 Subject: [GHC] #10672: GHCi linker does not understand C++ exception tables on Windows In-Reply-To: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> References: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> Message-ID: <060.abe5f569e10c651cd569749abaa26e4f@haskell.org> #10672: GHCi linker does not understand C++ exception tables on Windows -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Phyx- Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | rts/T10672/T10672_x86 T10672_x64 Blocked By: | Blocking: Related Tickets: #9297 #10563 | Differential Rev(s): Phab:D1244 #8237 #9907 | -------------------------------------+------------------------------------- Comment (by thomie): If #10726 is going to be merged, a path of without merge conflicts is: * 9f7cdfee3e9f9ca6fbfa27d3b2dc2d86ac4ee226 (#10705) * a442800fd27952bff9bf9773f514ee062f4b55d0 (#10705) * 54b7dc5537f8b871e655752bace1ad6f5e6fe89a * 7b211b4e5a38efca437d76ea442495370da7cc9a (#10726) * 620fc6f909cd6e51b5613454097ec1c9f323839a (this ticket) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 21:45:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 21:45:24 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.579a505f0eafbbd1c1ee5e166502e941@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: trommler Type: bug | Status: closed Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Changes (by erikd): * Attachment "0001-nativeGen-PPC-fix-16-bit-offsets-in-stack- handling.patch" added. Patch for 7.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 21:47:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 21:47:00 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.f10a9d1c0caa652933512b685224173e@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: trommler Type: bug | Status: merge Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 21:51:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 21:51:14 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.5d5703768c04653d4e6f82045c66a246@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: trommler Type: bug | Status: merge Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Comment (by erikd): I've attached a version of @trommler's patch for the 7.10 branch. WIth this patch applied to ghc-7.10.2, that compiler can build git HEAD again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 22:18:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 22:18:00 -0000 Subject: [GHC] #10873: Bad error message for incorrect pattern synonym signature In-Reply-To: <049.1015737e7e3a324fd7db7cc49a97b354@haskell.org> References: <049.1015737e7e3a324fd7db7cc49a97b354@haskell.org> Message-ID: <064.be0eed352febc75f1ae6f35991a313bc@haskell.org> #10873: Bad error message for incorrect pattern synonym signature -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 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): -------------------------------------+------------------------------------- Comment (by mpickering): Another note: there is another bad error message when there is an arity mismatch. Seems like some contexts need to be sprinkled in relevant places. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 22:41:21 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 22:41:21 -0000 Subject: [GHC] #10909: Test suite: Support non-utf8 locale In-Reply-To: <046.fa6aac9d3c2ea6a99e9e4dcd0986d398@haskell.org> References: <046.fa6aac9d3c2ea6a99e9e4dcd0986d398@haskell.org> Message-ID: <061.6b35ca9385234ba799fe24677b45e132@haskell.org> #10909: Test suite: Support non-utf8 locale -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Test Suite | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/unicode/T10907 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * testcase: => parser/unicode/T10907 * resolution: => fixed * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 22:41:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 22:41:46 -0000 Subject: [GHC] #10909: Test suite: Support non-utf8 locale In-Reply-To: <046.fa6aac9d3c2ea6a99e9e4dcd0986d398@haskell.org> References: <046.fa6aac9d3c2ea6a99e9e4dcd0986d398@haskell.org> Message-ID: <061.1d2b8d5afe8086e179eef7b3c29dbef7@haskell.org> #10909: Test suite: Support non-utf8 locale -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Test Suite | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * testcase: parser/unicode/T10907 => * resolution: fixed => Comment: Oops. Not done yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 22:53:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 22:53:03 -0000 Subject: [GHC] #10924: Template variable unbound in rewrite rule In-Reply-To: <047.723a648571c518eb9cf0f244f8acc218@haskell.org> References: <047.723a648571c518eb9cf0f244f8acc218@haskell.org> Message-ID: <062.380f6c0215a505eb1f584e1b07c9a4d4@haskell.org> #10924: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: singletons, | templatehaskell Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * milestone: => 7.10.3 Comment: I can reproduce this issue with ghc-7.10.2.20150906 (commit 108e35ff67586ffd570ca18d84a4f5fbf79727cc), which doesn't include the fix for #10689 yet. Run `cabal install --with-ghc=/opt/ghc/7.10.3/bin/ghc type-natural singletons` first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 22:54:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 22:54:40 -0000 Subject: [GHC] #10783: Partial type signatures should work in pattern synonym signatures In-Reply-To: <049.9210bbc1c425a4fe689a15bfe5ab9550@haskell.org> References: <049.9210bbc1c425a4fe689a15bfe5ab9550@haskell.org> Message-ID: <064.cd3b0124709edb169d544cbbf6a99275@haskell.org> #10783: Partial type signatures should work in pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by mpickering): * owner: => mpickering -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 23:12:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 23:12:08 -0000 Subject: [GHC] #10900: Suggestions for improvement of the PatternSynonyms chapter in the User's Guide In-Reply-To: <045.3ca8c7c70c117f1fbb26e794adbec55f@haskell.org> References: <045.3ca8c7c70c117f1fbb26e794adbec55f@haskell.org> Message-ID: <060.a0961a29b2491c37b16dd9ae762c9a70@haskell.org> #10900: Suggestions for improvement of the PatternSynonyms chapter in the User's Guide -------------------------------------+------------------------------------- Reporter: thomie | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.2 Resolution: | Keywords: | PatternSynonms Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by thomie): It is confusing that the type signatures are commented out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 23:38:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 23:38:18 -0000 Subject: [GHC] #10919: ghc: panic! (the 'impossible' happened) ... Dynamic linker not initialised In-Reply-To: <054.0b98f2d3ec398afce2ee51103df99d47@haskell.org> References: <054.0b98f2d3ec398afce2ee51103df99d47@haskell.org> Message-ID: <069.9f5f3a3ad09b041bc4fac59b7cce1571@haskell.org> #10919: ghc: panic! (the 'impossible' happened) ... Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: recursion-ninja | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: panic | impossible linker initialized Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: I tried to reproduce this issue. After installing cabal installing `c2hs`, it still wouldn't install the `cuda` package, because it requires https://developer.nvidia.com/cuda-downloads, which is 1.9GB, which is just too much and probably won't work on my laptop. In case you are using Ubuntu or Debian, you could try with either ghc-7.10.3 or ghc-head from this ppa: https://launchpad.net/~hvr/+archive/ubuntu/ghc. There is a chance it is already fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 3 23:53:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Oct 2015 23:53:51 -0000 Subject: [GHC] #10594: the ghc-7.10.1-x86_64-apple-darwin.tar.bz2 doesn't install /sw/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3/GHC In-Reply-To: <046.69b85de5f279bc6fd8a3f5ec62466a80@haskell.org> References: <046.69b85de5f279bc6fd8a3f5ec62466a80@haskell.org> Message-ID: <061.241e31d305fd0175ac56ddbfd497941c@haskell.org> #10594: the ghc-7.10.1-x86_64-apple-darwin.tar.bz2 doesn't install /sw/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3/GHC -------------------------------------+------------------------------------- Reporter: howarth | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded * failure: Other => Installing GHC failed * component: Compiler => Build System Comment: This would be a very strange issue if it were reproducible. You are saying the GHC directory is present after you unpack the .tar.bz2 file, but doesn't get installed when you run 'make install'. Can you try with ghc-7.10.2? The `DESTDIR=/sw` shouldn't be needed if you specify a `--prefix` to configure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 00:06:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 00:06:39 -0000 Subject: [GHC] #10554: Replacing existing attachment with the same name doesn't work In-Reply-To: <045.2f4472be5df2a2cd30bde47cef4d48c1@haskell.org> References: <045.2f4472be5df2a2cd30bde47cef4d48c1@haskell.org> Message-ID: <060.9c695c657d5b6d01debb7f5ad8b57058@haskell.org> #10554: Replacing existing attachment with the same name doesn't work -------------------------------------+------------------------------------- Reporter: thomie | Owner: hvr Type: bug | Status: new Priority: lowest | Milestone: Component: Trac & Git | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9675 | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * Attachment "T9675-max_bytes_used.png" added. Try again -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 00:06:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 00:06:39 -0000 Subject: [GHC] #10554: Replacing existing attachment with the same name doesn't work In-Reply-To: <045.2f4472be5df2a2cd30bde47cef4d48c1@haskell.org> References: <045.2f4472be5df2a2cd30bde47cef4d48c1@haskell.org> Message-ID: <060.26ab3fac76d31aff6d27bceca3a6642d@haskell.org> #10554: Replacing existing attachment with the same name doesn't work -------------------------------------+------------------------------------- Reporter: thomie | Owner: hvr Type: bug | Status: new Priority: lowest | Milestone: Component: Trac & Git | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9675 | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * Attachment "T9675-max_bytes_used.png" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 00:34:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 00:34:27 -0000 Subject: [GHC] #10513: ghc 7.6.3 Compiler panic with Generics In-Reply-To: <051.c09e61e0961a632608f776aed9796e7c@haskell.org> References: <051.c09e61e0961a632608f776aed9796e7c@haskell.org> Message-ID: <066.6fd580b84a9460ba101eed837f49832e@haskell.org> #10513: ghc 7.6.3 Compiler panic with Generics -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.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): -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: Closing, since there is a workaround (https://code.google.com/p/agda/issues/detail?id=1585 has been closed), and there won't be another 7.6 release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 04:04:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 04:04:49 -0000 Subject: [GHC] #10924: Template variable unbound in rewrite rule In-Reply-To: <047.723a648571c518eb9cf0f244f8acc218@haskell.org> References: <047.723a648571c518eb9cf0f244f8acc218@haskell.org> Message-ID: <062.24d6506e073cbe7652cb0c39ba4386a5@haskell.org> #10924: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: singletons, | templatehaskell Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by crockeea): I did figure out a workaround: don't use "as-patterns" at all. The following definition of `ppMul` compiles: {{{ ppMul :: PrimePower -> [PrimePower] -> [PrimePower] ppMul x [] = [x] ppMul (PP(p,e)) (PP (p',e'):pps') | p == p' = PP(p,e Num.+ e'):pps' | p <<= p' = (PP(p,e)):(PP (p',e'):pps') | otherwise = (PP(p',e')):ppMul (PP(p,e)) pps' }}} Since the point of using singletons is to get type-level functions, it's not clear that there is any performance overhead (except perhaps in the compiler) by rebuilding `PP(p,e)` and `PP(p,e')`, but it would be nice to be able to write this in a more idiomatic manner. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 09:35:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 09:35:08 -0000 Subject: [GHC] #10868: Make GHC generics capable of handling unboxed types In-Reply-To: <050.27f7f36fe7ccd6ec83005e9e4d3a8968@haskell.org> References: <050.27f7f36fe7ccd6ec83005e9e4d3a8968@haskell.org> Message-ID: <065.4e4f27eaa190593346ddfaf80c35c4fd@haskell.org> #10868: Make GHC generics capable of handling unboxed types -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8468 | Differential Rev(s): Phab:D1239 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 10:33:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 10:33:43 -0000 Subject: [GHC] #4879: Deprecate exports In-Reply-To: <049.ea1fa273b308c2a35269907288b50645@haskell.org> References: <049.ea1fa273b308c2a35269907288b50645@haskell.org> Message-ID: <064.8cef7f74ce11afedb405e430c786581e@haskell.org> #4879: Deprecate exports -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: feature request | Status: infoneeded Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: deprecate | warning Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10071 #2119 | Differential Rev(s): Phab:D638 -------------------------------------+------------------------------------- Comment (by bgamari): See [[Design/DeprecationMechanisms]] for a summary of this and related deprecation proposals. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 10:33:47 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 10:33:47 -0000 Subject: [GHC] #2119: explicitly importing deprecated symbols should elicit the deprecation warning In-Reply-To: <045.affc63bba10af8681f58c8409e4aaf99@haskell.org> References: <045.affc63bba10af8681f58c8409e4aaf99@haskell.org> Message-ID: <060.823c343212f78ae6fd4ed47b2d0088dd@haskell.org> #2119: explicitly importing deprecated symbols should elicit the deprecation warning -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: deprecate | warning Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4879 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by bgamari): See [[Design/DeprecationMechanisms]] for a summary of this and related deprecation proposals. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 10:33:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 10:33:52 -0000 Subject: [GHC] #10071: Implement deprecation-warnings for class-methods to non-method transitions In-Reply-To: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> References: <042.76da5bd8a8c91b7a70d78a09db0af881@haskell.org> Message-ID: <057.b70c0f99235e946f3f9d5ab88dbc9346@haskell.org> #10071: Implement deprecation-warnings for class-methods to non-method transitions -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: AMP MonadFail | deprecate warning Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8004, #4834, | Differential Rev(s): #4879, #2119 | -------------------------------------+------------------------------------- Comment (by bgamari): See [[Design/DeprecationMechanisms]] for a summary of this and related deprecation proposals. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 10:41:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 10:41:30 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.f490f7a2e379e4a2bac1dcd497222a31@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: trommler Type: bug | Status: closed Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Thanks erikd! Applied to `ghc-7.10` as e22d7dc434b64709a4b19b11f2e0a41676c04035. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 12:17:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 12:17:27 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.156a30be75616c1467fbf9619dfbee1b@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1284 -------------------------------------+------------------------------------- Comment (by bgamari): I realize that this has [[https://mail.haskell.org/pipermail/libraries/2015-May/025648.html|all been discussed before]] but I do wonder whether we really ''need'' to fold in `Data.List.NonEmpty` at this juncture? It does not appear to be a widely used type in practice and the interface has a few quirks. What do we gain by it being in `base`? The reason I ask is that I've noticed that `NonEmpty` introduces yet more partial functions to `base`. For instance, why must `words` have type `NonEmpty Char -> NonEmpty String`? Why not `NonEmpty Char -> [String]`? After all it seems quite reasonable for a non-empty string to nevertheless contain no words. Given that these are design decisions that reasonable people may disagree over, might it be best just to defer them packages outside of `base`? Sorry bringing this up so long after the initial consideration but I just wanted to make sure we have thoroughly considered this angle. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 13:27:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 13:27:30 -0000 Subject: [GHC] #10751: Implement Phase 1 of MonadFail Proposal (MFP) In-Reply-To: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> References: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> Message-ID: <057.59afba0020cac4885d9b921d6c772fd5@haskell.org> #10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: task | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1248 -------------------------------------+------------------------------------- Changes (by spl): * cc: spl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 14:30:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 14:30:06 -0000 Subject: [GHC] #4370: Bring back monad comprehensions In-Reply-To: <046.49abdb223a4732cf8eac6690239b5924@haskell.org> References: <046.49abdb223a4732cf8eac6690239b5924@haskell.org> Message-ID: <061.fc900be643adf2444b8feb8bf9e396b7@haskell.org> #4370: Bring back monad comprehensions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.12.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): -------------------------------------+------------------------------------- Changes (by Slavon8): * Attachment "d40bd6a41276ebb3795cb50422975481.jpg" removed. [http://kidkraftaccessories.tumblr.com/ was] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 14:32:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 14:32:32 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.46996dae14572de9cbd6a966d34eb45b@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1284 -------------------------------------+------------------------------------- Comment (by bergmark): I would like to see the partial functions removed as well. toList is total, which makes fromList the most natural name for converting to a NonEmpty, but nope it's partial! Use nonEmpty instead. There's also a partial IsList instance, I really don't want literals to be able to crash at runtime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 15:12:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 15:12:34 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.488f4557dab904567bc0362c4332713c@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1284 -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:21 bergmark]: > I really don't want literals to be able to crash at runtime. Bear in mind that it's already possible for literals to crash at runtime: {{{ $ ghci GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help ?> import Numeric.Natural ?> -1 :: Natural *** Exception: arithmetic underflow }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 15:20:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 15:20:51 -0000 Subject: [GHC] #10930: missing empty-Enumeration and out-of-range warning for `Natural` (was: missing empty-Enumeration warning for `Natural`) In-Reply-To: <042.2b93c01d2c091805f9e006b42184d16c@haskell.org> References: <042.2b93c01d2c091805f9e006b42184d16c@haskell.org> Message-ID: <057.0578ded7f975ca33a62b09e85b478bc9@haskell.org> #10930: missing empty-Enumeration and out-of-range warning for `Natural` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7881, #10929 | Differential Rev(s): Phab:D1306 -------------------------------------+------------------------------------- Description changed by hvr: Old description: New description: {{{ GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help ?:2> :set -XNegativeLiterals ?:3> (-123) :: Word :3:2: Warning: Literal -123 is out of the Word range 0..18446744073709551615 18446744073709551493 it :: Word ?:4> (-123) :: Numeric.Natural.Natural *** Exception: arithmetic underflow ?:5> ?:6> [10..3] :: [Word] :6:1: Warning: Enumeration is empty [] it :: [Word] ?:7> [10..3] :: [Numeric.Natural.Natural] [] it :: [GHC.Natural.Natural] }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 15:21:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 15:21:40 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.887d5ff00c3ec26572cd717b72961ab2@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1284 -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:22 RyanGlScott]: > Bear in mind that it's already possible for literals to crash at runtime: > {{{ > ?> -1 :: Natural > *** Exception: arithmetic underflow > }}} Somewhat related, #10930 wants GHC to at least emit a compiler warning in that case -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 17:10:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 17:10:20 -0000 Subject: [GHC] #10498: "if ... then \case -> else ..." causes a "missing else clause" error In-Reply-To: <050.28cad0c5bb9248828a1f63b683a53853@haskell.org> References: <050.28cad0c5bb9248828a1f63b683a53853@haskell.org> Message-ID: <065.2fc5d4ae9a1a1ab956918e03216a1312@haskell.org> #10498: "if ... then \case -> else ..." causes a "missing else clause" error -------------------------------------+------------------------------------- Reporter: dramforever | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1309 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D1309 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 18:12:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 18:12:52 -0000 Subject: [GHC] #10457: Revise/remove custom mapM implementation for lists In-Reply-To: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> References: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> Message-ID: <059.223f3401d577f22b8c92390199beb05f@haskell.org> #10457: Revise/remove custom mapM implementation for lists -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.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): Phab:D1124 -------------------------------------+------------------------------------- Changes (by thomie): * failure: None/Unknown => Runtime performance bug Comment: nofib/allocs/cryptarithm2 13094088 + 64.55% 21545696 bytes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 18:23:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 18:23:18 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.79dafb13a8a06dc72fc65b6d06a40f0d@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D586 | Phab:D587 Phab:D1244 -------------------------------------+------------------------------------- Changes (by Phyx-): * differential: Phab:D586 Phab:D587 => Phab:D586 Phab:D587 Phab:D1244 Comment: Fixed by 620fc6f909cd6e51b5613454097ec1c9f323839a, will remove the expect_broken in review soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 21:08:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 21:08:23 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.332105ea7bbfddc07c9893d62639db0f@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1259 -------------------------------------+------------------------------------- Comment (by gridaphobe): Ok, here's a version of Joachim's test case that doesn't involve CallStacks. {{{#!haskell ==> T10844a.hs <== module T10844a where data Foo = Foo Int String showFoo (Foo i s) = unwords [ "Foo", show i, show s ] foo n = showFoo $ Foo 0 "foo" {-# INLINE foo #-} ==> T10844.hs <== module T10844 where import T10844a main = print (foo 0) }}} With optimizations it produces the following core {{{ % ghc --make -fforce-recomp -ddump-simpl T10844.hs -O [1 of 2] Compiling T10844a ( T10844a.hs, T10844a.o ) ==================== Tidy Core ==================== Result size of Tidy Core = {terms: 61, types: 45, coercions: 0} T10844a.showFoo3 :: [Char] [GblId, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 40 0}] T10844a.showFoo3 = GHC.CString.unpackCString# "Foo"# T10844a.showFoo2 :: Char [GblId, Caf=NoCafRefs, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] T10844a.showFoo2 = GHC.Types.C# ' ' T10844a.showFoo1 :: [Char] [GblId, Caf=NoCafRefs, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] T10844a.showFoo1 = GHC.Types.: @ Char GHC.Show.shows6 (GHC.Types.[] @ Char) T10844a.$wshowFoo [InlPrag=[0]] :: Int -> String -> String [GblId, Arity=2, Str=DmdType , Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20 0] 220 0}] T10844a.$wshowFoo = \ (ww_sRs :: Int) (ww1_sRt :: String) -> ++ @ Char T10844a.showFoo3 (GHC.Types.: @ Char T10844a.showFoo2 (case ww_sRs of _ [Occ=Dead] { GHC.Types.I# ww3_aQt -> case GHC.Show.$wshowSignedInt 0 ww3_aQt (GHC.Types.[] @ Char) of _ [Occ=Dead] { (# ww5_aQx, ww6_aQy #) -> ++ @ Char (GHC.Types.: @ Char ww5_aQx ww6_aQy) (GHC.Types.: @ Char T10844a.showFoo2 (++ @ Char (GHC.Types.: @ Char GHC.Show.shows6 (GHC.Show.showLitString ww1_sRt T10844a.showFoo1)) (GHC.Types.[] @ Char))) } })) showFoo [InlPrag=INLINE[0]] :: Foo -> String [GblId, Arity=1, Str=DmdType , Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False) Tmpl= \ (w_sRp [Occ=Once!] :: Foo) -> case w_sRp of _ [Occ=Dead] { Foo ww1_sRs [Occ=Once] ww2_sRt [Occ=Once] -> T10844a.$wshowFoo ww1_sRs ww2_sRt }}] showFoo = \ (w_sRp :: Foo) -> case w_sRp of _ [Occ=Dead] { Foo ww1_sRs ww2_sRt -> T10844a.$wshowFoo ww1_sRs ww2_sRt } lvl_rEJ :: Int [GblId, Caf=NoCafRefs, Str=DmdType] lvl_rEJ = GHC.Types.I# 0 lvl1_rRU :: [Char] [GblId, Str=DmdType] lvl1_rRU = GHC.CString.unpackCString# "foo"# lvl2_rRV :: String [GblId, Str=DmdType] lvl2_rRV = T10844a.$wshowFoo lvl_rEJ lvl1_rRU foo [InlPrag=INLINE (sat-args=1)] :: forall t_aOn. t_aOn -> String [GblId, Arity=1, Str=DmdType , Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=False,boring_ok=False) Tmpl= \ (@ t_aOp) _ [Occ=Dead] -> $ @ Foo @ String showFoo (T10844a.Foo (GHC.Types.I# 0) (GHC.Base.build @ Char (\ (@ b_aPw) -> GHC.CString.unpackFoldrCString# @ b_aPw "foo"#)))}] foo = \ (@ t_aOp) _ [Occ=Dead] -> lvl2_rRV [2 of 2] Compiling T10844 ( T10844.hs, T10844.o ) ==================== Tidy Core ==================== Result size of Tidy Core = {terms: 31, types: 22, coercions: 3} T10844.main7 :: Int [GblId, Caf=NoCafRefs, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] T10844.main7 = GHC.Types.I# 0 T10844.main6 :: [Char] [GblId, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 40 0}] T10844.main6 = GHC.CString.unpackCString# "foo"# T10844.main5 :: String [GblId, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 30 0}] T10844.main5 = T10844a.$wshowFoo T10844.main7 T10844.main6 ... }}} The problem is that the unfolding for `foo` contains the string literal `"foo"` instead of the floated `lvl1_rRU`, so we end up inlining the string literal in `T10844`, which seems rather pointless. In fact, I'd argue that since the `Foo 0 "foo"` doesn't contain any free variables, the whole thing should be floated to the top-level. GHC actually goes further and floats the entire RHS (to `lvl2_rRV`), but it doesn't update `foo`s unfolding. The thing that I'm unsure about is that this example relies on the `INLINE` pragma. As I understand it, `INLINE` tells GHC to unconditionally inline the entire definition, which is precisely what it's doing here. (`INLINEABLE` has a similar effect in this example.) The more general fix, to make the unfolding reflect the result of the FloatOut pass, would subtly change the semantics of `INLINE`. It would no longer mean "inline the entire RHS" but rather "inline the pieces of the RHS that we think are sensible to inline". Is that a change we want to make? It would certainly decrease binary sizes, but it seems like that could also cause a performance loss due to increased cache misses. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 21:28:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 21:28:09 -0000 Subject: [GHC] #10888: ghci crashes In-Reply-To: <048.cd08c1c66af702cf9c35bbada74b978c@haskell.org> References: <048.cd08c1c66af702cf9c35bbada74b978c@haskell.org> Message-ID: <063.88d5cec06d34864695d2800b4621bdd4@haskell.org> #10888: ghci crashes -------------------------------+------------------------------ Reporter: parsifal9 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------+------------------------------ Comment (by erikd): This is probably a dupe of #10375. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 21:29:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 21:29:02 -0000 Subject: [GHC] #10633: GHCi segfaults on arm In-Reply-To: <045.ce30a9b63cbcf433a0315ff9f9caf317@haskell.org> References: <045.ce30a9b63cbcf433a0315ff9f9caf317@haskell.org> Message-ID: <060.337ee85946ff3c7a372e02d221e90ea2@haskell.org> #10633: GHCi segfaults on arm -------------------------------+------------------------------ Reporter: Thra11 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------+------------------------------ Comment (by erikd): This is probably a dupe of #10375. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 21:33:47 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 21:33:47 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.4ebd4d8e120263282c11b2bb234db3f7@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1259 -------------------------------------+------------------------------------- Comment (by nomeata): > The more general fix, to make the unfolding reflect the result of the FloatOut pass, would subtly change the semantics of INLINE AFAIK, we promise that when something is marked as `INLINE`, it the unfolding will match closely the definition and is _not_ already optimized. Floating stuff out here might for example prevent rules from firing at the inline site. Here the quote from the user?s guide: > So GHC guarantees to inline precisely the code that you wrote, no more and no less. It does this by capturing a copy of the definition of the function to use for inlining (we call this the "inline-RHS"), which it leaves untouched, while optimising the ordinarily RHS as usual. For externally-visible functions the inline-RHS (not the optimised RHS) is recorded in the interface file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 22:48:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 22:48:56 -0000 Subject: [GHC] #10931: layers-0.1 does not compile with ghc-7.10 (likely a regression from ghc-7.8) Message-ID: <045.19b8056b1d70bf96a656ae7348a956cb@haskell.org> #10931: layers-0.1 does not compile with ghc-7.10 (likely a regression from ghc-7.8) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- Distilled example is the following: {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE AllowAmbiguousTypes #-} -- not needed for 7.8, should not be needed for 7.10 as well {-# OPTIONS_GHC -Wall #-} module L () where import Prelude () -- clean up data IdT f a = IdC (f a) class ( m ~ Outer m (Inner m) ) => BugC (m :: * -> *) where type Inner m :: * -> * type Outer m :: (* -> *) -> * -> * bug :: ( forall n. ( n ~ Outer n (Inner n) , Outer n ~ Outer m ) => Inner n a) -> m a instance BugC (IdT m) where type Inner (IdT m) = m type Outer (IdT m) = IdT bug f = IdC f }}} ghc-7.8 compiles the sample just fine: {{{ $ ghci a.hs GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling L ( a.hs, interpreted ) Ok, modules loaded: L. *L> :t bug bug :: (BugC (t1 t), Outer (t1 t) ~ t1, Inner (t1 t) ~ t) => (forall (n :: * -> *). (n ~ Outer n (Inner n), Outer n ~ Outer (t1 t)) => Inner n a) -> t1 t a }}} ghc-7.10 can't build it even with AllowAmbiguousTypes {{{ $ ghci a.hs GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling L ( a.hs, interpreted ) a.hs:28:17: Couldn't match type ?m? with ?Inner (IdT m)? ?m? is a rigid type variable bound by the instance declaration at a.hs:24:10 Expected type: Outer (IdT m) (Inner (IdT m)) Actual type: IdT m Relevant bindings include f :: forall (n :: * -> *). (n ~ Outer n (Inner n), Outer n ~ Outer (IdT m)) => Inner n a (bound at a.hs:28:9) bug :: (forall (n :: * -> *). (n ~ Outer n (Inner n), Outer n ~ Outer (IdT m)) => Inner n a) -> IdT m a (bound at a.hs:28:5) In the first argument of ?IdC?, namely ?f? In the expression: IdC f In an equation for ?bug?: bug f = IdC f Failed, modules loaded: none. }}} Without AllowAmbiguousTypes the error gives a hint on ambiguity (which does not really exist as I understand associated type families): {{{ $ ghci a-no-ambig-language.hs GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling L ( a.hs, interpreted ) a.hs:28:17: Couldn't match type ?m? with ?Inner (IdT m)? ?m? is a rigid type variable bound by the instance declaration at a.hs:24:10 Expected type: Outer (IdT m) (Inner (IdT m)) Actual type: IdT m Relevant bindings include f :: forall (n :: * -> *). (n ~ Outer n (Inner n), Outer n ~ Outer (IdT m)) => Inner n a (bound at a.hs:28:9) bug :: (forall (n :: * -> *). (n ~ Outer n (Inner n), Outer n ~ Outer (IdT m)) => Inner n a) -> IdT m a (bound at a.hs:28:5) In the first argument of ?IdC?, namely ?f? In the expression: IdC f In an equation for ?bug?: bug f = IdC f Failed, modules loaded: none. }}} It seems that ghc-7.8 is more correct here. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 4 22:55:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Oct 2015 22:55:49 -0000 Subject: [GHC] #10931: layers-0.1 does not compile with ghc-7.10 (likely a regression from ghc-7.8) In-Reply-To: <045.19b8056b1d70bf96a656ae7348a956cb@haskell.org> References: <045.19b8056b1d70bf96a656ae7348a956cb@haskell.org> Message-ID: <060.68b613107ad2bd0881bcbc118dc50ed2@haskell.org> #10931: layers-0.1 does not compile with ghc-7.10 (likely a regression from ghc-7.8) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by thomie): Works fine with HEAD (ghc-7.11.20150921), also without `AllowAmbiguousTypes`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 00:26:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 00:26:09 -0000 Subject: [GHC] #10845: Incorrect behavior when let binding implicit CallStack object In-Reply-To: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> References: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> Message-ID: <068.e8a6c4f1b671382ba7b35fbbe0c80686@haskell.org> #10845: Incorrect behavior when let binding implicit CallStack object -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10846 | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by gridaphobe): * related: => #10846 Comment: Ok, the problem is that when we infer the type of a let-bound variable, we attempt to solve any constraints generated from the RHS without consulting the given constraints from the surrounding context. Specifically, `TcSimplify.simplifyInfer` tries to solve the wanteds with no givens. This is problematic for CallStacks because of the special rule that allows us to discharge a CallStack IP constraint without a given CallStack, by creating one out of thin air. So in {{{#!haskell f :: (?loc :: CallStack) => [(String, SrcLoc)] f = let y = getCallStack ?loc in y }}} the use of `getCallStack` tells GHC that `?loc :: CallStack`, and GHC immediately discharges the IP constraint without seeing the CallStack given by `f`'s context, while in {{{#!haskell f :: (?loc :: CallStack) => [(String, SrcLoc)] f = let y = ?loc in getCallStack y }}} we end up with a generic `?loc::t` constraint that GHC can't solve, until it emits an implication with `f`'s given constraints. I can work around this by splitting off any IP wanteds at the beginning of `simplifyInfer` and stitching them back onto the final implication constraint that `simplifyInfer` emits, but I'm not sure if this is the right solution. I don't think it should affect regular IPs since we always infer an IP constraint in local binders, but I still need to validate my patch. Also, I believe #10846 is closely related to this issue because `PartialTypeSignatures` triggers a similar code path through `TcBinds.tcPolyInfer` and `TcSimplify.simplifyInfer`, causing us to lose sight of the given IP constraint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 04:42:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 04:42:50 -0000 Subject: [GHC] #10845: Incorrect behavior when let binding implicit CallStack object In-Reply-To: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> References: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> Message-ID: <068.ba7e7dc5f7f41b659f46f562198dbd0f@haskell.org> #10845: Incorrect behavior when let binding implicit CallStack object -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10846 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by gridaphobe): Hrm, unfortunately splitting off the wanted IP constraints in `simplifyInfer` doesn't work because we need them to infer a corresponding given. For example, in {{{#!haskell f :: (?x :: Int) => Int f = let y = ?x in y }}} we want to infer `y :: (?x :: Int) => Int` (according to the Note "Inheriting Implicit Parameters"). But with CallStack IPs, {{{#!haskell f :: (?x :: CallStack) => [(String, SrcLoc)] f = let y = getCallStack ?x in y }}} we want to infer `y :: [(String, SrcLoc)]`. We really '''don't''' want to infer a CallStack IP here because that would add an extra location to the stack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 07:54:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 07:54:58 -0000 Subject: [GHC] #10932: Pattern synonyms and view pattern arguments Message-ID: <046.11bfef7c262f81a9e67459af0fd00c20@haskell.org> #10932: Pattern synonyms and view pattern arguments -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- In my code, I had a few complicated patterns involving view patterns that depended on local arguments, i.e. {{{ foo env (someView env -> Just x) = ... }}} I was hoping to be able to use PatternSynonyms to abstract and simplify this: {{{ pattern Pat env x <- (someView env -> Just x) foo env (Pat env x) = ... }}} but it says `Not in scope: env`. It would be nice if I could use pattern synonyms here as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 08:26:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 08:26:13 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.7a5b3c9b68556ba50046fdc1fa442143@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D586 | Phab:D587 Phab:D1244 Phab:D1310 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: Phab:D586 Phab:D587 Phab:D1244 => Phab:D586 Phab:D587 Phab:D1244 Phab:D1310 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 08:26:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 08:26:31 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.643729ff044c66eedd572eaa536031ab@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D586 | Phab:D587 Phab:D1244 Phab:D1310 -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 08:28:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 08:28:28 -0000 Subject: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files In-Reply-To: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> References: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> Message-ID: <059.912e0b2a22177d5a7922d06b2fc80788@haskell.org> #1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: archblob Type: feature request | Status: patch Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 6.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D194 | Phab:D1310 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: Phab:D194 => Phab:D194 Phab:D1310 Comment: Hi archblob, This should be covered under Phab:D1310 that I submitted to correct another issue. See test 'ghci_short_name'. Let me know if this is sufficient for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 08:28:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 08:28:55 -0000 Subject: [GHC] #1883: GHC can't find library using "short" name In-Reply-To: <045.76e5dee1da7bd3e6c3d26431d4641cce@haskell.org> References: <045.76e5dee1da7bd3e6c3d26431d4641cce@haskell.org> Message-ID: <060.5e5d719ce513b7ce392359c928b730d3@haskell.org> #1883: GHC can't find library using "short" name -------------------------------------+------------------------------------- Reporter: m4dc4p | Owner: Phyx- Type: bug | Status: patch Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: link library | windows Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #2283 #3242 | Differential Rev(s): Phab:D1310 #1883 #7097 | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D1310 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 08:29:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 08:29:11 -0000 Subject: [GHC] #5289: Can't use ghci with a library linked against libstdc++ In-Reply-To: <042.ca5f68f0f4907cc12990f083dfa50f2f@haskell.org> References: <042.ca5f68f0f4907cc12990f083dfa50f2f@haskell.org> Message-ID: <057.e6ac0065e9cd196d2a7c211747e4c3a4@haskell.org> #5289: Can't use ghci with a library linked against libstdc++ -------------------------------+---------------------------------------- Reporter: bos | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------+---------------------------------------- Changes (by Phyx-): * owner: => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 08:29:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 08:29:26 -0000 Subject: [GHC] #5289: Can't use ghci with a library linked against libstdc++ In-Reply-To: <042.ca5f68f0f4907cc12990f083dfa50f2f@haskell.org> References: <042.ca5f68f0f4907cc12990f083dfa50f2f@haskell.org> Message-ID: <057.5e0ee47e7c4fdf0d5e65728423745025@haskell.org> #5289: Can't use ghci with a library linked against libstdc++ -------------------------------+---------------------------------------- Reporter: bos | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1310 -------------------------------+---------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D1310 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 08:44:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 08:44:23 -0000 Subject: [GHC] #10931: layers-0.1 does not compile with ghc-7.10 (likely a regression from ghc-7.8) In-Reply-To: <045.19b8056b1d70bf96a656ae7348a956cb@haskell.org> References: <045.19b8056b1d70bf96a656ae7348a956cb@haskell.org> Message-ID: <060.50537f90da03aa71d7ab11fdda32aeae@haskell.org> #10931: layers-0.1 does not compile with ghc-7.10 (likely a regression from ghc-7.8) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by slyfox): Oh that's good! ghc-7.10 branch doesn't work though. I wonder when it was fixed. {{{ $ inplace/bin/ghc-stage2 --interactive T10931.hs GHCi, version 7.10.2.20151003: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling L ( T10931.hs, interpreted ) T10931.hs:28:17: Couldn't match type ?m? with ?Inner (IdT m)? ?m? is a rigid type variable bound by the instance declaration at T10931.hs:24:10 Expected type: Outer (IdT m) (Inner (IdT m)) Actual type: IdT m Relevant bindings include f :: forall (n :: * -> *). (n ~ Outer n (Inner n), Outer n ~ Outer (IdT m)) => Inner n a (bound at T10931.hs:28:9) bug :: (forall (n :: * -> *). (n ~ Outer n (Inner n), Outer n ~ Outer (IdT m)) => Inner n a) -> IdT m a (bound at T10931.hs:28:5) In the first argument of ?IdC?, namely ?f? In the expression: IdC f In an equation for ?bug?: bug f = IdC f Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 09:14:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 09:14:57 -0000 Subject: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files In-Reply-To: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> References: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> Message-ID: <059.26962cabcdae4a0953245a7ffbba2be5@haskell.org> #1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: archblob Type: feature request | Status: patch Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 6.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D194 | Phab:D1310 -------------------------------------+------------------------------------- Comment (by archblob): Hello Phyx, Yes it covers it and I see that you have made it so that the old test still runs on linux. I'm of the opinion that we should also make the linux test against your custom lib so that we don't have any headaches in the future. I can do it, or you can do it after your patch lands, whatever is best for you, just let me know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 10:03:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 10:03:56 -0000 Subject: [GHC] #10932: Pattern synonyms and view pattern arguments In-Reply-To: <046.11bfef7c262f81a9e67459af0fd00c20@haskell.org> References: <046.11bfef7c262f81a9e67459af0fd00c20@haskell.org> Message-ID: <061.ecf506c59bc05bce1bc10e88874e89c8@haskell.org> #10932: Pattern synonyms and view pattern arguments -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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): -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate Comment: Duplicate of #9671. As discussed there, really needs some better syntax to distinguish the roles of `env` (argument to the pattern) and `x` (bound by the pattern) in `Pat env x`. (Presumably `env` could be any name in scope, not necessarily bound by the same equation.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 10:04:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 10:04:04 -0000 Subject: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files In-Reply-To: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> References: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> Message-ID: <059.ff06a97e3e59bb6ef3c5bcd7167f35fe@haskell.org> #1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: archblob Type: feature request | Status: patch Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 6.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D194 | Phab:D1310 -------------------------------------+------------------------------------- Comment (by Phyx-): I can make the changes that's no problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 10:28:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 10:28:04 -0000 Subject: [GHC] #10751: Implement Phase 1 of MonadFail Proposal (MFP) In-Reply-To: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> References: <042.af0b8689bcfac4a130648c64d759a4c0@haskell.org> Message-ID: <057.ef4a6e1966c238ee26b46e2c43d681f7@haskell.org> #10751: Implement Phase 1 of MonadFail Proposal (MFP) -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: task | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1248 -------------------------------------+------------------------------------- Comment (by spl): I worked a bit on the wiki proposal. I think it would be good to indicate (1) which {{{MonadFail}}} instances will be created and (2) which types with {{{Monad}}} instances will not have {{{MonadFail}}} instances. Since this change affects a number of important packages, those packages should probably be included. Also, I'm not clear on the conclusion for having {{{Monad}}} vs. {{{Applicative}}} as the superclass constraint on {{{MonadFail}}}. I tried to develop the discussion text on this a bit. Since we're getting {{{ApplicativeDo}}} soon, I think it would be useful to work out whether and how these two features are related. I didn't see anything on ApplicativeDo referring to the desugaring of pattern matching. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 10:33:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 10:33:42 -0000 Subject: [GHC] #10932: Pattern synonyms and view pattern arguments In-Reply-To: <046.11bfef7c262f81a9e67459af0fd00c20@haskell.org> References: <046.11bfef7c262f81a9e67459af0fd00c20@haskell.org> Message-ID: <061.60b43e61afac49d729080d66800f701c@haskell.org> #10932: Pattern synonyms and view pattern arguments -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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): -------------------------------------+------------------------------------- Comment (by simonpj): Yes... the tricky issue here is syntactic: how to make it clear what is bound and what is binding. Even when that's solved there'd be the question of how to write the type of `Pat`, which has a mixture of bound and bind args. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 10:49:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 10:49:49 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.b624fd16e1cd28549f3fa4cd1792e3f2@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.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): -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > > I think that the current state of pattern synonym signatures is quite > > confusing, especially regarding the constraints. For those unfamiliar, > > a signature looks like the following, > > > > {{{ > > pattern ExNumPat :: (Show b) => (Num a, Eq a) => b -> T a > > }}} > > > > The first constraint being the "provided constraints" and the second > > the "required constraints". > > > > My main concern is when only a single constraint is specified then > > these are treated as the provided constraints. The manual gives the > > reason that this is the "more common" choice. It seems that this > > motivation is driven by the original ticket which had a lengthy > > discussion about GADTs. In my experience, the opposite is true, it is > > more common to have required constraints. > > > > This is true especially in a few common cases such as `pattern Foo = > > 27`, where users define pattern synonyms which have (overloaded) > > literals on the RHS. The most general signature for such a pattern is > > `pattern :: () => (Eq a, Num a) => a`. > > > > For this reason, I think it would be better if either > > > > 1. Only specifying one constraint corresponded to the required > constraints > > 2. We required users to specify both sets of constraints, even if the > > provided constraints are empty. > > > > In terms of breakage, I don't think that pattern synonym signatures > > are widely used yet. In both schemes it is possible to write backwards > > compatible code by writing both sets of constraints. > > > > I think a lot of the confusion also arises from the unusual form of > > the signature, it is unusual to specify two sets of constraints and I > > suspect users tends to assume that a single set of constraints is > > either provided or required depending on what they want it to mean. > > Forcing the specification of both, forces the user to make the > > distinction earlier rather than trying to decipher error messages. > > > > This is copied from a message sent to ghc-devs. This ticket is to track > the progress. New description: > I think that the current state of pattern synonym signatures is quite > confusing, especially regarding the constraints. For those unfamiliar, > a signature looks like the following, > > {{{ > pattern ExNumPat :: (Show b) => (Num a, Eq a) => b -> T a > }}} > > The first constraint being the "provided constraints" and the second > the "required constraints". > > My main concern is when only a single constraint is specified then > these are treated as the provided constraints. The manual gives the > reason that this is the "more common" choice. It seems that this > motivation is driven by the original ticket which had a lengthy > discussion about GADTs. In my experience, the opposite is true, it is > more common to have required constraints. > > This is true especially in a few common cases such as `pattern Foo = > 27`, where users define pattern synonyms which have (overloaded) > literals on the RHS. The most general signature for such a pattern is > `pattern :: () => (Eq a, Num a) => a`. > > For this reason, I think it would be better if either > > 1. Only specifying one constraint corresponded to the required constraints > 2. We required users to specify both sets of constraints, even if the provided constraints are empty. > > In terms of breakage, I don't think that pattern synonym signatures > are widely used yet. In both schemes it is possible to write backwards > compatible code by writing both sets of constraints. > > I think a lot of the confusion also arises from the unusual form of > the signature, it is unusual to specify two sets of constraints and I > suspect users tends to assume that a single set of constraints is > either provided or required depending on what they want it to mean. > Forcing the specification of both, forces the user to make the > distinction earlier rather than trying to decipher error messages. > This is copied from a message sent to ghc-devs. This ticket is to track the progress. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 10:51:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 10:51:34 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.354f3ede60242a1928d21ca5c9cd283d@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.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): -------------------------------------+------------------------------------- Comment (by simonpj): I'm ok with either (1) or (2). There is no technical issue here, it's just a question of what most people find most "natural". It'd be interesting to write a clear description of the three alternatives, and get people to vote (a little online survey). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 10:52:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 10:52:41 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.36ee9b4412d608cb34335c7b6cc46e8a@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.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): -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > > I think that the current state of pattern synonym signatures is quite > > confusing, especially regarding the constraints. For those unfamiliar, > > a signature looks like the following, > > > > {{{ > > pattern ExNumPat :: (Show b) => (Num a, Eq a) => b -> T a > > }}} > > > > The first constraint being the "provided constraints" and the second > > the "required constraints". > > > > My main concern is when only a single constraint is specified then > > these are treated as the provided constraints. The manual gives the > > reason that this is the "more common" choice. It seems that this > > motivation is driven by the original ticket which had a lengthy > > discussion about GADTs. In my experience, the opposite is true, it is > > more common to have required constraints. > > > > This is true especially in a few common cases such as `pattern Foo = > > 27`, where users define pattern synonyms which have (overloaded) > > literals on the RHS. The most general signature for such a pattern is > > `pattern :: () => (Eq a, Num a) => a`. > > > > For this reason, I think it would be better if either > > > > 1. Only specifying one constraint corresponded to the required > constraints > > 2. We required users to specify both sets of constraints, even if the > provided constraints are empty. > > > > In terms of breakage, I don't think that pattern synonym signatures > > are widely used yet. In both schemes it is possible to write backwards > > compatible code by writing both sets of constraints. > > > > I think a lot of the confusion also arises from the unusual form of > > the signature, it is unusual to specify two sets of constraints and I > > suspect users tends to assume that a single set of constraints is > > either provided or required depending on what they want it to mean. > > Forcing the specification of both, forces the user to make the > > distinction earlier rather than trying to decipher error messages. > > > > This is copied from a message sent to ghc-devs. This ticket is to track > the progress. New description: > I think that the current state of pattern synonym signatures is quite > confusing, especially regarding the constraints. For those unfamiliar, > a signature looks like the following, > > {{{ > pattern ExNumPat :: (Show b) => (Num a, Eq a) => b -> T a > }}} > > The first constraint being the "provided constraints" and the second > the "required constraints". > > My main concern is when only a single constraint is specified then > these are treated as the provided constraints. The manual gives the > reason that this is the "more common" choice. It seems that this > motivation is driven by the original ticket which had a lengthy > discussion about GADTs. In my experience, the opposite is true, it is > more common to have required constraints. > > This is true especially in a few common cases such as `pattern Foo = > 27`, where users define pattern synonyms which have (overloaded) > literals on the RHS. The most general signature for such a pattern is > `pattern :: () => (Eq a, Num a) => a`. > > For this reason, I think it would be better if either > > 1. Only specifying one constraint corresponded to the required constraints > 2. We required users to specify both sets of constraints, even if the provided constraints are empty. > > In terms of breakage, I don't think that pattern synonym signatures > are widely used yet. In both schemes it is possible to write backwards > compatible code by writing both sets of constraints. > > I think a lot of the confusion also arises from the unusual form of > the signature, it is unusual to specify two sets of constraints and I > suspect users tends to assume that a single set of constraints is > either provided or required depending on what they want it to mean. > Forcing the specification of both, forces the user to make the > distinction earlier rather than trying to decipher error messages. > This is copied from [https://mail.haskell.org/pipermail/ghc- devs/2015-October/010024.html a message sent to ghc-devs]. This ticket is to track the progress. But read the email thread for other comments! -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 12:01:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 12:01:56 -0000 Subject: [GHC] #10607: Auto derive from top to bottom In-Reply-To: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> References: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> Message-ID: <060.33bb6fcb0cdfb1ccb44cc9b122fcc99b@haskell.org> #10607: Auto derive from top to bottom -------------------------------------+------------------------------------- Reporter: songzh | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: deriving, | typeclass, auto Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:6 songzh]: > > 1. It forces me to use `KindSignatures`, `ConstraintKind` and other extension which should not be needed.(please see `TopDownDeriveTest.hs` file) Fair enough. But, in truth, you ''might'' need these extensions, depending on the definitions of types you are deriving for. One way forward here is to allow Template Haskell to turn on some extensions just within a splice, instead of specifying them at the top of a file. (This actually shouldn't be hard, once #10820 is complete.) > > 2. For type synonym, I want to do it without using TypeSynonymInstance, but I am not sure how to get the arity of a type constructor. For example: `type T a = (a,a,a,a,a)` I need to generate (Eq a , Eq b, Eq c ,Eq d, Eq e) => (a,b,c,d,e). However, the type synonym can be eta reduced, what should do to handle this case? I'm not sure what the problem is here. Are you worried about deriving, say, `Functor`, for which the eta reduction is necessary? But your example actually cannot be eta-reduced, because the variable `a` is used multiple times in the RHS. So I'm not sure what you're getting at on this one. > > 3. When I derive some instances that based on Generic class like Binary or FromJSON it gives me a type error: > > {{{ > Could not deduce (G.Generic a) > arising from a use of `binary-0.7.6.1:Data.Binary.Class.$gdmget' > from the context (B.Binary a) > bound by the instance declaration > }}} > > while I think `deriving instance (Binary a ,Binary b) => Binary (A a b)` should work fine. Why do I have to write `deriving instance (B.Binary a, G.Generic a) => (B.Binary (B a))`? And could you give me some suggestions to solve it. I'm a little lost here. What's the code being type-checked? What's `A`? What's `B`? Does the error happen both with and without TH? Or only when using TH? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 13:09:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 13:09:04 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.a3253b275894a5f3de48716d9deecdc0@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.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): -------------------------------------+------------------------------------- Comment (by goldfire): While we're tackling this problem, I'd like to repeat my arguments (made last round during the debate about this syntax) that we've gotten the order of the constraints wrong. Not less natural, but wrong. Consider this: {{{ data T a where MkT :: (Show a, Show b) => a -> b -> T a pattern P :: (Show a, Show b) => (Eq a, Num a) => b -> T a pattern P x = MkT 3 x foo :: T Int -> Bool foo (P _) = False }}} This code typechecks. But let's delve into that pattern type signature a bit. It has 4 parts: 1. The provided constraints: `(Show a, Show b)` 2. The required constraints: `(Eq a, Num a)` 3. The arguments: `b` 4. The result: `T a` Let's look, in particular, at the type variables here. Somewhat by definition, only the universal variables are mentioned in the result. Thus `a` is universal. Any other type variables are existential. Thus `b` is existential. Here is what is in scope in the 4 regions: 1. Provided: universals and existentials are in scope 2. Required: only universals are in scope 3. Arguments: universals and existentials are in scope 4. Result: only universals are in scope Look how the scoping rules flip-flop! Wait. What I've written is a lie. In GHC 7.10, the existentials ''are'' in scope in the required constraints. But this is hogwash. There's nothing at all useful that can be done by having a required constraint on an existential. Required constraints must be established before the pattern is matched. But existentials are available only after the match. Indeed, putting a `Read b` constraint in the required set makes `foo` fail to type-check. `b` should simply not be in scope for the required constraints. By reversing the order of provided/required, our scopes would nest. I would also support the following, verbose but clear syntax: {{{ pattern P :: { universals = [a] , existentials = [b] , provided = (Show a, Show b) , required = (Eq a, Num a) , arguments = [b] , result = T a } }}} The `provided`, `required`, etc, above are keywords, essentially, but they wouldn't clobber any existing syntax. We know precisely when we're parsing a pattern type signature. The only compulsory entry in there would be `result`. The `universals` and `existentials` are lists of type variable ''binders'', where we could assign kinds to the variables. These would be inferred, as usual, if they are omitted. (You might think we don't need to have binders anywhere, because we can always use a kind annotation on a usage of a variable to fix its kind. But this won't work in 8.0 for two reasons. 1) With visible type application, it would be nice to give an ordering to the variables, with universals always before existentials, and 2) when we have kind families, putting a kind family in a use site could be ambiguous, whereas it is unambiguous at a binding site.) This version has the considerable advantage of being easier to read and search for. It also means we could deprecate the current syntax for a cycle -- nothing would ''change'' in meaning. To be clear, I'm not 100% convinced that what I've suggested is an improvement, as it's quite verbose. But I'm reminded of one argument that came up during the role annotations debate that code is read much, much more often than it is written. Optimize for reading over writing! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 13:10:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 13:10:37 -0000 Subject: [GHC] #10607: Auto derive from top to bottom In-Reply-To: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> References: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> Message-ID: <060.a92e1d8d78dd634d7cce357912d79c74@haskell.org> #10607: Auto derive from top to bottom -------------------------------------+------------------------------------- Reporter: songzh | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: deriving, | typeclass, auto Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by goldfire): For point 3, could #10361 be related? I have a very strong suspicion that it is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 13:49:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 13:49:16 -0000 Subject: [GHC] #10933: REMOVED pragma Message-ID: <047.034826e24c434b8ddb0afbdd6905b9d3@haskell.org> #10933: REMOVED pragma -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- Say I have a function that's been deprecated for some time. Then I remove it. Some clients will still use the now-missing function. It would be nice to give a helpful error message, instead of a "symbol not found" error. I thus propose a `REMOVED` pragma. The syntax is identical to `DEPRECATED`, except for the name of the pragma. Whenever a `REMOVED` function is mentioned, the error message includes the string from the pragma. (This includes trying to define a `REMOVED` class method in an instance.) See Design/DeprecationMechanisms for more info and related efforts. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 15:24:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 15:24:39 -0000 Subject: [GHC] #1831: reify never provides the declaration of variables In-Reply-To: <044.a26292943bffdeb4bdb3ded03525ce1f@haskell.org> References: <044.a26292943bffdeb4bdb3ded03525ce1f@haskell.org> Message-ID: <059.610955c9e7c35c490f2ca1e2cb9e179e@haskell.org> #1831: reify never provides the declaration of variables -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.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): -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => newcomer Comment: It strikes me that this wouldn't actually be terribly hard to do. `INLINEABLE` identifiers have their unfoldings available. These unfoldings are expressed in Core. But it shouldn't be very hard to translate Core to the TH AST. Just looking at unfoldings would mean that this feature wouldn't work for identifiers declared in the same module as the `reify` but ''not'' declared `INLINEABLE` (or something that implies `INLINEABLE`). This would be disappointing to some people, I'm sure, but we can iteratively get better with this feature. I'll say this is appropriate for an ambitious newcomer. I don't think you'll have to know a ton about the internals of GHC, but it's way more than a few lines to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 15:45:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 15:45:14 -0000 Subject: [GHC] #8920: Alternative GADT syntax In-Reply-To: <044.aac5121bf5758b0193e2f09652955ddf@haskell.org> References: <044.aac5121bf5758b0193e2f09652955ddf@haskell.org> Message-ID: <059.f843570fa472bf6288b3d8acfe4de8a4@haskell.org> #8920: Alternative GADT syntax -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc2 (Parser) | Resolution: wontfix | Keywords: gadts Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => wontfix Comment: In the absence of a person willing to stand up and champion this, I'm closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 15:54:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 15:54:43 -0000 Subject: [GHC] #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression In-Reply-To: <045.67153471687796395f900337ba5220e7@haskell.org> References: <045.67153471687796395f900337ba5220e7@haskell.org> Message-ID: <060.a8df4c81dd12792ca6bfa8be7f33aabe@haskell.org> #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.8.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): -------------------------------------+------------------------------------- Comment (by RyanGlScott): One thing isn't clear to me about the changes proposed. We could certainly modify `dataToQa` so that `dataToExpQ` (and thus `liftData`) works with both function and constructor names. What about `dataToPatQ`, though? There's no way to pattern-match on an expression directly, so what would this translate to? {{{#!hs f :: Set Char -> Set Char f s@($(dataToPatQ (const Nothing) (fromList "test"))) = s }}} The only way I could envision this working is if it were translated to something like: {{{#!hs f :: Set Char -> Set Char f x | x == fromList "test" = x }}} which is reminiscent of how pattern-matching on literals works, I suppose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 17:27:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 17:27:03 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.c8e9098421fc52f679a6d06da291b4ff@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1284 -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:23 hvr]: > Somewhat related, #10930 wants GHC to at least emit a compiler warning in that case Ah, that's good to know. Perhaps we could add a similar warning for `[] :: NonEmpty` (when using `-XOverloadedLists`) in one of the phases of this proposal. While we're on this topic, I have another questions about things to come from the SMP (`Semigroup`?`Monoid` Proposal). Adding `Data.List.NonEmpty` brings in the `First`, `Last`, and `Option` data types, which are (intentionally) quite similar in behavior to `First` and `Last` (from `Data.Monoid`) and `Maybe`. Are there plans to consolidate (or strategically deprecate) some of these data types at some phase of the SMP? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 20:08:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 20:08:39 -0000 Subject: [GHC] #10934: Iface type variable out of scope Message-ID: <047.1cb3ee5ab1249c924fa43e250146dc6f@haskell.org> #10934: Iface type variable out of scope -------------------------------------+------------------------------------- Reporter: mjmrotek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: interface | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- I'm sorry for spamming code and not providing a distilled example, but honestly I have no idea how to even begin pinpointing this. I'm writing a library and hosting it on Github: https://github.com/marcinmrotek/pipes-key-value-csv which compiles fine, but when I try to compile the test suite, GHC crashes with this error message: {{{ /home/marcin/haskell/pipes-key-value-csv/.stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Pipes/KeyValueCsv/Internal/KeyValue.hi Declaration for $fFromKeyValuesf:3: Iface type variable out of scope: k Cannot continue after interface file error }}} when I uncomment the {{{#!hs . KV.foldHeader }}} line in https://github.com/marcinmrotek/pipes-key-value- csv/blob/master/test/Test/KeyValue.hs The thing is, this function does not even use the "FromKeyValues" type class mentioned - https://github.com/marcinmrotek/pipes-key-value- csv/blob/master/src/Pipes/KeyValueCsv/Internal/KeyValue.hs KV.parseLine, which does, compiles fine (the test suite runs and fails with "Prelude: undefined". They're both defined here: https://github.com/marcinmrotek/pipes-key-value- csv/blob/master/src/Pipes/KeyValueCsv/KeyValue.hs I've tried "stack clean", reinstalling both GHC and stack, installing my package globally with cabal-install (although I had to fix the validation-0.5.1 package by removing the Safe pragma; I've tried to use stack again, pointing it to the exact same code for validation-0.5.1, to no avail), the result is always the same - the library compiles, the test suite doesn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 20:47:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 20:47:46 -0000 Subject: [GHC] #10934: Iface type variable out of scope In-Reply-To: <047.1cb3ee5ab1249c924fa43e250146dc6f@haskell.org> References: <047.1cb3ee5ab1249c924fa43e250146dc6f@haskell.org> Message-ID: <062.6868195959f4bec1499cb29aa129f0be@haskell.org> #10934: Iface type variable out of scope -------------------------------------+------------------------------------- Reporter: mjmrotek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: interface Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by thomie): Similar bugs were closed because of lack of reproducability (#9584, #7958), but I can reproduce your problem. * clone https://github.com/marcinmrotek/pipes-key-value-csv at commit 5719db5cc7eeecf2a0690ca5627ae6bd9500280c * uncommented the line `-- . KV.foldHeader` in `test/Test/KeyValue.hs` * `cabal install --dependencies-only` * `cabal test` I used the following tools: * ghc-7.10.2 * cabal-install version 1.22.6.0 * version 1.22.4.0 of the Cabal library * packages from http://www.stackage.org/snapshot/lts-3.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 5 21:52:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Oct 2015 21:52:37 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.75b921bb810c686cf685fef06e141f08@haskell.org> #10375: arm: ghci hits an illegal instruction --------------------------------------------+------------------------------ Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System (Linker) | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): --------------------------------------------+------------------------------ Comment (by erikd): Tried once again to debug this using GDB. {{{ $ gdb --args inplace/bin/ghc-stage2 +RTS -V0 -RTS --interactive (gdb) break main (gdb) break main Breakpoint 1 at 0x93cd8 (gdb) r Starting program: /home/erikd/Git/ghc-upstream/inplace/lib/bin/ghc-stage2 -B/home/erikd/Git/ghc-upstream/inplace/lib +RTS -V0 -RTS --interactive [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux- gnueabihf/libthread_db.so.1". Breakpoint 1, 0x00093cd8 in main () (gdb) while 1 >x/i $pc >stepi >end }}} and it crashes in a at least 3 or 4 different ways on different runs, none of them even remotely like the way it crashes outside GDB. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 00:14:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 00:14:09 -0000 Subject: [GHC] #10934: Iface type variable out of scope In-Reply-To: <047.1cb3ee5ab1249c924fa43e250146dc6f@haskell.org> References: <047.1cb3ee5ab1249c924fa43e250146dc6f@haskell.org> Message-ID: <062.85e4353cd55042a89568063291cc3b48@haskell.org> #10934: Iface type variable out of scope -------------------------------------+------------------------------------- Reporter: mjmrotek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: interface Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * Attachment "keyvalue.cabal" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 00:14:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 00:14:19 -0000 Subject: [GHC] #10934: Iface type variable out of scope In-Reply-To: <047.1cb3ee5ab1249c924fa43e250146dc6f@haskell.org> References: <047.1cb3ee5ab1249c924fa43e250146dc6f@haskell.org> Message-ID: <062.f6661fc84960c985ef1d0fe2e1e508c7@haskell.org> #10934: Iface type variable out of scope -------------------------------------+------------------------------------- Reporter: mjmrotek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: interface Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * Attachment "KeyValue.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 00:14:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 00:14:30 -0000 Subject: [GHC] #10934: Iface type variable out of scope In-Reply-To: <047.1cb3ee5ab1249c924fa43e250146dc6f@haskell.org> References: <047.1cb3ee5ab1249c924fa43e250146dc6f@haskell.org> Message-ID: <062.27ecf95d601d2583a51fea00b995087e@haskell.org> #10934: Iface type variable out of scope -------------------------------------+------------------------------------- Reporter: mjmrotek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: interface Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * Attachment "Vinyl.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 00:14:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 00:14:41 -0000 Subject: [GHC] #10934: Iface type variable out of scope In-Reply-To: <047.1cb3ee5ab1249c924fa43e250146dc6f@haskell.org> References: <047.1cb3ee5ab1249c924fa43e250146dc6f@haskell.org> Message-ID: <062.9f0f6e816cac9d1a4695452dc9fdd781@haskell.org> #10934: Iface type variable out of scope -------------------------------------+------------------------------------- Reporter: mjmrotek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: interface Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * Attachment "T10934.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 00:17:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 00:17:13 -0000 Subject: [GHC] #10934: Iface type variable out of scope In-Reply-To: <047.1cb3ee5ab1249c924fa43e250146dc6f@haskell.org> References: <047.1cb3ee5ab1249c924fa43e250146dc6f@haskell.org> Message-ID: <062.d56f0a58ddd30d5ad019d3ff5777c473@haskell.org> #10934: Iface type variable out of scope -------------------------------------+------------------------------------- Reporter: mjmrotek | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: interface Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * priority: normal => high Comment: Reproducible with HEAD (ghc-7.11.20151002), see attachments. The cabal file doesn't pull in any dependencies. {{{ $ cabal configure ... $ cabal build Building keyvalue-0.0.0.0... Preprocessing library keyvalue-0.0.0.0... [1 of 2] Compiling Vinyl ( Vinyl.hs, dist/build/Vinyl.o ) [2 of 2] Compiling KeyValue ( KeyValue.hs, dist/build/KeyValue.o ) In-place registering keyvalue-0.0.0.0... $ ghc -package-db dist/package.conf.inplace -O -fforce-recomp -c T10934.hs /home/thomas/T10934/dist/build/KeyValue.hi Declaration for missing1: Iface type variable out of scope: k Cannot continue after interface file error }}} Note that the cabal build step is needed to trigger the bug. Running `ghc --make -O -outputdir=/tmp -fforce-recomp T10934.hs` works fine. Compiling `KeyValue.hs` with `-dcore-lint` results in Core Lint errors: {{{ $ ghc -O -outputdir=/tmp -dcore-lint -fforce-recomp KeyValue.hs [1 of 2] Compiling Vinyl ( Vinyl.hs, /tmp/Vinyl.o ) [2 of 2] Compiling KeyValue ( KeyValue.hs, /tmp/KeyValue.o ) *** Core Lint errors : in result of Simplifier *** KeyValue.hs:20:19: Warning: [in body of lambda with binder f_aBJ :: k_aBI -> *] @ (k_aBI :: BOX) is out of scope }}} Commenting out the `PolyKinds` extension in `KeyValue.hs` makes the bug go away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 02:16:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 02:16:13 -0000 Subject: [GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code In-Reply-To: <043.972d3170891da80a4e96bca7b675a836@haskell.org> References: <043.972d3170891da80a4e96bca7b675a836@haskell.org> Message-ID: <058.8f669c88c9d3b7ec37545cf1da4baad1@haskell.org> #10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: driver/T8101b Blocked By: | Blocking: Related Tickets: #8101 | Differential Rev(s): Phab:D1278 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"427f8a15c385de486d479989ecfbb6f82699f405/ghc" 427f8a15/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="427f8a15c385de486d479989ecfbb6f82699f405" Deduplicate one-shot/make compile paths. Summary: We had a duplicate copy of the code for --make and for -c which was a pain. The call graph looked something like this: compileOne -> genericHscCompileGetFrontendResult -> genericHscFrontend hscCompileOneShot ---^ with genericHscCompileGetFrontendResult and hscCompileOneShot duplicating logic for deciding whether or not recompilation was needed. This patchset fixes it, so now everything goes through this call-chain: compileOne (--make entry point) Calls hscIncrementCompile, invokes the pipeline to do codegen and sets up linkables. hscIncrementalCompile (-c entry point) Calls hscIncrementalFrontend, and then simplifying, desugaring, and writing out the interface. hscIncrementalFrontend Performs recompilation avoidance, if recompilation needed, does parses typechecking. I also cleaned up some of the MergeBoot nonsense by introducing a FrontendResult type. NB: this BREAKS #8101 again, because I can't unconditionally desugar due to Haddock barfing on lint, see #10600 Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, bgamari, simonmar, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1302 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 02:16:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 02:16:13 -0000 Subject: [GHC] #8101: No pattern match non-exhaustiveness warnings when compiling with -fno-code In-Reply-To: <044.dfa43534fecae23d8d03f05e2e6d901b@haskell.org> References: <044.dfa43534fecae23d8d03f05e2e6d901b@haskell.org> Message-ID: <059.b31b08597a4b83982c7cee7e35f804b1@haskell.org> #8101: No pattern match non-exhaustiveness warnings when compiling with -fno-code -------------------------------------+------------------------------------- Reporter: exbb2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: T8101 Blocked By: | Blocking: Related Tickets: #10600 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"427f8a15c385de486d479989ecfbb6f82699f405/ghc" 427f8a15/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="427f8a15c385de486d479989ecfbb6f82699f405" Deduplicate one-shot/make compile paths. Summary: We had a duplicate copy of the code for --make and for -c which was a pain. The call graph looked something like this: compileOne -> genericHscCompileGetFrontendResult -> genericHscFrontend hscCompileOneShot ---^ with genericHscCompileGetFrontendResult and hscCompileOneShot duplicating logic for deciding whether or not recompilation was needed. This patchset fixes it, so now everything goes through this call-chain: compileOne (--make entry point) Calls hscIncrementCompile, invokes the pipeline to do codegen and sets up linkables. hscIncrementalCompile (-c entry point) Calls hscIncrementalFrontend, and then simplifying, desugaring, and writing out the interface. hscIncrementalFrontend Performs recompilation avoidance, if recompilation needed, does parses typechecking. I also cleaned up some of the MergeBoot nonsense by introducing a FrontendResult type. NB: this BREAKS #8101 again, because I can't unconditionally desugar due to Haddock barfing on lint, see #10600 Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, bgamari, simonmar, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1302 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 05:56:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 05:56:50 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.a3f3363fa515b1c8a6396356847a43b1@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1259 -------------------------------------+------------------------------------- Comment (by gridaphobe): Thanks, that makes sense. I see two ways to think about this: 1. The real problem is the interaction between `INLINE` and the invisible CallStacks. Normally the programmer can see the entire definition that would be inlined because he just wrote it. So GHC can expect the programmer to make an informed decision about whether a given definition should be unconditionally inlined. CallStacks change this because they're invisible to the programmer, GHC inserts them automatically. Worse, they're a sizeable datatype containing three Strings per call-site. For example, a simple call to `error` goes from the source-level {{{ error "bad" }}} to something like {{{ error [("error", SrcLoc 1 1 1 8 "file.hs" "Main")] "bad" }}} We can't reasonably expect programmers to account for such invisible expressions when deciding whether to add an `INLINE` pragma. So perhaps a reasonable principle would be that '''GHC should not inline terms that the programmer did not write'''. At the moment I think this would only apply to CallStacks and dictionaries, but dictionaries are already top-level values so they shouldn't be dragged along the way CallStacks are. 2. Perhaps inlining the code to build the CallStack is not so bad (I don't really know how to judge that), but the real problem is inlining the three string literals. It does seem quite silly to inline string literals, why should we need more than one copy? GHC already floats string literals to top-level binders, but it doesn't know that it can reuse literals from imported modules. In this case the principle would be that '''there should only be one copy of any given string literal''' (per package?). So perhaps a Module could export a list of all string literals it allocated. Then a final simplification pass could replace literals with references to the literals that were already allocated in imported modules. This would leave the unfoldings unchanged and should not affect any opportunities for optimization, while still allowing us to clean up after the inliner. These both seem like reasonable principles to me, but only the second would help with my callstack-free example in comment:9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 08:21:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 08:21:02 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.f9c39fb1ad4b880f8fb69f7d0beac03e@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1259 -------------------------------------+------------------------------------- Comment (by simonpj): I think that (2) in comment:11 seems right to me. One path would be to adjust `FloatOut` so that * it picks up string literals; but remember that these "string literals" actually look like `(unpackCString# "foo"#)`. * (more invasively) it looks inside INLINE unfoldings, but in string- literal-only mode. That seems quite complicated. Another path is along the lines of your earlier patch: make the desugarer bind all string literals at top level in the first place. That way they'll be shared from birth. On the whole that sounds like an easier path to me. Particularly as the desugarer already uses a monadic function `mkStringExprFS` to make a new string literal, so you can make a desugarer-specific version of it which tosses a global binding into the monad. We'd need an extra bunch of monad-carried top-level bindings in the desugarer, but that is probably useful anyway. (It doesn't need to be string-specific.) Of course this would mean that, as Joachim points out (comment:10) that we wouldn't INLINE exactly what the programmer wrote: we'd share the string literal instead of copying it. But I think we should be able to guarantee that the effect is the same, provided we add a CONLIKE pragma to `unpackCSTring#`. (When doing this step, do some perf tests to check what happens.) This is all closely related to #8472, although it concerned unboxed string literals. There's a concrete proposal there, which would be good to execute on. In short, now we are focusing on string literals rather than call stacks, I agree that doing some extra work in the desugarer is probably the best path. BTW #5218 is in the same general area! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 08:48:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 08:48:27 -0000 Subject: [GHC] #10934: Iface type variable out of scope In-Reply-To: <047.1cb3ee5ab1249c924fa43e250146dc6f@haskell.org> References: <047.1cb3ee5ab1249c924fa43e250146dc6f@haskell.org> Message-ID: <062.45f899ead6f2a09bf740d96045bf7fc3@haskell.org> #10934: Iface type variable out of scope -------------------------------------+------------------------------------- Reporter: mjmrotek | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: interface Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by simonpj): Very good! Patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 10:38:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 10:38:17 -0000 Subject: [GHC] #10934: Iface type variable out of scope In-Reply-To: <047.1cb3ee5ab1249c924fa43e250146dc6f@haskell.org> References: <047.1cb3ee5ab1249c924fa43e250146dc6f@haskell.org> Message-ID: <062.de956e7a9b1c7c2a7555e389856b2e3c@haskell.org> #10934: Iface type variable out of scope -------------------------------------+------------------------------------- Reporter: mjmrotek | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: interface Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0e169a8b2b672ca95aad72511865c0b3fca458d3/ghc" 0e169a8b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0e169a8b2b672ca95aad72511865c0b3fca458d3" Fix kind-var abstraction in SimplUtils.abstractFloats A missing 'closeOverKinds' triggered Trac #10934. Happily the fix is simple. Merge to 7.10.3 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 10:40:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 10:40:09 -0000 Subject: [GHC] #10934: Iface type variable out of scope In-Reply-To: <047.1cb3ee5ab1249c924fa43e250146dc6f@haskell.org> References: <047.1cb3ee5ab1249c924fa43e250146dc6f@haskell.org> Message-ID: <062.0c45edb0fc217b68d046d12f66f942ca@haskell.org> #10934: Iface type variable out of scope -------------------------------------+------------------------------------- Reporter: mjmrotek | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: interface Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | polykinds/T10934 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => polykinds/T10934 * milestone: => 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 10:44:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 10:44:35 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.b689527071b475331f5dbb3644022327@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.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): -------------------------------------+------------------------------------- Comment (by simonpj): * I do agree about switching the order of provided and required constraints. Let's just do that for GHC 8.0. This isn't yet a widely- used feature, so lets' fix it asap. * We should definitely complain if the existentials are used by required constraints. That's a bug to fix. * I'm much less certain about Richard's proposed syntax. Not dead set against but we could get on with the first two while debating the third. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 10:47:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 10:47:23 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.d8f1f4168cca2d8156e7ed9e503c603e@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation | fault, segfault, long input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1180 -------------------------------------+------------------------------------- Changes (by bgamari): * owner: bgamari => Comment: I fixed the compile-time check; leaving the proper RTS fix for someone else. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 10:51:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 10:51:31 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.4663f1f46607a62e60008f333f1fad5a@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.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): -------------------------------------+------------------------------------- Changes (by mpickering): * cc: ekmett, dreixel (added) Comment: Adding Edward and Pedro as they are the only two other authors to (publicly) use them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 10:55:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 10:55:47 -0000 Subject: [GHC] #10817: Looping default associated type family without UndecidableInstances In-Reply-To: <047.64ffaf6cb4d5ab1829ed952b25df0d19@haskell.org> References: <047.64ffaf6cb4d5ab1829ed952b25df0d19@haskell.org> Message-ID: <062.cda9d95d360483f6b5a7271a36703249@haskell.org> #10817: Looping default associated type family without UndecidableInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_fail/T10817 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1262 -------------------------------------+------------------------------------- Comment (by bgamari): goldfire, do you suppose you could backport this to `ghc-7.10`? I tried but there have been just enough differences in this area that I'm not sure I trust myself to get this right. Alternatively we could just punt. Your call. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 11:32:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 11:32:56 -0000 Subject: [GHC] #10845: Incorrect behavior when let binding implicit CallStack object In-Reply-To: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> References: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> Message-ID: <068.f1f40ec708ff2174b6eef718e1cd2fb5@haskell.org> #10845: Incorrect behavior when let binding implicit CallStack object -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10846 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by simonpj): There are several things going on here. First, let's just note that none of this arises if we have `MonoLocalBinds`, which is what happens if you have GADTs etc. Second, we have this magic rule that `CallStack` constraints can be spontaneously solved by the solver. This is an ad-hoc rule that means we don't gratuitously infer top-level types like `f :: (?x :: CallStack) => blah`. **But it should really only apply at top level.** For nested let- bindings I think it'd be fine to abstract. So in the "spontaneous solve" code in `TcInteract.interactDict` we can make it conditional on the `tc_lvl` being 3. (Sorry about the 3; I'm committing a new `Note [TcLevel assignment]` in `TcType` to explain. There should be a definition `topImplicationTcLevel = 3` alongside `topTcLevel = 1`.) Third, I think that if `MonoLocalBinds` is off, then we do want to generalise over `CallStack` constraints, just like any other implicit parameter. Consider {{{ f :: (?loc :: CallStack) => blah f x = let g y = ...error "foo".... in ...(g x) ... (g v) ... }}} Now, if `g` fails, calling `error`, surely you'd like to see which of `g`'s call sites was implicated? So we'd expect `g` to get an inferred type {{{ g :: (?loc :: CallStack) => something }}} Does it make a difference if `g` has no arguments? Well, the monomorphism restriction says we won't quantify over any constraints, so yes, it makes a difference. Fourth you seems to want to treat `getCallStack` specially, which I am doubtful about. In the above example `g`'s RHS has a call to `error`, but it should not behave any differently if it had a call to `getCallStack` instead. The latter is just another ordinary function with a `(?x :: CallStack)` constraint. Bottom line: I think that all we need do is suppress the spontaneous-solve code for `CallStack` if we are not at top level. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 12:10:07 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 12:10:07 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.cf156b4aa86497d47d846da2779f5bf6@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 5321 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by bgamari): Finally have a chance to look at this. In particular I'll be looking at the `b a` case identified in comment:6 as still being slow. For the record `runghc Types.hs 5 b a` produces output of the form, {{{#!hs {-# LANGUAGE TypeOperators,DataKinds,KindSignatures,TypeFamilies,PolyKinds,UndecidableInstances #-} import GHC.TypeLits data Nat1 = Zero | Succ Nat1 type family Replicate1 (n :: Nat1) (x::a) :: [a] type instance Replicate1 n x = Replicate1' '[] n x type family Replicate1' (acc::[a]) (n :: Nat1) (x::a) :: [a] type instance Replicate1' acc Zero x = acc type instance Replicate1' acc (Succ n) x = Replicate1' (x ': acc) n x class Class a where f :: a -> a data Data (xs::a) = X | Y deriving (Read,Show) main = print test1 -- The numeric parameter adjusts this -- This definition is inlined in the actual output type N = Succ (Succ (Succ (Succ (Succ Zero))) instance (xs ~ Replicate1 N ()) => Class (Data xs) where f X = Y f Y = X test1 = f (X :: Data (Replicate1 N () )) }}} In particular the numeric parameter to `Test` is adjusting `N`. In the case of `N=500` compile-time is quite bad indeed, {{{ $ ./Types 500 b a >| test.hs && time ghc test.hs -freduction-depth=0 -dshow-passes Glasgow Haskell Compiler, Version 7.11.20151006, stage 2 booted by GHC version 7.10.2 ... *** Chasing dependencies: Chasing modules from: *test.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2015-10-06 11:44:53.905638216 UTC ms_mod = Main, ms_textual_imps = [import (implicit) Prelude, import GHC.TypeLits] ms_srcimps = [] }] *** Deleting temp files: compile: input file test.hs Created temporary directory: /tmp/ghc27682_0 *** Checking old interface for Main: [1 of 1] Compiling Main ( test.hs, test.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 103, types: 11,779, coercions: 509,036} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 107, types: 7,294, coercions: 516} Result size of Simplifier = {terms: 107, types: 7,294, coercions: 516} *** Tidy Core: Result size of Tidy Core = {terms: 111, types: 7,302, coercions: 518} *** CorePrep: Result size of CorePrep = {terms: 152, types: 7,880, coercions: 518} *** Stg2Stg: *** CodeGen: *** Assembler: Upsweep completely successful. *** Deleting temp files: Warning: deleting non-existent /tmp/ghc27682_0/ghc_3.c Warning: deleting non-existent /tmp/ghc27682_0/ghc_1.s Linking test ... *** C Compiler: *** C Compiler: *** Linker: *** Deleting temp files: *** Deleting temp dirs: real 0m22.835s user 0m22.514s sys 0m0.315s }}} It appears that the desugaring pass ends up producing a number of coercions quadratic in the number of depth of the equality in the context result (with almost all being eliminated during simplification), ||= input =||= terms =||= types =||= coercions =|| || 400 b a || 103 || 9479 || 327236 || || 200 b a || 103 || 4879 || 83636 || || 100 b a || 103 || 2579 || 21836 || || 50 b a || 103 || 1429 || 5936 || || 2 b a || 103 || 325 || 80 || Looking at the output from desugaring, it seems that the only definition which is growing non-linearly is `main` itself, where indeed we find a chain of quadratically growing coercions. For instance, in the case of `N=3` we have, {{{#!hs -- RHS size: {terms: 6, types: 85, coercions: 102} main :: IO () [LclIdX, Str=DmdType] main = print @ (Data '[(), (), ()]) (Main.$fShowData @ [*] @ '[(), (), ()]) (f @ (Data '[(), (), ()]) (Main.$fClassData @ '[(), (), ()] (Eq# @ [*] @ '[(), (), ()] @ (Replicate1 ('Succ ('Succ ('Succ 'Zero))) ()) @~ (Sym (Main.TFCo:R:Replicate1'kaccZerox[0] <*>_N <'[(), (), ()]>_N <()>_N) ; Sym (Main.TFCo:R:Replicate1'kaccSuccx[0] <*>_N <'[(), ()]>_N <'Zero>_N <()>_N) ; Sym (Main.TFCo:R:Replicate1'kaccSuccx[0] <*>_N <'[()]>_N <'Succ 'Zero>_N <()>_N) ; Sym (Main.TFCo:R:Replicate1'kaccSuccx[0] <*>_N <'[]>_N <'Succ ('Succ 'Zero)>_N <()>_N) ; Sym (Main.TFCo:R:Replicate1knx[0] <*>_N <'Succ ('Succ ('Succ 'Zero))>_N <()>_N) :: '[(), (), ()] ~# Replicate1 ('Succ ('Succ ('Succ 'Zero))) ()))) (((Main.X @ [*] @ '[(), (), ()]) `cast` ((Data (UnivCo opt_phantom phantom '[(), (), ()] (Replicate1 ('Succ ('Succ ('Succ 'Zero))) ())))_R :: Data '[(), (), ()] ~R# Data (Replicate1 ('Succ ('Succ ('Succ 'Zero))) ()))) `cast` ((Data (UnivCo opt_phantom phantom (Replicate1 ('Succ ('Succ ('Succ 'Zero))) ()) '[(), (), ()]))_R :: Data (Replicate1 ('Succ ('Succ ('Succ 'Zero))) ()) ~R# Data '[(), (), ()]))) }}} More analysis to follow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 12:11:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 12:11:30 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.438b081af8221d05398f075e64dd7112@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.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): -------------------------------------+------------------------------------- Comment (by goldfire): I won't champion the verbose syntax, as I'm deeply unsure of that myself. But I wanted to see what a verbose syntax might look like, in case someone else wants to run with it. I'm quite happy with comment:6. We should also include point (1) or (2) from the original post. I favor (1) by a tiny bit, but perhaps only because it's sunny out this morning. It's hard for me to choose there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 12:16:29 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 12:16:29 -0000 Subject: [GHC] #10817: Looping default associated type family without UndecidableInstances In-Reply-To: <047.64ffaf6cb4d5ab1829ed952b25df0d19@haskell.org> References: <047.64ffaf6cb4d5ab1829ed952b25df0d19@haskell.org> Message-ID: <062.7fedb6e226cd6c6364a26f2408dc4453@haskell.org> #10817: Looping default associated type family without UndecidableInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_fail/T10817 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1262 -------------------------------------+------------------------------------- Comment (by goldfire): I'll take a look at this today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 12:26:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 12:26:38 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.092b7583b4c1c433e2341840ecd99083@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 5321 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by goldfire): The blowup in coercions is fixed in the simplifier, yes? That means that coercion optimization is working. When you vary `N`, what changes in the output? The long sequence of coercions in the middle of that dump looks correct to me. I'm less sure about the two casts at the end. The unoptimized Core term for this program may truly grow quadratically. Maybe the solution is to be more eager with the coercion optimizer? I don't see any harm in doing so, if we can observe a speedup. Let me know if I can be of further assistance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 12:28:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 12:28:06 -0000 Subject: [GHC] #10931: layers-0.1 does not compile with ghc-7.10 (likely a regression from ghc-7.8) In-Reply-To: <045.19b8056b1d70bf96a656ae7348a956cb@haskell.org> References: <045.19b8056b1d70bf96a656ae7348a956cb@haskell.org> Message-ID: <060.61958faac0609fcd6b63c1c54eb8778d@haskell.org> #10931: layers-0.1 does not compile with ghc-7.10 (likely a regression from ghc-7.8) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by simonpj): * cc: goldfire (added) Comment: Thanks for a small test case. I've added a test so if this goes wrong again we'll know. I have not investigated in detail. Would someone like to git-bisect to find when it got fixed? I have a horrid feeling that it'll just be part of some fairly substantial change to the type constraint solver, which we won't want to merge en-masse to 7.10.3. As things stand, it's a bug in 7.10 that we don't know how to fix. I'm sure we could find out, but it'd take precious cycles. How bad is it if this library doesn't work? I imagine this is relatively rare else it'd show up more often. Richard; you might be interested. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 12:29:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 12:29:28 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.b790db2d5a8c06b176fc80fdb3e4f650@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 5321 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by simonpj): > Maybe the solution is to be more eager with the coercion optimizer? I don't think so. If the type checker generates a term of quadratic size, it'll take at least quadratic time to generate, and quadratic time to optimise. We should look into why it gets so big in the first place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 12:56:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 12:56:37 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.327b3025c7154316da46ef8608c3d7a6@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.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): -------------------------------------+------------------------------------- Comment (by rwbarton): One thing that bothers me about the current syntax is that `C1 a => C2 a => T a` in general already has a meaning. It's the same thing as `(C1 a, C2 a) => T a`. I don't know if this is actually valid Haskell 98 (I suspect not), but GHC accepts it without any language flags. Just to throw out another option, long ago user "ski" on IRC suggested a syntax for existentials-plus-constraints, dual to constrained polymorphic values. The idea is dual to {{{ forall a. C a => T a }}} which is a sort of function that accepts a `C a` constraint and produces a value, we have {{{ exists a. C a *> T a }}} which is a sort of pair of a `C a` constraint (dictionary) and a value. (Mnemonic: `*` is like a pair and `>` is from `=>`. Not sure I am convinced myself.) I'm not sure whether this applies directly to pattern synonyms since a pattern is not really the same thing as a value. But, we could at least use the idea of two different bits of syntax for provided and required constraints, e.g., {{{ pattern P :: (Eq a, Num a) => (Show a, Show b) *> b -> T a }}} Here I am thinking of `(Eq a, Num a)` as in negative position and `(Show a, Show b)` in positive position, so tentatively using the corresponding `=>` and `*>`. Advantages: * Does not use syntax that already has another meaning (`C1 a => C2 a => T a`) * You can write patterns with either empty required constraints or empty provided constraints (`Cr a => T a`, `Cp a *> T a`) without having to add an empty context * Not extremely verbose like Richard's verbose syntax Disadvantages: * Another funny bit of syntax to learn. But at least it appears in only one context. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 13:01:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 13:01:39 -0000 Subject: [GHC] #10913: deprecate and then remove -fwarn-hi-shadowing In-Reply-To: <043.5271c7f4effd317ccfe2016268f0bde8@haskell.org> References: <043.5271c7f4effd317ccfe2016268f0bde8@haskell.org> Message-ID: <058.dd994b7f051c3474ca03dd0cac3a42b3@haskell.org> #10913: deprecate and then remove -fwarn-hi-shadowing -------------------------------------+------------------------------------- Reporter: osa1 | Owner: ChrisU Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.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): -------------------------------------+------------------------------------- Comment (by osa1): We should either implement or remove it, leaving it there unimplemented is the worst case, because it has an entry in user manual and man page etc. and users may expect it to work while it silently does nothing. Since nobody complained in 9 years, I say let's remove it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 13:09:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 13:09:50 -0000 Subject: [GHC] #10935: More unused and non-deprecated warning flags Message-ID: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> #10935: More unused and non-deprecated warning flags -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10752 Differential Rev(s): | -------------------------------------+------------------------------------- For #10752 I was looking at some warning generation code, and I realized that these flags are not doing anything right now, but they're not deprecated: - -fwarn-tabs - -fwarn-monomorphism-restriction - -fwarn-unrecognised-pragmas This one is not even shown in user manual or man page: - Opt_WarnAlternativeLayoutRileTransitional We should probably deprecate and remove them. Another thing is that we should probably remove -fwarn-amp in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 13:36:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 13:36:34 -0000 Subject: [GHC] #10935: More unused and non-deprecated warning flags In-Reply-To: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> References: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> Message-ID: <058.8dcc0b5e305a82db7fe0fb68f46151ec@haskell.org> #10935: More unused and non-deprecated warning flags -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10752 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by osa1): EDIT: It seems like I forgot to search in the lexer. Current status: - -fwarn-monomorphism-restriction is unused. - -fwarn-alternative-layout-rule-transitional is used in the lexer but not documented anywhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 14:08:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 14:08:32 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.d157715dc86c7d04ad4c023d507ed7d3@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10528 | Differential Rev(s): Phab:D1246 -------------------------------------+------------------------------------- Comment (by bgamari): Any updates on this, Andrew? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 14:12:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 14:12:14 -0000 Subject: [GHC] #10931: layers-0.1 does not compile with ghc-7.10 (likely a regression from ghc-7.8) In-Reply-To: <045.19b8056b1d70bf96a656ae7348a956cb@haskell.org> References: <045.19b8056b1d70bf96a656ae7348a956cb@haskell.org> Message-ID: <060.ae29e2c78a3d21ac477026a652601a3a@haskell.org> #10931: layers-0.1 does not compile with ghc-7.10 (likely a regression from ghc-7.8) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by goldfire): This seems to have many of the same elements to #10009, which indeed cannot be merged. Are there known workarounds to #10009? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 14:12:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 14:12:43 -0000 Subject: [GHC] #10594: the ghc-7.10.1-x86_64-apple-darwin.tar.bz2 doesn't install /sw/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3/GHC In-Reply-To: <046.69b85de5f279bc6fd8a3f5ec62466a80@haskell.org> References: <046.69b85de5f279bc6fd8a3f5ec62466a80@haskell.org> Message-ID: <061.abb55033fbe455cca3deb7c3c308c3f7@haskell.org> #10594: the ghc-7.10.1-x86_64-apple-darwin.tar.bz2 doesn't install /sw/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3/GHC -------------------------------------+------------------------------------- Reporter: howarth | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Using the ghc-7.10.1-x86_64-apple-darwin.tar.bz2 binary release to > install ghc 7.10.1 with... > > ./configure --prefix=/sw > make DESTDIR=/sw install > > fails to install a populated > /sw/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3/GHC subdirectory causing > builds of ghc packages with gcc-prim dependencies to fail. The only non- > documentation files installed are... > > -rwxr-xr-x root/admin 647620 2015-07-01 13:20 > ./sw/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3/libHSghc- > prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3-ghc7.10.1.dylib > -rw-r--r-- root/admin 1326504 2015-07-01 13:20 > ./sw/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3/libHSghc- > prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3.a > -rw-r--r-- root/admin 814 2015-07-01 13:20 > ./sw/lib/ghc-7.10.1/package.conf.d/ghc- > prim-0.4.0.0-7c945cc0c41d3b7b70f3edd125671166.conf > > This compares to the same installation of the ghc-7.8.3-x86_64-apple- > darwin.tar.bz2 binary release which does install the required files as... > > drwxr-xr-x root/admin 0 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/ > drwxr-xr-x root/admin 0 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/ > -rw-r--r-- root/admin 373897 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/Classes.dyn_hi > -rw-r--r-- root/admin 373885 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/Classes.hi > -rw-r--r-- root/admin 373889 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/Classes.p_hi > -rw-r--r-- root/admin 2661 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/CString.dyn_hi > -rw-r--r-- root/admin 2649 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/CString.hi > -rw-r--r-- root/admin 2653 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/CString.p_hi > -rw-r--r-- root/admin 1940 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/Debug.dyn_hi > -rw-r--r-- root/admin 1928 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/Debug.hi > -rw-r--r-- root/admin 1932 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/Debug.p_hi > -rw-r--r-- root/admin 942 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/IntWord64.dyn_hi > -rw-r--r-- root/admin 930 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/IntWord64.hi > -rw-r--r-- root/admin 934 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/IntWord64.p_hi > -rw-r--r-- root/admin 388 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/Magic.dyn_hi > -rw-r--r-- root/admin 376 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/Magic.hi > -rw-r--r-- root/admin 380 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/Magic.p_hi > -rw-r--r-- root/admin 50032 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/PrimopWrappers.dyn_hi > -rw-r--r-- root/admin 50020 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/PrimopWrappers.hi > -rw-r--r-- root/admin 50024 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/PrimopWrappers.p_hi > -rw-r--r-- root/admin 1100 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/Tuple.dyn_hi > -rw-r--r-- root/admin 1088 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/Tuple.hi > -rw-r--r-- root/admin 1092 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/Tuple.p_hi > -rw-r--r-- root/admin 939 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/Types.dyn_hi > -rw-r--r-- root/admin 927 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/Types.hi > -rw-r--r-- root/admin 931 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/GHC/Types.p_hi > -rwxr-xr-x root/admin 631192 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/libHSghc-prim-0.3.1.0-ghc7.8.3.dylib > -rw-r--r-- root/admin 792352 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/libHSghc-prim-0.3.1.0.a > -rw-r--r-- root/admin 1134504 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- > prim-0.3.1.0/libHSghc-prim-0.3.1.0_p.a > -rw-r--r-- root/admin 871 2015-07-01 13:09 > ./sw/lib/ghc-7.8.3/package.conf.d/ghc- > prim-0.3.1.0-954cb57749cf319beafdc89b3415422c.conf New description: Using the ghc-7.10.1-x86_64-apple-darwin.tar.bz2 binary release to install ghc 7.10.1 with... {{{ ./configure --prefix=/sw make DESTDIR=/sw install fails to install a populated /sw/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3/GHC subdirectory causing builds of ghc packages with gcc-prim dependencies to fail. The only non- documentation files installed are... -rwxr-xr-x root/admin 647620 2015-07-01 13:20 ./sw/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3/libHSghc- prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3-ghc7.10.1.dylib -rw-r--r-- root/admin 1326504 2015-07-01 13:20 ./sw/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3/libHSghc- prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3.a -rw-r--r-- root/admin 814 2015-07-01 13:20 ./sw/lib/ghc-7.10.1/package.conf.d/ghc- prim-0.4.0.0-7c945cc0c41d3b7b70f3edd125671166.conf This compares to the same installation of the ghc-7.8.3-x86_64-apple- darwin.tar.bz2 binary release which does install the required files as... drwxr-xr-x root/admin 0 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/ drwxr-xr-x root/admin 0 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/ -rw-r--r-- root/admin 373897 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Classes.dyn_hi -rw-r--r-- root/admin 373885 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Classes.hi -rw-r--r-- root/admin 373889 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Classes.p_hi -rw-r--r-- root/admin 2661 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/CString.dyn_hi -rw-r--r-- root/admin 2649 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/CString.hi -rw-r--r-- root/admin 2653 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/CString.p_hi -rw-r--r-- root/admin 1940 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Debug.dyn_hi -rw-r--r-- root/admin 1928 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Debug.hi -rw-r--r-- root/admin 1932 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Debug.p_hi -rw-r--r-- root/admin 942 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/IntWord64.dyn_hi -rw-r--r-- root/admin 930 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/IntWord64.hi -rw-r--r-- root/admin 934 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/IntWord64.p_hi -rw-r--r-- root/admin 388 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Magic.dyn_hi -rw-r--r-- root/admin 376 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Magic.hi -rw-r--r-- root/admin 380 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Magic.p_hi -rw-r--r-- root/admin 50032 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/PrimopWrappers.dyn_hi -rw-r--r-- root/admin 50020 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/PrimopWrappers.hi -rw-r--r-- root/admin 50024 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/PrimopWrappers.p_hi -rw-r--r-- root/admin 1100 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Tuple.dyn_hi -rw-r--r-- root/admin 1088 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Tuple.hi -rw-r--r-- root/admin 1092 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Tuple.p_hi -rw-r--r-- root/admin 939 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Types.dyn_hi -rw-r--r-- root/admin 927 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Types.hi -rw-r--r-- root/admin 931 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Types.p_hi -rwxr-xr-x root/admin 631192 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/libHSghc-prim-0.3.1.0-ghc7.8.3.dylib -rw-r--r-- root/admin 792352 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/libHSghc-prim-0.3.1.0.a -rw-r--r-- root/admin 1134504 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/libHSghc-prim-0.3.1.0_p.a -rw-r--r-- root/admin 871 2015-07-01 13:09 ./sw/lib/ghc-7.8.3/package.conf.d/ghc- prim-0.3.1.0-954cb57749cf319beafdc89b3415422c.conf }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 14:14:07 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 14:14:07 -0000 Subject: [GHC] #10516: PolyKinds results in incorrect reporting of type synonym parameter count In-Reply-To: <055.bec1f97d6a44e1f3f7ecb1a59b83df87@haskell.org> References: <055.bec1f97d6a44e1f3f7ecb1a59b83df87@haskell.org> Message-ID: <070.91745685be31649c5a3ecdf40a4cd0a1@haskell.org> #10516: PolyKinds results in incorrect reporting of type synonym parameter count -------------------------------------+------------------------------------- Reporter: benjamin.hodgson | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: | polykinds/T10516 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: It sadly doesn't look like this will be terribly convenient. Punting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 14:14:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 14:14:21 -0000 Subject: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files In-Reply-To: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> References: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> Message-ID: <059.09d16e156b67df83e938dbf6abe8d5c3@haskell.org> #1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: archblob Type: feature request | Status: merge Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 6.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D194 | Phab:D1310 -------------------------------------+------------------------------------- Changes (by simonmar): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 14:14:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 14:14:32 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.79baa84ddbe7eb59a03353616b29c8cd@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Phyx- Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D586 | Phab:D587 Phab:D1244 Phab:D1310 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 14:17:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 14:17:49 -0000 Subject: [GHC] #10498: "if ... then \case -> else ..." causes a "missing else clause" error In-Reply-To: <050.28cad0c5bb9248828a1f63b683a53853@haskell.org> References: <050.28cad0c5bb9248828a1f63b683a53853@haskell.org> Message-ID: <065.1462393a7a5ae45d83b8229b5e358435@haskell.org> #10498: "if ... then \case -> else ..." causes a "missing else clause" error -------------------------------------+------------------------------------- Reporter: dramforever | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1309 -------------------------------------+------------------------------------- Comment (by simonmar): Worth double-checking to see whether the set of shift/reduce conflicts in `Parser.y` needs updating. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 14:26:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 14:26:03 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.2eea731696b04fe4a13ff7c0d8fa4f9b@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 5321 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by goldfire): It has to get big, as the coercion witnesses the sequence of reductions that a type family makes to get to a normal form. There are roughly `N` steps. And each step must explicitly mention the decreasing value of `N`. And that's quadratic. Unless I'm missing something, the only way to remove the quadratic behavior here is to redesign Core to be less explicit. That might just be possible. Right now, we can take a coercion and ask what types it relates. We will always get an answer. But perhaps we can redesign things so that we ask a coercion what types it relates, '''and we always provide one of the types'''. Then some function tells us what the other type is. (This operation can't just be, say, left-to-right because we need `sym` to work.) As a really easy example, this new design means that reflexive coercions don't need to store their types, because one type is always the same as the other. In the case of axioms, getting from one type to another is much harder. Going left-to-right seems possible, but it will require a matching algorithm. Going right-to-left on non-injective type family axioms is not possible without some extra information, so that's annoying. But maybe there's a design of this feature available. What would be the consequences? Coercions would get smaller. Compilation would get faster. Core Lint would get slower. Core would get harder to debug, perhaps. Might be worth it. '''Wait! A new idea! ''' This is actually an old idea of mine, but one I've never articulated. What if we just don't bother with coercions at all when `-dcore-lint` is off? I conjecture that they're entirely pointless without `-dcore-lint`. Sometimes we'll need to ask for the type of `(expr |> co)`, and so we'll have to store the type of the result of a cast (since we're omitting the coercion). Implementing this idea may be a challenge given our current code infrastructure, but I do think it would work. And then, poof, this problem goes away, and compilation probably gets a lot faster in a lot of cases. We absolutely want to keep coercions around for `-dcore-lint`, as that feature has saved us from unknown quantities of pain and embarrassment. But there's no good reason ordinary, trusting users need to pay the price (in compilation times/memory) for this feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 14:29:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 14:29:49 -0000 Subject: [GHC] #5966: getAppUserDataDirectory does not respect XDG specification In-Reply-To: <047.bc37781e7713df0d1b7455991f78caf3@haskell.org> References: <047.bc37781e7713df0d1b7455991f78caf3@haskell.org> Message-ID: <062.30a6978d0bda08ce198f8771a2457c8d@haskell.org> #5966: getAppUserDataDirectory does not respect XDG specification -------------------------------------+------------------------------------- Reporter: ordcoder | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 6077 Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by hvr): * status: upstream => new * cc: ekmett (added) Comment: `directory` now provides primitives to query XDG dirs, so now the ball is again in GHC's court to decide how/whether to support XDG dirs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 14:35:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 14:35:04 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.b5bb9a5802ea3ce49b6dc09f84ec3783@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.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): -------------------------------------+------------------------------------- Comment (by goldfire): I like the idea of using a different operator to flag required vs provided here. I'm far from convinced about `*>`, not in the least because that steals the type operator. I do agree with Reid about the unfortunate fact that `C a => D a => T` already has a meaning. But we're not stealing syntax here, because the `blah` in `pattern P :: blah` is '''not''' a type. It's a pattern type signature, which, in its current syntax, looks rather like a type, but it's a different beast, with its own strange rules. (Rather like the fact that the `blah` in `data X where Y :: blah` is also not a type. Note that `C a => D a => a -> X` doesn't work there, but that record and bang syntax does.) So I'm not terribly bothered by the double `=>` in this regard, but only a little bothered. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 14:38:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 14:38:09 -0000 Subject: [GHC] #5966: getAppUserDataDirectory does not respect XDG specification In-Reply-To: <047.bc37781e7713df0d1b7455991f78caf3@haskell.org> References: <047.bc37781e7713df0d1b7455991f78caf3@haskell.org> Message-ID: <062.bdb3a2e4f98b13aa28f75793e4b6feb3@haskell.org> #5966: getAppUserDataDirectory does not respect XDG specification -------------------------------------+------------------------------------- Reporter: ordcoder | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 6077 Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by dolio): Isn't this still a report about `directory`? I think it was decided for the upstream issue that changing the behavior of `getAppUserDataDirectory` would silently break things, so it was better to add the XDG querying functions for people to use rather than switch this function. So should this issue be closed? If the reason it's open is GHC placing its files in XDG directories, that is #6077 as mentioned by simonmar above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 14:39:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 14:39:24 -0000 Subject: [GHC] #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images In-Reply-To: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> References: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> Message-ID: <059.4c2389350e09b246513c9c308686b64e@haskell.org> #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Documentation | Version: 7.10.1 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): Phab:D958, | Phab:D970 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This is fixed in the ReST-ified user guide -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 15:02:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 15:02:01 -0000 Subject: [GHC] #10817: Looping default associated type family without UndecidableInstances In-Reply-To: <047.64ffaf6cb4d5ab1829ed952b25df0d19@haskell.org> References: <047.64ffaf6cb4d5ab1829ed952b25df0d19@haskell.org> Message-ID: <062.da9b75dc5f0e51a8141aa0571a6ff1d2@haskell.org> #10817: Looping default associated type family without UndecidableInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_fail/T10817 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1262 -------------------------------------+------------------------------------- Comment (by goldfire): I've just pushed a patch (relative to `ghc-7.10`) to `wip/rae`. (See commit 8b69b318802f59cfeb0779779cfbbebf74348fa0.) I can't validate because of the problem Simon already mentioned about `ghc-7.10` not building. But hopefully this is only a typo or two away from working. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 15:12:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 15:12:38 -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.c54aee7ba81e6b65e54e46e781513f62@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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): -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => simplCore/should_fail/T7411 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 15:19:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 15:19:46 -0000 Subject: [GHC] #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression In-Reply-To: <045.67153471687796395f900337ba5220e7@haskell.org> References: <045.67153471687796395f900337ba5220e7@haskell.org> Message-ID: <060.31aea56600013d4b436ba23b93644eb8@haskell.org> #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression -------------------------------------+------------------------------------- Reporter: erisco | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.8.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): -------------------------------------+------------------------------------- Comment (by goldfire): Good point. But I'm not terribly concerned here. The current behavior of `dataToPatQ` in this situation (when it sees a function instead of a constructor) is to create some bogus Haskell. The new behavior of `dataToPatQ` in this situation will be to create some bogus Haskell. The bogus Haskell changes, but I don't think it's any worse. And, as you say, with this change, we could improve `dataToExpQ` to create correct Haskell. Perhaps better would be for calls to `dataToQa` to know when it's working with a pattern and fail more gracefully. That would indeed be an improvement. But I don't think that we should try too hard here. The `Data` instance involved is lying, calling something a constructor when it's not. If we can accommodate the lie easily -- as we can in `dataToExpQ` -- then great. Otherwise, I think it's OK to fail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 15:28:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 15:28:21 -0000 Subject: [GHC] #5966: getAppUserDataDirectory does not respect XDG specification In-Reply-To: <047.bc37781e7713df0d1b7455991f78caf3@haskell.org> References: <047.bc37781e7713df0d1b7455991f78caf3@haskell.org> Message-ID: <062.3c776347c8de678d61f775db4690e16c@haskell.org> #5966: getAppUserDataDirectory does not respect XDG specification -------------------------------------+------------------------------------- Reporter: ordcoder | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 6077 Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed Comment: Replying to [comment:14 dolio]: > If the reason it's open is GHC placing its files in XDG directories, that is #6077 as mentioned by simonmar above. you're right... I missed that -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 15:29:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 15:29:13 -0000 Subject: [GHC] #10376: arm/linux linking failure In-Reply-To: <044.29ac411aa184ff9b10d3766853c9a35d@haskell.org> References: <044.29ac411aa184ff9b10d3766853c9a35d@haskell.org> Message-ID: <059.3ad7e8435b8f99ed77d43d4387e81783@haskell.org> #10376: arm/linux linking failure -------------------------------------+----------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10464 | Differential Rev(s): -------------------------------------+----------------------------- Comment (by thomie): @k-bx: ok, I can reproduce it now. I was using Ubuntu-14.04, which comes with llvm-3.5.0, whereas llvm-3.5.2 is needed. Starting over with a new machine and Ubuntu-15.04 solved the problem. Here's a workaround: set `library-stripping: False` in your `.cabal/config` file, and reinstall `text`. The warnings disappear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 15:29:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 15:29:36 -0000 Subject: [GHC] #6077: Respect XDG_CONFIG_HOME In-Reply-To: <045.4be78870b39bed231ff23249aec382c8@haskell.org> References: <045.4be78870b39bed231ff23249aec382c8@haskell.org> Message-ID: <060.ef9cfa1af5d40230ba8b7578e236232e@haskell.org> #6077: Respect XDG_CONFIG_HOME -------------------------------------+------------------------------------- Reporter: So8res | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: None | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 5966 | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by hvr): for the record, `directory` now has separate functions availabel for querying XDG dirs. So GHC now needs to decide if and how to support XDG base dirs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 15:33:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 15:33:34 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.b0ea9d782a84f814ea487637bb369bfe@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 5321 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by bgamari): For the record, #7428 is characterized by a similar blow-up in coercions. I'm not quite sure whether it's the same cause, but it is eerily reminiscent. Disabling production of coercions is an interesting idea; I wonder how much this would actually improve compilation speed in the non-pathological cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 15:44:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 15:44:30 -0000 Subject: [GHC] #10905: Incorrect number of parameters in "role" errors In-Reply-To: <047.769c113cdba80683b91dbad9e4b88b4d@haskell.org> References: <047.769c113cdba80683b91dbad9e4b88b4d@haskell.org> Message-ID: <062.af2558fb582aef4fd6b565bf7c3e1e48@haskell.org> #10905: Incorrect number of parameters in "role" errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: roles 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): -------------------------------------+------------------------------------- Comment (by goldfire): If I say {{{ import Data.Coerce data G a where MkG :: G Int newtype Age = MkAge Int go :: G Age -> G Int go = coerce }}} I get {{{ Couldn't match type ?Int? with ?Age? arising from trying to show that the representations of ?G Age? and ?G Int? are the same Relevant role signatures: type role G nominal In the expression: coerce In an equation for ?go?: go = coerce }}} That role signature looks helpful. Perhaps !TcErrors could be more selective in deciding which signatures to include (though I'm not quite sure how to get this right), but I do think they're good to see. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 15:49:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 15:49:16 -0000 Subject: [GHC] #10905: Incorrect number of parameters in "role" errors In-Reply-To: <047.769c113cdba80683b91dbad9e4b88b4d@haskell.org> References: <047.769c113cdba80683b91dbad9e4b88b4d@haskell.org> Message-ID: <062.1138ff26125e08b1e38cd305dc6716e2@haskell.org> #10905: Incorrect number of parameters in "role" errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: roles 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): -------------------------------------+------------------------------------- Comment (by crockeea): To me this is a separate issue from the bug I reported. I have no problem with the fact that roles were reported for a missing constructor error. If anything I think the roles *help* in my example. The ticket as reported is really just about when the kind-roles should be printed, as that's the part I found confusing. Replying to [comment:4 simonpj]: > I don't think my reasoning was any deeper than the comment says. In the example in the Description, the roles are a distraction from the main point: the constructor isn't in scope. They just get in the way, and for most people will be mysterious and confusing. > > Do we even want to see these role, or perhaps the roles of type constructors we have decomposed on the way to getting this error? > > To put it another way, can you give an example of where they are useful? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 15:58:22 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 15:58:22 -0000 Subject: [GHC] #10049: Lower level memcpy primop In-Reply-To: <049.7926ad1e5d4d0b6d73e54643d844bbc7@haskell.org> References: <049.7926ad1e5d4d0b6d73e54643d844bbc7@haskell.org> Message-ID: <064.32ce167a4ff0a4205f4dbb131ebb6200@haskell.org> #10049: Lower level memcpy primop -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by bgamari): For the record we have had `rep movsw` support for quite a while as a result of Phab:D166. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 16:10:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 16:10:43 -0000 Subject: [GHC] #10845: Incorrect behavior when let binding implicit CallStack object In-Reply-To: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> References: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> Message-ID: <068.c796a88fb8a8d3d992670d364c660c05@haskell.org> #10845: Incorrect behavior when let binding implicit CallStack object -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10846 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by gridaphobe): Ah, I wasn't suggesting to treat `getCallStack` specially, it was just the simplest way to get GHC to instantiate the ?x's type with `CallStack` in the RHS of the local let-binder, which is a key ingredient in this bug. Suppressing the special case for `CallStack` seems to get us part of the way, we defer solving the CallStack until we get a toplevel implication {{{ Implic { TcLevel = 3 Skolems = No-eqs = False Status = Unsolved Given = $dIP_anO :: ?loc::CallStack Wanted = WC {wc_impl = Implic { TcLevel = 5 Skolems = No-eqs = False Status = Unsolved Given = Wanted = WC {wc_simple = [W] $dIP_anT :: ?loc::CallStack (CNonCanonical)} Binds = EvBindsVar the inferred type of y_anr :: t_anQ[tau:5] }} Binds = EvBindsVar the type signature for: f :: (?loc::CallStack) => [(String, SrcLoc)] } }}} Unfortunately the wanted in this implication is itself an implication, so GHC raises the TcLevel again when it enters the nested implication and our special case remains suppressed. I find it a bit strange though that the nested implication has no givens. Why emit an implication with no givens when we could just emit a simple wanted? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 16:15:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 16:15:47 -0000 Subject: [GHC] #8335: Create more specialized entries to GC In-Reply-To: <048.b95f2f48d387537ed648bf2e9895d80e@haskell.org> References: <048.b95f2f48d387537ed648bf2e9895d80e@haskell.org> Message-ID: <063.84ed54bced1335548f112fcc7d4f2eba@haskell.org> #8335: Create more specialized entries to GC -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: bgamari Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 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): -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: I think this may be fixed (at least in the current state of `master`, a3c78abcbdfe5025dc704acdcd0a85c78cabbd6b). This program (taken from #8326), {{{#!hs {-# LANGUAGE MagicHash #-} module Test where import GHC.Prim import GHC.Types f :: Int# -> Int f x | isTrue# (x ># 0#) = I# x | otherwise = -(I# x) }}} produces this Core, {{{#!hs f :: Int# -> Int f = \ (x_anw :: Int#) -> case tagToEnum# @ Bool (># x_anw 0#) of _ [Occ=Dead] { False -> I# (negateInt# x_anw); True -> I# x_anw } }}} which is ultimately lowered to this C--, {{{ Test.f_entry() // [R2] { info_tbl: [(cyv, label: Test.f_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 4} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset cyv: Hp = Hp + 16; if (Hp > HpLim) goto cyz; else goto cyy; cyz: HpAlloc = 16; R2 = R2; R1 = Test.f_closure; call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8; cyy: if (%MO_S_Gt_W64(R2, 0)) goto cyL; else goto cyI; cyL: I64[Hp - 8] = GHC.Types.I#_con_info; I64[Hp] = R2; R1 = Hp - 7; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; cyI: I64[Hp - 8] = GHC.Types.I#_con_info; I64[Hp] = -R2; R1 = Hp - 7; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } }] }}} Jan, would you agree that all looks okay here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 17:00:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 17:00:55 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310520=3A_RecordWildCards_causes_?= =?utf-8?q?=E2=80=9Cis_not_a_=28visible=29_field_of_constructor?= =?utf-8?b?4oCdIGluIGdoY2k=?= In-Reply-To: <043.c857f67e883ef833a204da9e13d91bc2@haskell.org> References: <043.c857f67e883ef833a204da9e13d91bc2@haskell.org> Message-ID: <058.58110632b97883851504bdef0146890e@haskell.org> #10520: RecordWildCards causes ?is not a (visible) field of constructor? in ghci -------------------------------------+------------------------------------- Reporter: ion1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 7.10.1 Resolution: fixed | Keywords: | RecordWildCards Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: I'm afraid this isn't entirely trivial to backport as it requires 9b73cb16485f331d9dc1f37826c6d503e24a5b0b which is a rather major rework. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 17:28:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 17:28:05 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.88cfd32b1977d792fe0dcd29d8402e82@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: trommler Type: bug | Status: closed Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Changes (by trommler): * Attachment "0001-Fix-merge-error.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 17:29:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 17:29:24 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.56386167a0ba1b27535b424b01d7c9f4@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Changes (by trommler): * owner: trommler => * status: closed => new * resolution: fixed => Comment: Added patch for merge error in commit:e22d7dc. Please merge onto ghc-7.10 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 17:30:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 17:30:09 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.86b8056c9129ff86e0317724871a8c10@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Changes (by trommler): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 17:30:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 17:30:59 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.8cea027d135309e9968821f8cb39a109@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Changes (by trommler): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 17:32:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 17:32:12 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.6cf7e9625525a98e118b2e8d8b6074fc@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 -------------------------------------+------------------------------------- Comment (by trommler): Sorry, I hope this is right now. The attached patch needs to be commited onto branch ghc-7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 18:09:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 18:09:46 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.3253cd1b02291434f9b18562acd4c28e@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10528 | Differential Rev(s): Phab:D1246 -------------------------------------+------------------------------------- Comment (by afarmer): Rebased onto most recent master and did a `./validate --slow` on both master and this patch. The one additional test that fails is T7785, so I'm looking into it now. {{{ =====> T7785(optasm) 1 of 1 [0, 0, 0] cd ./simplCore/should_compile && "/data/users/anfarmer/head/inplace/bin /ghc-stage2" -c T7785.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug- output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed- specialisations -fno-ghci-history -O -fasm -ddump-rules > T7785.comp.stderr 2>&1 Actual stderr output differs from expected: --- ./simplCore/should_compile/T7785.stderr.normalised 2015-10-06 11:10:41.550769587 -0700 +++ ./simplCore/should_compile/T7785.comp.stderr.normalised 2015-10-06 11:10:41.550769587 -0700 @@ -4,5 +4,3 @@ forall ($dMyFunctor :: MyFunctor []) (irred :: Domain [] Int). shared @ [] $dMyFunctor irred = bar_$sshared -"SPEC/Foo myfmap @ []" [ALWAYS] - forall (tpl :: MyFunctor []). myfmap @ [] tpl = $cmyfmap *** unexpected failure for T7785(optasm) }}} I did a preliminary stackage LTS 3.7 build (with 7.10.2+patch) and it looked positive (everything seemed to be building), but the VM ran out of disk and didn't build the last 300 or so packages. Going to restart that process on another machine and report back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 18:59:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 18:59:46 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.25d56d27895f01d01dc1791476e26066@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.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): -------------------------------------+------------------------------------- Comment (by rodlogic): Sorry to inject myself here, but what about: {{{ pattern P :: (Required b) => b -> T a => (Provided a) }}} I.e. required constraints come before and provided after. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 19:17:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 19:17:36 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.4f84e2c98e2327c221cd755479bff199@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10528 | Differential Rev(s): Phab:D1246 -------------------------------------+------------------------------------- Comment (by afarmer): So it looks like the output for T7785 was changed by SPJ in 45d9a15c4b85a2ed89579106bdafd84accf2cb39, which is the commit that this issue is addressing anyway, so I just changed the output back to what it was before and the test passes. Going to start stackage build soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 19:38:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 19:38:00 -0000 Subject: [GHC] #10049: Lower level memcpy primop In-Reply-To: <049.7926ad1e5d4d0b6d73e54643d844bbc7@haskell.org> References: <049.7926ad1e5d4d0b6d73e54643d844bbc7@haskell.org> Message-ID: <064.c161e502739d001976b78c9360c768ae@haskell.org> #10049: Lower level memcpy primop -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by tibbe): Phab:D166 still needs to be merged though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 20:38:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 20:38:39 -0000 Subject: [GHC] #10936: Can't fire up GHCi with Mueval Message-ID: <048.a6b78e942d795aa593f02c79cf06f467@haskell.org> #10936: Can't fire up GHCi with Mueval -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Other (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- Cf. https://github.com/commercialhaskell/stack/issues/1094#issuecomment-145949397 {{{ $ stack ghci mueval:exe:mueval Using main module: Package `mueval' component exe:mueval with main-is file: /home/callen/work/mueval/watchdog.hs Configuring GHCi with the following packages: mueval GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help ghc: --interactive can't be used with -prof or -unreg. Usage: For basic information, try the `--help' option. }}} {{{ $ stack -v ghci mueval:exe:mueval Version 0.1.5.0 X86_64 2015-10-06 20:40:02.88486: [debug] Checking for project config at: /home/callen/work/mueval/stack.yaml @(stack_Bp003b8iWaELtdr693pSPs:Stack.Config src/Stack/Config.hs:511:9) 2015-10-06 20:40:02.885018: [debug] Loading project config file stack.yaml @(stack_Bp003b8iWaELtdr693pSPs:Stack.Config src/Stack/Config.hs:534:13) 2015-10-06 20:40:02.885749: [debug] Run process: ldd /home/callen/.local/bin/stack @(stack_Bp003b8iWaELtdr693pSPs:System.Process.Read src/System/Process/Read.hs:259:3) 2015-10-06 20:40:02.893986: [debug] Trying to decode /home/callen/.stack /build-plan-cache/x86_64-linux/lts-3.5.cache @(stack_Bp003b8iWaELtdr693pSPs:Data.Binary.VersionTagged src/Data/Binary/VersionTagged.hs:53:5) 2015-10-06 20:40:02.900069: [debug] Success decoding /home/callen/.stack /build-plan-cache/x86_64-linux/lts-3.5.cache @(stack_Bp003b8iWaELtdr693pSPs:Data.Binary.VersionTagged src/Data/Binary/VersionTagged.hs:62:13) 2015-10-06 20:40:02.900294: [debug] Run process: ghc --info @(stack_Bp003b8iWaELtdr693pSPs:System.Process.Read src/System/Process/Read.hs:259:3) 2015-10-06 20:40:02.931936: [debug] Run process: ghc --numeric-version @(stack_Bp003b8iWaELtdr693pSPs:System.Process.Read src/System/Process/Read.hs:259:3) 2015-10-06 20:40:02.948879: [debug] Run process: ghc-pkg --no-user- package-db field --simple-output Cabal version @(stack_Bp003b8iWaELtdr693pSPs:System.Process.Read src/System/Process/Read.hs:259:3) 2015-10-06 20:40:02.964055: [debug] Run process: ghc-pkg --no-user- package-db list --global @(stack_Bp003b8iWaELtdr693pSPs:System.Process.Read src/System/Process/Read.hs:259:3) 2015-10-06 20:40:02.979938: [debug] Run process: locale -a @(stack_Bp003b8iWaELtdr693pSPs:System.Process.Read src/System/Process/Read.hs:259:3) 2015-10-06 20:40:02.981134: [debug] Checking resolver: lts-3.5 @(stack_Bp003b8iWaELtdr693pSPs:Stack.Build.Source src/Stack/Build/Source.hs:163:17) 2015-10-06 20:40:02.981242: [debug] Trying to decode /home/callen/.stack /build-plan-cache/x86_64-linux/lts-3.5.cache @(stack_Bp003b8iWaELtdr693pSPs:Data.Binary.VersionTagged src/Data/Binary/VersionTagged.hs:53:5) 2015-10-06 20:40:02.985054: [debug] Success decoding /home/callen/.stack /build-plan-cache/x86_64-linux/lts-3.5.cache @(stack_Bp003b8iWaELtdr693pSPs:Data.Binary.VersionTagged src/Data/Binary/VersionTagged.hs:62:13) 2015-10-06 20:40:02.989986: [debug] Checking resolver: lts-3.5 @(stack_Bp003b8iWaELtdr693pSPs:Stack.Build.Source src/Stack/Build/Source.hs:163:17) 2015-10-06 20:40:02.990098: [debug] Trying to decode /home/callen/.stack /build-plan-cache/x86_64-linux/lts-3.5.cache @(stack_Bp003b8iWaELtdr693pSPs:Data.Binary.VersionTagged src/Data/Binary/VersionTagged.hs:53:5) 2015-10-06 20:40:02.994056: [debug] Success decoding /home/callen/.stack /build-plan-cache/x86_64-linux/lts-3.5.cache @(stack_Bp003b8iWaELtdr693pSPs:Data.Binary.VersionTagged src/Data/Binary/VersionTagged.hs:62:13) 2015-10-06 20:40:02.995893: [debug] Trying to decode /home/callen/.stack/indices/Hackage/00-index.cache @(stack_Bp003b8iWaELtdr693pSPs:Data.Binary.VersionTagged src/Data/Binary/VersionTagged.hs:53:5) 2015-10-06 20:40:03.15333: [debug] Success decoding /home/callen/.stack/indices/Hackage/00-index.cache @(stack_Bp003b8iWaELtdr693pSPs:Data.Binary.VersionTagged src/Data/Binary/VersionTagged.hs:62:13) 2015-10-06 20:40:03.1727: [debug] Checking resolver: lts-3.5 @(stack_Bp003b8iWaELtdr693pSPs:Stack.Build.Source src/Stack/Build/Source.hs:163:17) 2015-10-06 20:40:03.172812: [debug] Trying to decode /home/callen/.stack /build-plan-cache/x86_64-linux/lts-3.5.cache @(stack_Bp003b8iWaELtdr693pSPs:Data.Binary.VersionTagged src/Data/Binary/VersionTagged.hs:53:5) 2015-10-06 20:40:03.17626: [debug] Success decoding /home/callen/.stack /build-plan-cache/x86_64-linux/lts-3.5.cache @(stack_Bp003b8iWaELtdr693pSPs:Data.Binary.VersionTagged src/Data/Binary/VersionTagged.hs:62:13) 2015-10-06 20:40:03.177793: [debug] Trying to decode /home/callen/.stack/indices/Hackage/00-index.cache @(stack_Bp003b8iWaELtdr693pSPs:Data.Binary.VersionTagged src/Data/Binary/VersionTagged.hs:53:5) 2015-10-06 20:40:03.338356: [debug] Success decoding /home/callen/.stack/indices/Hackage/00-index.cache @(stack_Bp003b8iWaELtdr693pSPs:Data.Binary.VersionTagged src/Data/Binary/VersionTagged.hs:62:13) 2015-10-06 20:40:03.343809: [debug] Run process: ghc-pkg --global --no- user-package-db dump --expand-pkgroot @(stack_Bp003b8iWaELtdr693pSPs:System.Process.Read src/System/Process/Read.hs:259:3) 2015-10-06 20:40:03.373571: [debug] Run process: ghc-pkg --user --no-user- package-db --package-db /home/callen/.stack/snapshots/x86_64-linux/lts-3.5/7.10.2/pkgdb/ dump --expand-pkgroot @(stack_Bp003b8iWaELtdr693pSPs:System.Process.Read src/System/Process/Read.hs:259:3) 2015-10-06 20:40:03.483621: [debug] Run process: ghc-pkg --user --no-user- package-db --package-db /home/callen/work/mueval/.stack- work/install/x86_64-linux/lts-3.5/7.10.2/pkgdb/ dump --expand-pkgroot @(stack_Bp003b8iWaELtdr693pSPs:System.Process.Read src/System/Process/Read.hs:259:3) 2015-10-06 20:40:03.498867: [debug] Trying to decode /home/callen/.stack/indices/Hackage/00-index.cache @(stack_Bp003b8iWaELtdr693pSPs:Data.Binary.VersionTagged src/Data/Binary/VersionTagged.hs:53:5) 2015-10-06 20:40:03.648263: [debug] Success decoding /home/callen/.stack/indices/Hackage/00-index.cache @(stack_Bp003b8iWaELtdr693pSPs:Data.Binary.VersionTagged src/Data/Binary/VersionTagged.hs:62:13) 2015-10-06 20:40:03.648411: [debug] Trying to decode /home/callen/.stack/indices/Hackage/00-index.cache @(stack_Bp003b8iWaELtdr693pSPs:Data.Binary.VersionTagged src/Data/Binary/VersionTagged.hs:53:5) 2015-10-06 20:40:03.806948: [debug] Success decoding /home/callen/.stack/indices/Hackage/00-index.cache @(stack_Bp003b8iWaELtdr693pSPs:Data.Binary.VersionTagged src/Data/Binary/VersionTagged.hs:62:13) 2015-10-06 20:40:03.872715: [debug] Run process: ghc-pkg --no-user- package-db list --global @(stack_Bp003b8iWaELtdr693pSPs:System.Process.Read src/System/Process/Read.hs:259:3) 2015-10-06 20:40:03.888689: [info] Using main module: Package `mueval' component exe:mueval with main-is file: /home/callen/work/mueval/watchdog.hs @(stack_Bp003b8iWaELtdr693pSPs:Stack.Ghci src/Stack/Ghci.hs:101:28) 2015-10-06 20:40:03.888816: [info] Configuring GHCi with the following packages: mueval @(stack_Bp003b8iWaELtdr693pSPs:Stack.Ghci src/Stack/Ghci.hs:81:5) 2015-10-06 20:40:03.888868: [debug] Run process: ghc --interactive -odir=/home/callen/work/mueval/.stack-work/odir/ -hidir=/home/callen/work/mueval/.stack-work/odir/ -hide-all-packages -Wall -static -i/home/callen/work/mueval/ -i/home/callen/work/mueval/.stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/autogen/ -i/home/callen/work/mueval/.stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/ -stubdir=/home/callen/work/mueval/.stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/ -optP-include -optP/home/callen/work/mueval/.stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/autogen/cabal_macros.h -package=base /home/callen/work/mueval/watchdog.hs @(stack_Bp003b8iWaELtdr693pSPs:Stack.Exec src/Stack/Exec.hs:52:5) GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help ghc: --interactive can't be used with -prof or -unreg. Usage: For basic information, try the `--help' option. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 20:39:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 20:39:01 -0000 Subject: [GHC] #10931: layers-0.1 does not compile with ghc-7.10 (likely a regression from ghc-7.8) In-Reply-To: <045.19b8056b1d70bf96a656ae7348a956cb@haskell.org> References: <045.19b8056b1d70bf96a656ae7348a956cb@haskell.org> Message-ID: <060.e877aaf0b76679f1b04a65f514ec722b@haskell.org> #10931: layers-0.1 does not compile with ghc-7.10 (likely a regression from ghc-7.8) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by slyfox): Replying to [comment:3 simonpj]: > How bad is it if this library doesn't work? I imagine this is relatively rare else it'd show up more often. Nonworking library in 7.10 is absolutely not a problem for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 6 21:16:29 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Oct 2015 21:16:29 -0000 Subject: [GHC] #10918: Float once-used let binding into a recursive function In-Reply-To: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> References: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> Message-ID: <061.c6bb6da35aed6ac01f74dde9645d82c1@haskell.org> #10918: Float once-used let binding into a recursive function -------------------------------------+------------------------------------- Reporter: nomeata | Owner: 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by nomeata): Hey, where is my comment I reported something here a few days ago :-( Darn it. Maybe I should open a ticket asking for the removal of the ?Preview? button (after all, there is a live preview these days). Anyways, I made `CallArity` consider all variables interesting, so that we actually collect cardinality information on things that cannot be eta- expanded, made it store the once-used-information: {{{#!hs v'' | called_once = v' `setIdDemandInfo` oneifyDmd (idDemandInfo v') | otherwise = v' }}} and then made `preInlineUnconditionally` use this information: {{{#!hs try_once in_lam int_cxt -- There's one textual occurrence | not in_lam = isNotTopLevel top_lvl || early_phase - | otherwise = int_cxt && canInlineInLam rhs + | otherwise = (int_cxt && canInlineInLam rhs) || isSingleUsed (idDemandInfo bndr) }}} This had the desired effect of changing {{{#!hs let x = f x0 in let go 20 = x go 10 = something else go i = go (i+1) in go y }}} to {{{#!hs let go 20 = f x0 go 10 = something else go i = go (i+1) in go y }}} in the simplifier phase following Call Arity, as expected. But the later FloatOut pass would simply float `f x0` out again to where it was before. I?m not sure how to prevent that. In general, floating something out of a recursive group is good, and the information that was used to effect the inlining (namely the once-used of `x`) is lost, as no `x` remains. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 00:46:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 00:46:25 -0000 Subject: [GHC] #10937: "ghc -no-link --make A.hs -o foo" does something silly Message-ID: <045.889834166a030bc3b81adffd573d6eb7@haskell.org> #10937: "ghc -no-link --make A.hs -o foo" does something silly -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- If I run "ghc -no-link --make A.hs -o foo" it puts the first object file it compiles into the `-o` location, and then fails because the object is not where is expected. {{{ [ezyang at hs01 ghc-fat-interface]$ ghc -no-link --make B.hs -o foo [1 of 2] Compiling A ( A.hs, A.o ) ./A.o: getFileStatus: does not exist (No such file or directory) }}} Without `-no-link` I get a more reasonable warning, and object files are not redirected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 01:41:45 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 01:41:45 -0000 Subject: [GHC] #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression In-Reply-To: <045.67153471687796395f900337ba5220e7@haskell.org> References: <045.67153471687796395f900337ba5220e7@haskell.org> Message-ID: <060.418c6e49b8127152a2784a24b49e557b@haskell.org> #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression -------------------------------------+------------------------------------- Reporter: erisco | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.8.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:D1313 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: => RyanGlScott * differential: => Phab:D1313 Comment: I can agree that it's probably not worth the effort to make such patterns work, especially since we'd have to convert the subpatterns to expressions to make this work, which would probably require a rewrite of `dataToQa`... I'll just stick to the `dataToExpQ` case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 04:19:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 04:19:02 -0000 Subject: [GHC] #10938: DeriveAnyClass + deriving Bifunctor causes GHC panic Message-ID: <048.05bdc8a9acaff098bc4ba561c4725449@haskell.org> #10938: DeriveAnyClass + deriving Bifunctor causes GHC panic -------------------------------------+------------------------------------- Reporter: erantapaa | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: MacOS X DeriveAnyClass | Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- Attempting the derive Bifunctor with DeriveAnyClass caused this message from GHC: {{{ $ ghc Foo.hs [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Var/Type length mismatch: [a_an7, b_an8] [] Var/Type length mismatch: [a_an7, b_an8] [] Var/Type length mismatch: [a_an7, b_an8] [] Foo.hs:8:13:ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-apple-darwin): tcTyVarDetails a_an7 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The code: {{{#!hs {-# LANGUAGE DeriveAnyClass #-} module Foo where import Data.Bifunctor data Blah a b = A a | B b deriving (Bifunctor) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 06:47:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 06:47:00 -0000 Subject: [GHC] #10571: GHC 7.10.1 segfaults when shiftL-ing Integers by negative amounts In-Reply-To: <046.5fe10823e2d0a9badb1b3a63cbe8bcdb@haskell.org> References: <046.5fe10823e2d0a9badb1b3a63cbe8bcdb@haskell.org> Message-ID: <061.3d2ba773ba81590e9ac28e7eb554f434@haskell.org> #10571: GHC 7.10.1 segfaults when shiftL-ing Integers by negative amounts ----------------------------------+-------------------------------------- Reporter: anders_ | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ----------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"ea4df12f7f3fc4d1d2af335804b8ec893f45550c/ghc" ea4df12/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ea4df12f7f3fc4d1d2af335804b8ec893f45550c" Ensure shiftL/shiftR arguments aren't negative Fixes #10571. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 06:47:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 06:47:00 -0000 Subject: [GHC] #10687: Clang 3.6 fails with -g due to .file directive order In-Reply-To: <044.67379f3a8d9d1920a99529a73d2b00f0@haskell.org> References: <044.67379f3a8d9d1920a99529a73d2b00f0@haskell.org> Message-ID: <059.ec6a2bb866cd028532eedae0a3c11126@haskell.org> #10687: Clang 3.6 fails with -g due to .file directive order -------------------------------------+------------------------------------- Reporter: scpmw | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"36811bfd3bd981d3cd3cc7280e1a815ba1ed42e9/ghc" 36811bfd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="36811bfd3bd981d3cd3cc7280e1a815ba1ed42e9" AsmCodeGen: Ensure LLVM .line directives are sorted Apparently some Clang 3.6 expects these to be sorted. Patch due to Peter Wortmann. Fixes #10687. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 06:48:37 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 06:48:37 -0000 Subject: [GHC] #10687: Clang 3.6 fails with -g due to .file directive order In-Reply-To: <044.67379f3a8d9d1920a99529a73d2b00f0@haskell.org> References: <044.67379f3a8d9d1920a99529a73d2b00f0@haskell.org> Message-ID: <059.d53ee7c72996feb76e85b98ee4373b04@haskell.org> #10687: Clang 3.6 fails with -g due to .file directive order -------------------------------------+------------------------------------- Reporter: scpmw | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 06:50:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 06:50:47 -0000 Subject: [GHC] #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ In-Reply-To: <048.86721c518b657437564df331356981ea@haskell.org> References: <048.86721c518b657437564df331356981ea@haskell.org> Message-ID: <063.8560a154ff0199f2cf96271619e94efc@haskell.org> #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => infoneeded Comment: strake888, do you think you could put this up on Phabricator when you have a patch addressing dfeuer's comment? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 06:51:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 06:51:52 -0000 Subject: [GHC] #10687: Clang 3.6 fails with -g due to .file directive order In-Reply-To: <044.67379f3a8d9d1920a99529a73d2b00f0@haskell.org> References: <044.67379f3a8d9d1920a99529a73d2b00f0@haskell.org> Message-ID: <059.0d7f6fbf7364258a225e9beba1f21bb1@haskell.org> #10687: Clang 3.6 fails with -g due to .file directive order -------------------------------------+------------------------------------- Reporter: scpmw | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 06:52:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 06:52:44 -0000 Subject: [GHC] #10571: GHC 7.10.1 segfaults when shiftL-ing Integers by negative amounts In-Reply-To: <046.5fe10823e2d0a9badb1b3a63cbe8bcdb@haskell.org> References: <046.5fe10823e2d0a9badb1b3a63cbe8bcdb@haskell.org> Message-ID: <061.12093ddc737d1047b2de999b8af3146c@haskell.org> #10571: GHC 7.10.1 segfaults when shiftL-ing Integers by negative amounts ----------------------------------+-------------------------------------- Reporter: anders_ | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ----------------------------------+-------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Fixed and merged to `ghc-7.10` as ea4df12f7f3fc4d1d2af335804b8ec893f45550c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 06:53:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 06:53:10 -0000 Subject: [GHC] #10687: Clang 3.6 fails with -g due to .file directive order In-Reply-To: <044.67379f3a8d9d1920a99529a73d2b00f0@haskell.org> References: <044.67379f3a8d9d1920a99529a73d2b00f0@haskell.org> Message-ID: <059.ff5e795f8039f650e3825ca17ac7a791@haskell.org> #10687: Clang 3.6 fails with -g due to .file directive order -------------------------------------+------------------------------------- Reporter: scpmw | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): -------------------------------------+------------------------------------- Comment (by bgamari): Fixed and merged to `ghc-7.10` as 36811bfd3bd981d3cd3cc7280e1a815ba1ed42e9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 06:57:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 06:57:24 -0000 Subject: [GHC] #8364: equip GHC with an accurate internal model of floating point In-Reply-To: <045.1a954a36897b343743f15a900b2f72bd@haskell.org> References: <045.1a954a36897b343743f15a900b2f72bd@haskell.org> Message-ID: <060.cdfdac63be965f8d5282ee1075702eb0@haskell.org> #8364: equip GHC with an accurate internal model of floating point -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9276 | Blocking: Related Tickets: #9276 | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => normal Comment: It seems like this is bound to be a fairly long-term project and isn't critical for proper compilation. Bumping down to normal priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 08:12:40 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 08:12:40 -0000 Subject: [GHC] #10939: Odditites regarding Any and typeclasses. Message-ID: <044.726c85b3e4519c1a60e9739c86554109@haskell.org> #10939: Odditites regarding Any and typeclasses. -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- The typechecker seems to be unable to operate on contexts containing "naked" `Any`, for example: {{{#!hs x :: State [Any] () x = put [] }}} {{{ No instance for (MonadState [Any] (StateT [Any] Identity)) arising from a use of ?put? }}} A more minimal self-contained example would be: {{{#!hs {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} import GHC.Prim (Any) class Class a b where method :: a -> b instance Class a a where method = id x :: Any -> Any x = method }}} {{{ No instance for (Class Any Any) arising from a use of ?method? }}} It's quite obvious why this error happens (`Any` is not a datatype), however it also feels like it shouldn't happen. All of the above code seems to work in 7.8, which is back when `Any` was a datatype. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 08:18:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 08:18:55 -0000 Subject: [GHC] #10918: Float once-used let binding into a recursive function In-Reply-To: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> References: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> Message-ID: <061.f83e58f2ea78528815597e975bbe5cdf@haskell.org> #10918: Float once-used let binding into a recursive function -------------------------------------+------------------------------------- Reporter: nomeata | Owner: 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by simonpj): Good point. The only obvious thing is to do arity/strictness analysis after the last use of float-out. And in fact with `-flate-dmd-anal` we do a late strictness analysis pass, which is not followed by float-out. I suppose you might need to add a last arity-analysis pass to that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 08:38:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 08:38:58 -0000 Subject: [GHC] #10918: Float once-used let binding into a recursive function In-Reply-To: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> References: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> Message-ID: <061.6169ac1a3a0f2698a25af61ece9b3ceb@haskell.org> #10918: Float once-used let binding into a recursive function -------------------------------------+------------------------------------- Reporter: nomeata | Owner: 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by nomeata): I suppose that would work, although I don?t like solving such issues by slamming just another pass to the end of the pipeline, instead of making sure the passes work well together (which is indeed tricky here). I?ll give it a shot to see if there are performance wins to be gained (I don?t actually expect much, I was mostly hoping for nice core), and if there are not many, I?d rather not pay the cost of yet another pass until there is a more compelling use case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 09:40:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 09:40:11 -0000 Subject: [GHC] #10938: DeriveAnyClass + deriving Bifunctor causes GHC panic In-Reply-To: <048.05bdc8a9acaff098bc4ba561c4725449@haskell.org> References: <048.05bdc8a9acaff098bc4ba561c4725449@haskell.org> Message-ID: <063.8183a336b82dc397cc3507002924ae7b@haskell.org> #10938: DeriveAnyClass + deriving Bifunctor causes GHC panic -------------------------------------+------------------------------------- Reporter: erantapaa | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Keywords: Resolution: | DeriveAnyClass Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * cc: dreixel (added) * component: Compiler => Compiler (Type checker) Comment: Reproducable with HEAD (ghc-7.11.20151002). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 09:40:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 09:40:28 -0000 Subject: [GHC] #10938: DeriveAnyClass + deriving Bifunctor causes GHC panic In-Reply-To: <048.05bdc8a9acaff098bc4ba561c4725449@haskell.org> References: <048.05bdc8a9acaff098bc4ba561c4725449@haskell.org> Message-ID: <063.32074b041a5269649b7fe723341434cd@haskell.org> #10938: DeriveAnyClass + deriving Bifunctor causes GHC panic -------------------------------------+------------------------------------- Reporter: erantapaa | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Keywords: Resolution: | DeriveAnyClass Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * os: MacOS X => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 09:45:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 09:45:17 -0000 Subject: [GHC] #10939: Odditites regarding Any and typeclasses. In-Reply-To: <044.726c85b3e4519c1a60e9739c86554109@haskell.org> References: <044.726c85b3e4519c1a60e9739c86554109@haskell.org> Message-ID: <059.8bad1d5b12b41dd8dfc725eea107f84e@haskell.org> #10939: Odditites regarding Any and typeclasses. -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by thomie): Your second example compiles fine with HEAD (ghc-7.11.20151002). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 10:03:29 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 10:03:29 -0000 Subject: [GHC] #10936: Can't fire up GHCi with Mueval In-Reply-To: <048.a6b78e942d795aa593f02c79cf06f467@haskell.org> References: <048.a6b78e942d795aa593f02c79cf06f467@haskell.org> Message-ID: <063.a31a5567e3a87002ae00aafa3ed09795@haskell.org> #10936: Can't fire up GHCi with Mueval -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1314 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D1314 Comment: I think the confusing error message is the only problem here: {{{ $ ghci -static GHCi, version 7.11.20151002: http://www.haskell.org/ghc/ :? for help ghc: --interactive can't be used with -prof. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 10:16:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 10:16:06 -0000 Subject: [GHC] #10940: Random number chosen by openTempFile is always 1804289383846930886 Message-ID: <046.6c26c2e1a6caf8aeb8abfcc47da92577@haskell.org> #10940: Random number chosen by openTempFile is always 1804289383846930886 -------------------------------------+------------------------------------- Reporter: andersk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- {{{#!hs import System.Directory import System.IO main = do (p, _) <- openTempFile "/tmp" "" print p removeFile p }}} {{{#!console $ runghc temp.hs "/tmp/1804289383846930886" $ runghc temp.hs "/tmp/1804289383846930886" $ runghc temp.hs "/tmp/1804289383846930886" $ runghc temp.hs "/tmp/1804289383846930886" }}} This ?random? number is the concatenation of the first two numbers 1804289383, 846930886 returned by glibc?s `rand()` when not seeded (or seeded with 1). This is not immediately a library security bug, I think: the file is created with `O_EXCL`, and if it already exists, `openTempFile` will move onto the next value 16816927771714636915, and so on. However, the predictable filenames make a potential application security bug that much more likely. (For your amusement, [https://www.google.com/search?q=1804289383846930886 Google 1804289383846930886].) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 10:25:46 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 10:25:46 -0000 Subject: [GHC] #9058: System.IO.openTempFile does not scale In-Reply-To: <045.41fdb1eece4d843bb1a26f72af3a8a36@haskell.org> References: <045.41fdb1eece4d843bb1a26f72af3a8a36@haskell.org> Message-ID: <060.bd5c88cf91a1c79720f52cc88f165d5c@haskell.org> #9058: System.IO.openTempFile does not scale -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10940 | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * related: => #10940 Comment: Closing this in favor of #10940, which has an example showing the problem mentined in comment:5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 10:27:20 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 10:27:20 -0000 Subject: [GHC] #10940: Random number chosen by openTempFile is always 1804289383846930886 In-Reply-To: <046.6c26c2e1a6caf8aeb8abfcc47da92577@haskell.org> References: <046.6c26c2e1a6caf8aeb8abfcc47da92577@haskell.org> Message-ID: <061.a030fa88caf361fd9340ec4a1c16b18a@haskell.org> #10940: Random number chosen by openTempFile is always 1804289383846930886 -------------------------------------+------------------------------------- Reporter: andersk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9058 | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * cc: slyfox (added) * related: => #9058 Comment: The code for `openTempFile` was added in f510c7cac5b2e9afe0ebde2766a671c59137f3cc (#9058). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 10:52:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 10:52:52 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.a903aedd665cfca22630d3d57ade7139@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ----------------------------------------+------------------------------- Comment (by edmund): So the stage1 compiler builds a stage2 compiler which fails when building anything at all. But the stage1 compiler builds a hello.hs that works (comment 10, above). Would it be possible to run the testsuite on the stage1 compiler, with various optimisation options, to get an idea of what the stage1 compiler can and cannot do? That might lead to a simpler test case than GHC itself, or there might be some interesting pattern in the failures. Just a suggestion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 11:33:34 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 11:33:34 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.f05ed9384c820d9fb16c2c9b5267378f@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.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): -------------------------------------+------------------------------------- Comment (by rwbarton): Thinking about this some more it seems wrong to change the operator used for provided constraints, since the whole type of a constructor in a GADT declaration {{{ data T a where MkT :: (Show a, Show b) => a -> b -> T a }}} should be a unit in the type of a pattern {{{ pattern MkT :: (Show a, Show b) => a -> b -> T a }}} Or looking at it another way, the fields of type `a` and `b`, despite being provided by a match on the pattern, appear in negative position in the type; so the provided context `(Show a, Show b)` should also appear in negative position too, which is the normal role of `=>`. So if we're going to use two different operators here, the non-`=>` one should mark the required constraints, like {{{ pattern P :: (Eq a, Num a) ??> (Show a, Show b) => b -> T a }}} But this is somehow a bit less appealing to me, since I don't see how this other operator `??>` could make sense in any other context. We have provided constraints, provided values (the values bound by a matching pattern), required constraints, but no required values. That's PatternFamilies. However there is no proposed syntax for the type of a pattern family there. It might be worthwhile to try to solve that problem at the same time. For example a syntax that would accommodate required arguments (while being rather ugly and perhaps unparseable) could be {{{ pattern ReqC => ReqVal1 -> ReqVal2 -> P :: ProvC => ProvVal1 -> ProvVal2 -> Res }}} This also happens to be backwards compatible in the case where `ReqC => ReqVal1 -> ReqVal2 -> ` is empty. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 11:42:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 11:42:15 -0000 Subject: [GHC] #10935: More unused and non-deprecated warning flags In-Reply-To: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> References: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> Message-ID: <058.f342e442820c2d44574d090b55035baf@haskell.org> #10935: More unused and non-deprecated warning flags -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10752, #8176 | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * related: #10752 => #10752, #8176 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 11:46:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 11:46:22 -0000 Subject: [GHC] #10941: Large heap address space breaks valgrind Message-ID: <046.bc51ed910abe4837d799aba373b5c152@haskell.org> #10941: Large heap address space breaks valgrind -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.11 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #9706 Differential Rev(s): | -------------------------------------+------------------------------------- It seems that programs compiled with a GHC `--enable-large-address-space` (see #9706) no longer run under valgrind, which is a pitty, as that is useful to get more reliable numbers out of nofib. It fails with `internal error: getMBlock: mmap: Invalid argument` This bug is a general ?Can we do anything about this?. In particular, is there a possibility to make this a RTS option instead of a compile time option? Or maybe it is possible to talk to the valgrind authors if they can support such large allocations? If neither, can we maybe extend the error message to say ?If you are using a tool like valgrind, you might want to recompile the compiler with `--disable-large-address-space.? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 11:54:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 11:54:23 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.ecaaba60576568a3c20000bda098a7d7@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ----------------------------------------+------------------------------- Comment (by rwbarton): You can certainly try to run the test suite against the stage1 compiler, see Building/RunningTests/Running. {{{ make TEST_HC=/path/to/ghc/inplace/bin/ghc-stage1 }}} I don't think we mark tests for whether they are expected to work under the stage1 compiler, so there will be a lot of false negatives (anything involving ghci or TH). But you could compare the failures to those on x86_64 and hopefully there will be some new, small tests that fail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 12:10:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 12:10:16 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.543ce917d694b9387e0694fa1d1ec078@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.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): -------------------------------------+------------------------------------- Comment (by rwbarton): I'm actually coming around to the original syntax, but with the constraints reversed as in comment:5. It's not so bad and it can be extended to support required values too, using an empty provided constraint if needed. {{{ pattern IsMember :: Ord a => a -> () => Set a pattern IsMember val <- (member val -> True) pattern Lookup :: Ord k => k -> () => v -> Map k v pattern Lookup key val <- (lookup key -> Just val) }}} I have to say writing these pattern signatures was a bit mind-bending, but I don't think that's because of the particular concrete syntax involving constraints. I still feel that maybe we ought to be able to do better, but I consider this solution at least satisfactory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 12:48:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 12:48:01 -0000 Subject: [GHC] #10942: CPP pragma ignored if top comments and Opt_KeepRawTokenStream Message-ID: <044.3dc1d52508bafa33dfb53526bcdd251c@haskell.org> #10942: CPP pragma ignored if top comments and Opt_KeepRawTokenStream -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- HaRe sets `Opt_KeepRawTokenStream` to be able to round trip the source code. If we have a module starting {{{#!hs {- A normal comment, to check if we can still pick up the CPP directive after it. -} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE CPP #-} -- Check that we can parse a file which requires CPP module BCpp where bob :: Int -> Int -> Int #if __GLASGOW_HASKELL__ > 704 bob x y = x + y #else bob x y = x + y * 2 #endif }}} then the call to `loadTargets` via the GHC API fails with `SourceError (lexical error at character 'i'` which is the normal error when `#if` is hit and CPP is not enabled. If `Opt_KeepRawTokenStream` is not set it loads without problems. Also, files using CPP but not having a top comment load properly too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 13:00:34 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 13:00:34 -0000 Subject: [GHC] #10918: Float once-used let binding into a recursive function In-Reply-To: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> References: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> Message-ID: <061.35c61a5b1350c928092682d20c9cd873@haskell.org> #10918: Float once-used let binding into a recursive function -------------------------------------+------------------------------------- Reporter: nomeata | Owner: 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by simonpj): Well, currently `-flate-dmd-anal` is an `-O2` thing, which also seems appropriate here. It's also possible (measure!) that a late run of arity analysis might be able to exploit information that was not available early; that might have performance benefits all by itself. That was the reason we introduced `-flate-dmd-anal`, for example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 13:06:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 13:06:17 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.5cee5395d34041ee0b7d0f02e2c4901c@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.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): -------------------------------------+------------------------------------- Comment (by simonpj): I agree: using the current syntax with reversed constraints seems like the best option right now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 13:14:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 13:14:39 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.c4c2241d6f7d6ef2856f3e24f27cc7ba@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.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): -------------------------------------+------------------------------------- Comment (by rodlogic): Replying to [comment:11 rodlogic]: > Sorry to inject myself here, but what about: > {{{ > pattern P :: (Required b) => b -> T a => (Provided a) > }}} > > I.e. required constraints come before and provided after. Feeling stupid here now... this is the original proposal! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 13:17:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 13:17:15 -0000 Subject: [GHC] #10942: CPP pragma ignored if top comments and Opt_KeepRawTokenStream In-Reply-To: <044.3dc1d52508bafa33dfb53526bcdd251c@haskell.org> References: <044.3dc1d52508bafa33dfb53526bcdd251c@haskell.org> Message-ID: <059.5cdb0510426df27d717493df40ad37e2@haskell.org> #10942: CPP pragma ignored if top comments and Opt_KeepRawTokenStream -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Description changed by alanz: Old description: > HaRe sets `Opt_KeepRawTokenStream` to be able to round trip the source > code. > > If we have a module starting > > {{{#!hs > {- > > A normal comment, to check if we can still pick up the CPP directive > after it. > > -} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE CPP #-} > -- Check that we can parse a file which requires CPP > module BCpp where > bob :: Int -> Int -> Int > #if __GLASGOW_HASKELL__ > 704 > bob x y = x + y > #else > bob x y = x + y * 2 > #endif > > }}} > > then the call to `loadTargets` via the GHC API fails with > > `SourceError (lexical error at character 'i'` which is the normal error > when `#if` is hit and CPP is not enabled. > > If `Opt_KeepRawTokenStream` is not set it loads without problems. > > Also, files using CPP but not having a top comment load properly too. New description: HaRe sets `Opt_KeepRawTokenStream` to be able to round trip the source code. If we have a module starting {{{#!hs {- A normal comment, to check if we can still pick up the CPP directive after it. -} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE CPP #-} -- Check that we can parse a file which requires CPP module BCpp where bob :: Int -> Int -> Int #if __GLASGOW_HASKELL__ > 704 bob x y = x + y #else bob x y = x + y * 2 #endif }}} then the call to `load LoadAllTargets` via the GHC API fails with `SourceError (lexical error at character 'i'` which is the normal error when `#if` is hit and CPP is not enabled. If `Opt_KeepRawTokenStream` is not set it loads without problems. Also, files using CPP but not having a top comment load properly too. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 13:20:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 13:20:44 -0000 Subject: [GHC] #10939: Odditites regarding Any and typeclasses. In-Reply-To: <044.726c85b3e4519c1a60e9739c86554109@haskell.org> References: <044.726c85b3e4519c1a60e9739c86554109@haskell.org> Message-ID: <059.42d3d24cc1a676859849440775322c93@haskell.org> #10939: Odditites regarding Any and typeclasses. -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: fixed | 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): -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: Confirmed that the first example works, too. I'm not sure what the fix is, though. I'm closing as fixed. If this is holding you up and you want the fix in 7.10.3, reopen and we can try to learn more. Thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 13:33:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 13:33:28 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.e95c2bf323425563d2b378713dc23204@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.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): -------------------------------------+------------------------------------- Comment (by goldfire): Concur with comment:14. Keep current syntax, but with reversed ordering. Specifying only one constraint would now indicate a '''required''' constraint. On a separate note, the parallelism with GADT syntax discussed in comment:12 is already broken. Consider {{{#!hs data G a where MkG :: G Int pattern P :: G Int pattern P = MkG }}} The pattern and the data constructor have '''different''' static semantics. Specifically, {{{#!hs -- this works: ctor :: G a -> a ctor MkG = 5 -- this doesn't: pat :: G a -> a pat P = 5 }}} This is because a non-uniformity in the return type of a pattern is taken as a required equality constraint, not a provided equality constraint. The top set of definitions is equivalent to {{{#!hs data G a where MkG :: a ~ Int => G a pattern P :: {- required -} a ~ Int => {- provided -} () => G a pattern P = MkG }}} This was a design decision made in pattern synonym typing. I don't love this decision, but I can't quite argue against it either. It's one more way in which we must be honest that the things appearing after `MkG ::` and `P ::` are '''not''' types, but type-like specifications with a very specific interpretation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 13:35:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 13:35:44 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.7969805da0175df8373e7fd0e47082b1@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.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): -------------------------------------+------------------------------------- Comment (by simonpj): If anyone feels able to improve the user-manual documentation in the light of this discussion, it would be great to do so. Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 13:42:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 13:42:30 -0000 Subject: [GHC] #8583: Associated pattern synonyms In-Reply-To: <045.39184734af9bc44765e305261b59a6ed@haskell.org> References: <045.39184734af9bc44765e305261b59a6ed@haskell.org> Message-ID: <060.bdab04f7274e49aa0a5295587b3a9745@haskell.org> #8583: Associated pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: 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: 5144 | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: carter (added) Comment: Definitely would be useful, but this might require a new implementation strategy since it gives pattern synonyms essentially first-class status, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 13:47:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 13:47:10 -0000 Subject: [GHC] #10943: Suggest PatternSynonyms Message-ID: <047.ef0761bfe320d77c0d572f9c36753978@haskell.org> #10943: Suggest PatternSynonyms -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- If I try to compile a pattern type signature like {{{ pattern P :: G Int }}} without having enabled `PatternSynonyms` then I get the error {{{ Pat.hs:8:1: Invalid type signature: pattern P :: G Int Should be of form :: }}} We could easily work out to suggest that the user enable `PatternSynonyms` here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 13:47:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 13:47:53 -0000 Subject: [GHC] #10942: CPP pragma ignored if top comments and Opt_KeepRawTokenStream In-Reply-To: <044.3dc1d52508bafa33dfb53526bcdd251c@haskell.org> References: <044.3dc1d52508bafa33dfb53526bcdd251c@haskell.org> Message-ID: <059.3204db251896d84eecce701f533ef868@haskell.org> #10942: CPP pragma ignored if top comments and Opt_KeepRawTokenStream -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by alanz): It seems the simplified parser in `HeaderInfo.getOptions'` needs to to skip over any vanilla comments seen and keep going. Alternatively `Opt_KeepRawTokenStream` must be unset in `HeaderInfo.getOptions` before calling `getToks`. I suspect the latter will be the simplest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 13:53:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 13:53:15 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.894a5a94c65312d008f0ca38eea569ab@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.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): -------------------------------------+------------------------------------- Comment (by rwbarton): That's kind of weird. But you can write {{{ pattern P :: a ~ Int => () => G a -- current syntax; (Int ~ a) is provided constraint pattern P = MkG }}} and then `pat` is accepted... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 14:15:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 14:15:33 -0000 Subject: [GHC] #10918: Float once-used let binding into a recursive function In-Reply-To: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> References: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> Message-ID: <061.86ec56c65039e74548492e34e5efd497@haskell.org> #10918: Float once-used let binding into a recursive function -------------------------------------+------------------------------------- Reporter: nomeata | Owner: 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by nomeata): Prelimary results: In `queens` allocation goes down by 17%, due to this change to the core (which is pretty much a poster child for what I am aiming for) {{{#!hs go = \ (ds3 :: [[Int]]) -> case ds3 of _ [Occ=Dead] { [] -> [] @ [Int]; : y ys -> - let { - z :: [[Int]] - [LclId, Str=DmdType] - z = go ys } in letrec { go1 [Occ=LoopBreaker] :: [Int] -> [[Int]] [LclId, Arity=1, Str=DmdType ] go1 = \ (ds4 :: [Int]) -> case ds4 of _ [Occ=Dead] { - [] -> z; + [] -> go ys; : y1 ys1 -> }}} Multiple similar changes in cryptarithm2, 8% improved allocation. But in paraffins something goes very wrong, +1290% allocation. Needs more investigation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 15:24:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 15:24:27 -0000 Subject: [GHC] #10918: Float once-used let binding into a recursive function In-Reply-To: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> References: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> Message-ID: <061.73d31ef5201ae1c5a00e792c43a3de27@haskell.org> #10918: Float once-used let binding into a recursive function -------------------------------------+------------------------------------- Reporter: nomeata | Owner: 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by nomeata): One effect, which might or might not be the reason for the paraffin regression (but certainly obscures the view) is that an inlined expression seems to float out further than a let-bound expression. More explicitly, consider this code: {{{#!hs foo :: [[Bool]] -> [Bool] --foo input = [ not y | (x:xs) <- input, y <- (x:xs) ] foo [] = [] foo (y:ys) = case y of [] -> foo ys (x:xs) -> let z = foo ys in let go [] = z go (y':ys') = not y' : go ys' in not x : go xs }}} With my change, this will be turned into {{{#!hs foo :: [[Bool]] -> [Bool] --foo input = [ not y | (x:xs) <- input, y <- (x:xs) ] foo [] = [] foo (y:ys) = case y of [] -> foo ys (x:xs) -> let go [] = foo ys go (y':ys') = not y' : go ys' in not x : go xs }}} If the compiler would stop here, I?d be happy. But instead, something interesting happens. In the pristine case, the binding to `z` is not affected by the level set: {{{ (let { > > = T10918a.foo ys } in }}} whereas the plain `foo ys` expression got wrapped in a binding and is assigned a level further out: {{{ [] -> let { > > = T10918a.foo ys } in lvl; }}} The `F<1,1>` is ? as expected ? the binding site of `ys`. But now the first invocation of `foo ys` is in scope of the `lvl`, CSE happens, the variable is no longer used at most once, it cannot be inlined back and we end up with {{{#!hs foo :: [[Bool]] -> [Bool] --foo input = [ not y | (x:xs) <- input, y <- (x:xs) ] foo [] = [] foo (y:ys) = let lvl = foo ys case y of [] -> lvl (x:xs) -> let go [] = lvl go (y':ys') = not y' : go ys' in not x : go xs }}} which is not what I want to see. So the issue here seems to be that under some circumstances, an `e` in `C[e]` can be floated out further than `let z = e in C[z]`. (All this does not look too server in this case, but it happens a few times in paraffin, so I hope that this is actually related to the allocation increase.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 16:56:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 16:56:00 -0000 Subject: [GHC] #10938: DeriveAnyClass + deriving Bifunctor causes GHC panic In-Reply-To: <048.05bdc8a9acaff098bc4ba561c4725449@haskell.org> References: <048.05bdc8a9acaff098bc4ba561c4725449@haskell.org> Message-ID: <063.97154bc9ce8228d213c171053c5f6f06@haskell.org> #10938: DeriveAnyClass + deriving Bifunctor causes GHC panic -------------------------------------+------------------------------------- Reporter: erantapaa | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Keywords: Resolution: duplicate | DeriveAnyClass Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #9968 | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by dreixel): * status: new => closed * resolution: => duplicate * related: => #9968 Comment: Thanks for reporting, but this is already reported as #9968. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 17:07:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 17:07:38 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.6cc5974fbcedc4eb06ef336c9fc078d6@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.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): -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:18 rwbarton]: > That's kind of weird. But you can write > {{{ > pattern P :: a ~ Int => () => G a -- current syntax; (Int ~ a) is provided constraint > pattern P = MkG > }}} > and then `pat` is accepted... Sure you can. But such a `P` is different from the one I defined. Very, very subtly different, but indeed different: matching on your `P` tells the type checker that `a ~ Int`, whereas matching on my `P` asks the type checker to prove `a ~ Int`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 17:11:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 17:11:15 -0000 Subject: [GHC] #10941: Large heap address space breaks valgrind In-Reply-To: <046.bc51ed910abe4837d799aba373b5c152@haskell.org> References: <046.bc51ed910abe4837d799aba373b5c152@haskell.org> Message-ID: <061.d577d1bd026ea44ccb50b47eb65fa6a4@haskell.org> #10941: Large heap address space breaks valgrind -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by ezyang): Related: http://stackoverflow.com/questions/8644234/why-is-valgrind- limited-to-32-gb-on-64-bit-architectures -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 17:35:29 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 17:35:29 -0000 Subject: [GHC] #8583: Associated pattern synonyms In-Reply-To: <045.39184734af9bc44765e305261b59a6ed@haskell.org> References: <045.39184734af9bc44765e305261b59a6ed@haskell.org> Message-ID: <060.9fff4541e755eee1ecd0845ac068aa33@haskell.org> #8583: Associated pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: 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: 5144 | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by goldfire): Yes yes yes. I want this! But it's tricky, even forgetting about implementation for the moment. Let's pretend that all types have to be explicit for a sec, and I'll continue the example from the original post: {{{#!hs headOfList :: forall a. [a] -> Maybe a headOfList (Nil @[] @a) = Nothing @a headOfList (Cons @[] @a x _) = Just x }}} There's something very strange going on here. It looks, in those patterns, that we're pattern-matching on a ''type''. This, of course, is not allowed, because types are erased. Upon further inspection, we're not really doing this. The first type parameter to `Nil` and `Cons` are ''inputs''. Contrast to the second type parameter and the term parameters (to `Cons`), which are ''outputs''. Another way to see this is to think about how `Nil @[] @a` and `Nil @Seq @a` are both valid patterns, but `Nil @l @Int` would be terrible, as it requires doing a type check at runtime. So I wonder if implementing this without terrible hacks might depend on PatternFamilies which (despite its name) allows for a mix of inputs and outputs in pattern synonyms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 17:50:34 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 17:50:34 -0000 Subject: [GHC] #10934: Iface type variable out of scope In-Reply-To: <047.1cb3ee5ab1249c924fa43e250146dc6f@haskell.org> References: <047.1cb3ee5ab1249c924fa43e250146dc6f@haskell.org> Message-ID: <062.fc0bb3f1fc4ba2d0321109650ab46783@haskell.org> #10934: Iface type variable out of scope -------------------------------------+------------------------------------- Reporter: mjmrotek | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: interface Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | polykinds/T10934 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by mjmrotek): Thanks! Just for the record, in case someone runs into a similar problem: a "workaround" for this bug in the particular case I've posted was just to remove the offending type class, as its method can be implemented by just having a regular function pattern match on Rec. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 17:55:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 17:55:43 -0000 Subject: [GHC] #8583: Associated pattern synonyms In-Reply-To: <045.39184734af9bc44765e305261b59a6ed@haskell.org> References: <045.39184734af9bc44765e305261b59a6ed@haskell.org> Message-ID: <060.2ee74f5510573df6245bafa55f104d05@haskell.org> #8583: Associated pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: 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: 5144 | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by nomeata): > Upon further inspection, we're not really doing this. The first type parameter to Nil and Cons are inputs This seems to be #9671 in disguise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 18:07:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 18:07:14 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.c27786c4d304fb7aa3d8e75041ff38b0@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ----------------------------------------+------------------------------- Comment (by edmund): Alternatively, would the following procedure work? - Build the unmodified source in the usual way, all stages. - Run the testsuite to give a basis for comparison. - Set stage=2 in build.mk. - Reconfigure: ./configure --disable-unregisterised - make - Run the testsuite again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 18:39:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 18:39:50 -0000 Subject: [GHC] #10942: CPP pragma ignored if top comments and Opt_KeepRawTokenStream In-Reply-To: <044.3dc1d52508bafa33dfb53526bcdd251c@haskell.org> References: <044.3dc1d52508bafa33dfb53526bcdd251c@haskell.org> Message-ID: <059.fe4ecefba17b54f843a6991cdedbff45@haskell.org> #10942: CPP pragma ignored if top comments and Opt_KeepRawTokenStream -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by alanz): A workaround (as now in HaRe) is to only set the `Opt_KeepRawTokenStream` flag in the cached `DynFlags` in the `ModSummary` before invoking `parseModule` {{{#!hs tweakModSummaryDynFlags :: GHC.ModSummary -> GHC.ModSummary tweakModSummaryDynFlags ms = let df = GHC.ms_hspp_opts ms in ms { GHC.ms_hspp_opts = GHC.gopt_set df GHC.Opt_KeepRawTokenStream } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 20:34:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 20:34:01 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.f65d269d9227261422307eb85a9cf470@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ----------------------------------------+------------------------------- Comment (by edmund): By the way, what BuildFlavour are you using? https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend says: "GHC HEAD now requires LLVM 3.6.x" https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796343 says: "arm64 has some (many) problems with older llvm such as the currently Debian default one. I tried to reproduce this (really nice) bug report, and I succeeded with llvm-3.4, 3.5 and 3.6." What's the best way of building GHC without LLVM? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 21:12:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 21:12:25 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.61352cb5d88beb1b0c8ffc42f804e427@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ----------------------------------------+------------------------------- Comment (by erikd): GHC builds fine on arm64 in un-registerised mode. I haven't built any packages, but it should just work. The problem in this ticket is only about registerised mode (See https://ghc.haskell.org/trac/ghc/wiki/Building/Unregisterised). The only (main?) problem with un-registerised mode is that the compiler and its executables are far slower than I have what seem to be working ghc-7.8.4 and ghc-7.10.2 compilers (un- registerised) on Debian. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 21:23:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 21:23:13 -0000 Subject: [GHC] #10944: powModInteger slower than computing pow and mod separately Message-ID: <043.b0fdf686fc294a9dbe673ff52b315c89@haskell.org> #10944: powModInteger slower than computing pow and mod separately -------------------------------------+------------------------------------- Reporter: iago | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.8.3 Libraries | Keywords: integer-gmp | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- {{{#!hs module Foo where import GHC.Integer.GMP.Internals ( powModInteger ) test1, test2 :: Integer -> Integer -> Int -> Integer test1 a b c = (a ^ b) `mod` (2^c) test2 a b c = powModInteger a b (2^c) }}} I was expecting `test2` to perform better than `test1`, but I'm getting quite the opposite: the use of `powModInteger` seems to be several orders of magnitude slower. I have tested this with GHC 7.10.2 and integer-gmp 1.0.0.0 too, with similar results. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 21:34:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 21:34:17 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.890d4828eac4ae086823ed1b647e5ced@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ----------------------------------------+------------------------------- Comment (by edmund): Have you had any LLVM errors, such as the segfault in 'Greedy Register Allocator'? If you haven't, it might be because you're using the "native code generator" rather than the "LLVM code generator". That might be because of your BuildFlavour. Which BuildFlavour are you using? How are you building GHC, exactly? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 7 21:43:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Oct 2015 21:43:27 -0000 Subject: [GHC] #10940: Random number chosen by openTempFile is always 1804289383846930886 In-Reply-To: <046.6c26c2e1a6caf8aeb8abfcc47da92577@haskell.org> References: <046.6c26c2e1a6caf8aeb8abfcc47da92577@haskell.org> Message-ID: <061.d55336fd39dcd133e9862569967797f5@haskell.org> #10940: Random number chosen by openTempFile is always 1804289383846930886 -------------------------------------+------------------------------------- Reporter: andersk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9058 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by slyfox): I agree it's a problem. Posting '''ghc-7.8.4''' results for comparison: {{{ $ runhaskell a.hs "/tmp/47" $ runhaskell a.hs "/tmp/59" $ runhaskell a.hs "/tmp/71" $ runhaskell a.hs "/tmp/83" $ runhaskell a.hs "/tmp/95" $ runhaskell a.hs "/tmp/107" }}} (nice +12 steps) The question is what to use so it would work on modern systems. I see the following routes: 1. use something portable and insecure like seeding with '''srand(time())''': will not behave nicely after '''fork()''' from haskell program, still predictable 2. introduce OS-specific branches to use '''mkstemp''' / '''mkostemp''' / '''mkostemps''' / '''GetTempFileName''' / '''GetTempPath'''. Is there a nicer way? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 01:28:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 01:28:08 -0000 Subject: [GHC] #10733: Improving the error message for type variable ambiguity In-Reply-To: <049.e68ae3d7f8aaef94b3cdeb692d3e5ac5@haskell.org> References: <049.e68ae3d7f8aaef94b3cdeb692d3e5ac5@haskell.org> Message-ID: <064.5379860dbf064eb8480647fddbdc5753@haskell.org> #10733: Improving the error message for type variable ambiguity -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: kanetw Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1182 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"7b443bb1df8f7f0a6b3124537590aa655a9300cd/ghc" 7b443bb1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7b443bb1df8f7f0a6b3124537590aa655a9300cd" Improve error messages for ambiguous type variables Improved error messages are only printed when the old message would be "No instance for...", since they're not as helpful for "Could not deduce..." No special test case as error messages are tested by other tests already. Signed-off-by: David Kraeutmann Reviewed By: austin, goldfire Differential Revision: https://phabricator.haskell.org/D1182 GHC Trac Issues: #10733 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 01:35:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 01:35:58 -0000 Subject: [GHC] #10747: Infix pattern synonyms fail to parse (regression) In-Reply-To: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> References: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> Message-ID: <063.b272c47c2deb68b736d5a31072d6df45@haskell.org> #10747: Infix pattern synonyms fail to parse (regression) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: mpickering Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | PatternSynonyms 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:D1295 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"69a6e4258786894578ffed2a1d907a74c52d779b/ghc" 69a6e425/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="69a6e4258786894578ffed2a1d907a74c52d779b" Allow non-operator infix pattern synonyms For example ``` pattern head `Cons` tail = head : tail ``` Reviewed By: goldfire, austin Differential Revision: https://phabricator.haskell.org/D1295 GHC Trac Issues: #10747 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 01:35:59 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 01:35:59 -0000 Subject: [GHC] #10498: "if ... then \case -> else ..." causes a "missing else clause" error In-Reply-To: <050.28cad0c5bb9248828a1f63b683a53853@haskell.org> References: <050.28cad0c5bb9248828a1f63b683a53853@haskell.org> Message-ID: <065.33381d54bcc816c3c1c9494f9ac13863@haskell.org> #10498: "if ... then \case -> else ..." causes a "missing else clause" error -------------------------------------+------------------------------------- Reporter: dramforever | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1309 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"e2b579e8d77357e8b36f57d15daead101586ac8e/ghc" e2b579e8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e2b579e8d77357e8b36f57d15daead101586ac8e" Parser: revert some error messages to what they were before 7.10 Among doing other things, Phab:D201 (bc2289e13d9586be087bd8136943dc35a0130c88) tried to improve the error messages thrown by the parser. For example a missing else clause now prints "parse error in if statement: else clause empty" instead of "parse error (possibly incorrect indentation or mismatched brackets)". Some error messages got much worse however (see tests), and the result seems to be a net negative. Although not entirely satisfactory, this commits therefore reverts those parser changes. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1309 GHC Trac Issues: #10498 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 03:43:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 03:43:46 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.c36185667ef2beb073d19129169be2dc@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ----------------------------------------+------------------------------- Comment (by erikd): Oh wow, that is embarrassing! Rechecked the `mk/build.mk` file and found that `BuildFlavour` was not set. Not sure what the hell it was building. Anyway, setting `BuildFlavour=quick-llvm` I then get: {{{ "inplace/bin/ghc-stage1" -static -O0 -H64m -fllvm -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/PrimOps.cmm -o rts/dist/build/PrimOps.o 0 libLLVM-3.6.so.1 0x0000007f787be130 llvm::sys::PrintStackTrace(_IO_FILE*) + 48 Stack dump: 0. Program arguments: /usr/bin/llc-3.6 -O3 -relocation-model=static /tmp/ghc17942_0/ghc_5.bc -o /tmp/ghc17942_0/ghc_6.lm_s --enable- tbaa=true 1. Running pass 'Function Pass Manager' on module '/tmp/ghc17942_0/ghc_5.bc'. 2. Running pass 'Greedy Register Allocator' on function '@"stg_atomically_frame_info$def"' `llc-3' failed in phase `LLVM Compiler'. (Exit code: -11) rts/ghc.mk:246: recipe for target 'rts/dist/build/PrimOps.o' failed }}} Seeing LLVM 3.6 break like this, I hacked `configure.ac` to accept `llvm-3.7` and then got: {{{ You are using a new version of LLVM that hasn't been tested yet! We will try though... /usr/bin/opt-3.7: /tmp/ghc24454_0/ghc_3.ll:22:21: error: expected comma after load's type %lnI = load i64** %Sp_Var ^ `opt-3' failed in phase `LLVM Optimiser'. (Exit code: 1) }}} It seems the LLVM IR has changed between llvm-3.6 and llvm-3.7 (again). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 06:48:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 06:48:19 -0000 Subject: [GHC] #10432: panic with kind polymorphism In-Reply-To: <053.23d99653504b87c50e0b0230cb7a3ff8@haskell.org> References: <053.23d99653504b87c50e0b0230cb7a3ff8@haskell.org> Message-ID: <068.18eb8b89f56c27fce57245636ac3dbd6@haskell.org> #10432: panic with kind polymorphism -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by jstolarek): I just tested Simon's code and it works in HEAD. Originally reported code results in type ambiguity error (well, kind ambiguity in fact). 403cfc9187b9df560768bb809f4d280fb999639c added some comments about this ticket but I don't think that any commit explicitly addressed issues reported here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 09:09:36 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 09:09:36 -0000 Subject: [GHC] #10945: Typed Template Haskell splices broken in HEAD (7.11) Message-ID: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> #10945: Typed Template Haskell splices broken in HEAD (7.11) -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template | Version: 7.11 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- In the latest HEAD (e2b579e8d77357e8b36f57d15daead101586ac8e) when I say: {{{#!hs $$(return [ SigD (mkName "m") (ForallT [PlainTV (mkName "a")] [] (AppT (AppT ArrowT (VarT (mkName "a"))) (VarT (mkName "a")))) , FunD (mkName "m") [Clause [VarP (mkName "x")] (NormalB (VarE (mkName "x"))) []] ]) }}} I get: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151007 for x86_64-unknown-linux): runRnSplice $$(return [SigD (mkName "m") (ForallT [PlainTV (mkName "a")] [] (AppT (AppT ArrowT (VarT (mkName "a"))) (VarT (mkName "a")))), FunD (mkName "m") [Clause [VarP (mkName "x")] (NormalB (VarE (mkName "x"))) []]]) }}} This code compiles correctly in GHC 7.10.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 09:12:36 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 09:12:36 -0000 Subject: [GHC] #10946: Typed hole inside typed Template Haskell bracket causes panic Message-ID: <048.bb931422119631f05ab09abe14bd4c46@haskell.org> #10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template | Version: 7.10.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- When I say: {{{#!hs m :: a -> a m x = $$([||_||]) }}} I get: {{{ T10946.hs:47:13:ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): No skolem info: a_apJ[sk] }}} This happens both with GHC 7.10.1 and latest HEAD (e2b579e8d77357e8b36f57d15daead101586ac8e). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 09:17:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 09:17:31 -0000 Subject: [GHC] #10946: Typed hole inside typed Template Haskell bracket causes panic In-Reply-To: <048.bb931422119631f05ab09abe14bd4c46@haskell.org> References: <048.bb931422119631f05ab09abe14bd4c46@haskell.org> Message-ID: <063.2471bef813425a2e63ef536d791cb970@haskell.org> #10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by jstolarek): This error is raised in `TcErrors.getSkolemInfo` called from `TcErrors.mkHoleError`. Quick look at the code tells me that "implication constraints" are expected to be non-empty but they are. Are implication constraints things that come in the contexts, ie. everything before a `=>`? Why are they expected to be non-empty? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 09:35:22 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 09:35:22 -0000 Subject: [GHC] #10945: Typed Template Haskell splices broken in HEAD (7.11) In-Reply-To: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> References: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> Message-ID: <063.4e34c0de13dd27400d7db4d707d5942d@haskell.org> #10945: Typed Template Haskell splices broken in HEAD (7.11) -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: simonpj (added) Comment: The sequence of calls that leads to this panic goes like this: `TcRnDriver.tc_rn_src_decls` -> `RnSplice.rnTopSpliceDecls` -> `RnSplice.runRnSplice` and in `runRnSplice` we hit `HsTypedSplice` alternative in the case that scrutinizes `splice'`. Looking at git blame I conjecture that this bug was introduced in f46360ed7139ff25741b381647b0a0b6d1000d84 (but would need to bisect to verify), which was a fix for #10047. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 10:09:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 10:09:51 -0000 Subject: [GHC] #10943: Suggest PatternSynonyms In-Reply-To: <047.ef0761bfe320d77c0d572f9c36753978@haskell.org> References: <047.ef0761bfe320d77c0d572f9c36753978@haskell.org> Message-ID: <062.ba2ab90c129b2bb3ad836f68dc230520@haskell.org> #10943: Suggest PatternSynonyms -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): -------------------------------------+------------------------------------- Comment (by simonpj): Good idea. Should not be hard for a newcomer. Would someone like to tackle this? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 10:23:30 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 10:23:30 -0000 Subject: [GHC] #10943: Suggest PatternSynonyms In-Reply-To: <047.ef0761bfe320d77c0d572f9c36753978@haskell.org> References: <047.ef0761bfe320d77c0d572f9c36753978@haskell.org> Message-ID: <062.e6c9c01aef7071d175c7f730f49748eb@haskell.org> #10943: Suggest PatternSynonyms -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): -------------------------------------+------------------------------------- Changes (by nomeata): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 10:43:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 10:43:23 -0000 Subject: [GHC] #9968: DeriveAnyClass fails on multi-parameter type classes In-Reply-To: <047.651a00b270696920750ca655201f4d2f@haskell.org> References: <047.651a00b270696920750ca655201f4d2f@haskell.org> Message-ID: <062.c656ac3869fe6897696fc5feb4957972@haskell.org> #9968: DeriveAnyClass fails on multi-parameter type classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9821 | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by simonpj): * cc: kosmikus (added) Comment: Adding Andres, the king of generics. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 10:45:02 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 10:45:02 -0000 Subject: [GHC] #9968: DeriveAnyClass fails on multi-parameter type classes In-Reply-To: <047.651a00b270696920750ca655201f4d2f@haskell.org> References: <047.651a00b270696920750ca655201f4d2f@haskell.org> Message-ID: <062.b815d8d79886208fe14640445af8206f@haskell.org> #9968: DeriveAnyClass fails on multi-parameter type classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9821 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by simonpj): See also #10938 for another example of this bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 12:14:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 12:14:25 -0000 Subject: [GHC] #10945: Typed Template Haskell splices broken in HEAD (7.11) In-Reply-To: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> References: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> Message-ID: <063.c7bad1d425f27e1f738c253ebe167c23@haskell.org> #10945: Typed Template Haskell splices broken in HEAD (7.11) -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Jan Stolarek ): In [changeset:"f64f7c36ef9395da1cc7b686aaf1b019204cd0fc/ghc" f64f7c3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f64f7c36ef9395da1cc7b686aaf1b019204cd0fc" Tests for #10945 and #10946 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 12:14:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 12:14:25 -0000 Subject: [GHC] #10946: Typed hole inside typed Template Haskell bracket causes panic In-Reply-To: <048.bb931422119631f05ab09abe14bd4c46@haskell.org> References: <048.bb931422119631f05ab09abe14bd4c46@haskell.org> Message-ID: <063.71ec83ff7630472d2c0f067f9075cd26@haskell.org> #10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Jan Stolarek ): In [changeset:"f64f7c36ef9395da1cc7b686aaf1b019204cd0fc/ghc" f64f7c3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f64f7c36ef9395da1cc7b686aaf1b019204cd0fc" Tests for #10945 and #10946 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 12:14:35 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 12:14:35 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package In-Reply-To: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> References: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> Message-ID: <057.9a5be230aa71b79218e37886edd02b1f@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Resolution: | Keywords: AMP, report- | impact 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:D510 -------------------------------------+------------------------------------- Changes (by hvr): * owner: ekmett => * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 12:15:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 12:15:03 -0000 Subject: [GHC] #10945: Typed Template Haskell splices broken in HEAD (7.11) In-Reply-To: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> References: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> Message-ID: <063.e89426a5dc1897edcd49ab37a0ba6a0c@haskell.org> #10945: Typed Template Haskell splices broken in HEAD (7.11) -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10945 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by jstolarek): * testcase: => th/T10945 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 12:15:20 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 12:15:20 -0000 Subject: [GHC] #10946: Typed hole inside typed Template Haskell bracket causes panic In-Reply-To: <048.bb931422119631f05ab09abe14bd4c46@haskell.org> References: <048.bb931422119631f05ab09abe14bd4c46@haskell.org> Message-ID: <063.f1a57fe4992789dc4aaf27f2eb25a287@haskell.org> #10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T10946 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by jstolarek): * testcase: => th/T10946 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 12:15:20 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 12:15:20 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package In-Reply-To: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> References: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> Message-ID: <057.1c2fbbfc8edfada28c0df006726bddf5@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Resolution: wontfix | Keywords: AMP, report- | impact 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:D510 -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => wontfix Comment: (it's not really fixed, more like wontfix for the meantime IMO) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 12:53:26 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 12:53:26 -0000 Subject: [GHC] #10947: nofib-analyze should print per-benchmark-compile time totals Message-ID: <046.e6aa0dcd741ff8a9fe1facb78be23202@haskell.org> #10947: nofib-analyze should print per-benchmark-compile time totals -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: NoFib | Version: 7.11 benchmark suite | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- hvr asked me if htt://perf.haskell.org/ghc could track compilation times, and I said it does not yet, one reason being that nofib reports compilation times on a per-module basis, which is not really helpful in general. If nofib-analyze would report them as a per-benchmark sum, I could likely easily add this information to perf.haskell.org. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 12:54:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 12:54:08 -0000 Subject: [GHC] #10947: nofib-analyze should print per-benchmark-compile time totals In-Reply-To: <046.e6aa0dcd741ff8a9fe1facb78be23202@haskell.org> References: <046.e6aa0dcd741ff8a9fe1facb78be23202@haskell.org> Message-ID: <061.818a4cb46ba2c9b35ba5ece2e055567e@haskell.org> #10947: nofib-analyze should print per-benchmark-compile time totals -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.11 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by hvr): * cc: hvr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 12:57:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 12:57:19 -0000 Subject: [GHC] #10845: Incorrect behavior when let binding implicit CallStack object In-Reply-To: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> References: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> Message-ID: <068.1faf1204bbd51bcb2f28711ca90e3b42@haskell.org> #10845: Incorrect behavior when let binding implicit CallStack object -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10846 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by simonpj): Ah, yes, you are correct. (You can have a nested implication with skolems but no givens; that's important. Here there are no skolems either, and it'd take a little longer to explain why.) Rather than conditionally suppressing the no-given solver for `CallStack`, a better way is probably this. * Remove the auto-solve for `CallStack` (with no givens) altogether. * Instead, look at `TcSimplify.simplifyInfer`. It figures out what to quantify over. At top level (look at `rhs_tclvl`) we don't want to quantify over `CallStack` constraints; instead we want to discharge (solve) them. After getting the constraints back from `approximateWC`, we can simply solve any un-solved `CallStack` constraints. Does that help? I should have though of this first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 13:34:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 13:34:23 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.263a0dceebca164923552fcca4223422@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 5321 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by simonpj): Good idea. And here's an easier way to implement it: replace every (non- trivial) coercion in the program (specifically in cases) with `UnivCo`! That deals with the "sometimes we'll need to type of the result in the cast" question. But we need to take care. If we start with {{{ data T a where T1 :: Bool -> T Bool T2 :: T a f :: T a -> a -> Bool f = /\a (x:T a) (y:a). case x of T1 (c : a~Bool) (z : Bool) -> not (y |> c) T2 -> True }}} If we discard the cast, or turn it into UnivCo we might then wrongly float the not-expression, thus {{{ f = /\a (x:T a) (y:a). let w :: Bool = not (y |> UnivCo a Bool) case x of T1 (c : a~Bool) (z : Bool) -> w T2 -> True }}} This woudl not have happened before, because the 'c' would prevent the not-expression being floated. But if we dump the 'c' it could (utterly bogusly, and risking seg-faults) be floated. So if we are going to radically abbreviate to `UnivCo` or something like it, we should include the free variables of the coercion we have discarded, something like `UnivCo t1 tc [v1,...,vn]`. So we'd get: {{{ f :: T a -> a -> Bool f = /\a (x:T a) (y:a). case x of T1 (c : a~Bool) (z : Bool) -> not (y |> UnivCo a Bool [c]) T2 -> True }}} But now what if `c` was itself bound to a big coercion? Then the `UnivCo` would keep the big coercion alive. But it's ok: we should just substitute for `c` to get {{{ UnivCo a Bool [big-coercion] }}} and now have a magic `UnivCo` optimisation to take the free vars of `big- coercion`: {{{ UnivCo a Bool [v1,..,vn] }}} I think that would do it. We could do this in the desugarer; or even earlier in `setEvBind` in the type checker. In the latter case we'd essentially kill off those big coercions at birth. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 13:42:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 13:42:31 -0000 Subject: [GHC] #10944: powModInteger slower than computing pow and mod separately In-Reply-To: <043.b0fdf686fc294a9dbe673ff52b315c89@haskell.org> References: <043.b0fdf686fc294a9dbe673ff52b315c89@haskell.org> Message-ID: <058.1e60e52c93a5edfe3df0a0262a828b7a@haskell.org> #10944: powModInteger slower than computing pow and mod separately -------------------------------------+------------------------------------- Reporter: iago | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: integer-gmp Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by bgamari): I'm afraid I am unable to reproduce this. Could you provide a concrete test case which quantitatively demonstrates the difference? For the record, I my attempt was, {{{#!hs import GHC.Integer.GMP.Internals ( powModInteger ) main = defaultMain [ bench "test1" $ whnf (\(a,b,c) -> test1 a b c) (5,76,2) , bench "powModInteger" $ whnf (\(a,b,c) -> test2 a b c) (5,76,2) , bench "list test1" $ whnf (sum . map (\(a,b,c) -> test1 a b c)) xs , bench "list test2" $ whnf (sum . map (\(a,b,c) -> test2 a b c)) xs ] xs :: [(Integer, Integer, Int)] xs = do a <- [1..5] b <- [50..60] c <- [2..4] return (a,b,c) test1, test2 :: Integer -> Integer -> Int -> Integer test1 a b c = (a ^ b) `mod` (2^c) test2 a b c = powModInteger a b (2^c) }}} which resulted in, {{{ $ ghc -V The Glorious Glasgow Haskell Compilation System, version 7.10.2 $ ghc -O Hi.hs [1 of 1] Compiling Main ( Hi.hs, Hi.o ) Linking Hi ... $ ./Hi benchmarking test1 time 567.7 ns (562.9 ns .. 571.6 ns) 1.000 R? (0.999 R? .. 1.000 R?) mean 566.7 ns (562.5 ns .. 571.9 ns) std dev 15.85 ns (12.92 ns .. 19.35 ns) variance introduced by outliers: 39% (moderately inflated) benchmarking powModInteger time 440.7 ns (438.4 ns .. 443.3 ns) 1.000 R? (1.000 R? .. 1.000 R?) mean 443.6 ns (440.8 ns .. 446.9 ns) std dev 9.862 ns (8.180 ns .. 12.19 ns) variance introduced by outliers: 29% (moderately inflated) benchmarking list test1 time 97.44 ?s (96.68 ?s .. 98.31 ?s) 0.999 R? (0.999 R? .. 0.999 R?) mean 97.59 ?s (96.58 ?s .. 98.57 ?s) std dev 3.431 ?s (2.833 ?s .. 4.300 ?s) variance introduced by outliers: 35% (moderately inflated) benchmarking list test2 time 76.43 ?s (75.85 ?s .. 76.92 ?s) 0.999 R? (0.999 R? .. 1.000 R?) mean 76.55 ?s (76.08 ?s .. 77.11 ?s) std dev 1.698 ?s (1.412 ?s .. 2.126 ?s) variance introduced by outliers: 18% (moderately inflated) }}} This is the sort of modest speed-up that I would have expected from `powModInteger`. I found similar results with 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 14:10:20 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 14:10:20 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.e95445e5ac1ad128020ecd4ff7a723e1@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ----------------------------------------+------------------------------- Comment (by edmund): That error from opt-3.7 looks like a syntax error in the IR. If there had been a fundamental change in the IR's syntax then it would probably be mentioned in http://llvm.org/releases/3.7.0/docs/ReleaseNotes.html, but I don't see it mentioned there. Also, it says in https://www.reddit.com/r/haskell/comments/3nf3q1/improved_llvm_backend/: "There are tests in LLVM upstream for our needed features (including the new ones in LLVM 3.6+), so hopefully the scope for regressions is lower (indeed, crude hacks simply increase the cost of supporting it.) In fact, LLVM 3.7.0 worked perfectly on release, and we did some prerelease testing too." So I wouldn't be so sure that the problem you're seeing there is caused by the IR changing. Can you try using GHC with llvm-3.7 on x86_64? In general, an LLVM load instruction does contain at least one comma, I think (http://llvm.org/docs/LangRef.html#id201), so the line you quoted looks suspicious. Can you get GHC to generate some more IR and see what the other loads look like? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 14:22:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 14:22:44 -0000 Subject: [GHC] #10944: powModInteger slower than computing pow and mod separately In-Reply-To: <043.b0fdf686fc294a9dbe673ff52b315c89@haskell.org> References: <043.b0fdf686fc294a9dbe673ff52b315c89@haskell.org> Message-ID: <058.748eba20cff5d2de3679f8f425b82932@haskell.org> #10944: powModInteger slower than computing pow and mod separately -------------------------------------+------------------------------------- Reporter: iago | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: integer-gmp Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by iago): My bad, I forgot to mention that I have observed this when using large `c`s (thus very large divisors). A simple test case would be: {{{#!hs import Criterion.Main import GHC.Integer.GMP.Internals ( powModInteger ) main = defaultMain [ bench "test1" $ whnf (\(a,b,c) -> test1 a b c) (45,432,500000) , bench "powModInteger" $ whnf (\(a,b,c) -> test2 a b c) (45,432,500000) , bench "list test1" $ whnf (sum . map (\(a,b,c) -> test1 a b c)) xs , bench "list powModInteger" $ whnf (sum . map (\(a,b,c) -> test2 a b c)) xs ] xs :: [(Integer, Integer, Int)] xs = do a <- [45..50] b <- [295..300] c <- [299999..300000] return (a,b,c) test1, test2 :: Integer -> Integer -> Int -> Integer test1 a b c = (a ^ b) `mod` (2^c) test2 a b c = powModInteger a b (2^c) }}} On my laptop the results are: {{{ benchmarking test1 time 9.796 ms (9.671 ms .. 10.03 ms) 0.997 R? (0.992 R? .. 1.000 R?) mean 9.834 ms (9.764 ms .. 9.977 ms) std dev 274.6 ?s (176.3 ?s .. 443.6 ?s) benchmarking powModInteger time 118.2 ms (117.8 ms .. 118.7 ms) 1.000 R? (1.000 R? .. 1.000 R?) mean 118.5 ms (118.3 ms .. 118.7 ms) std dev 263.8 ?s (193.4 ?s .. 350.7 ?s) variance introduced by outliers: 11% (moderately inflated) benchmarking list test1 time 341.9 ms (335.5 ms .. 347.6 ms) 1.000 R? (NaN R? .. 1.000 R?) mean 338.7 ms (336.6 ms .. 340.1 ms) std dev 2.110 ms (0.0 s .. 2.434 ms) variance introduced by outliers: 19% (moderately inflated) benchmarking list powModInteger time 5.582 s (5.559 s .. 5.622 s) 1.000 R? (1.000 R? .. 1.000 R?) mean 5.737 s (5.685 s .. 5.776 s) std dev 60.66 ms (0.0 s .. 68.48 ms) variance introduced by outliers: 19% (moderately inflated) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 14:24:35 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 14:24:35 -0000 Subject: [GHC] #10613: Mechanism for checking that we only enter single-entry thunks once In-Reply-To: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> References: <046.787816a81f7da40c6d0ca0afdcdd9dbb@haskell.org> Message-ID: <061.8e01ce64ddbe8b48e48479886f7def61@haskell.org> #10613: Mechanism for checking that we only enter single-entry thunks once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by nomeata): A little motivation for anyone considering to work on this: Right now I would be very happy to have this feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 15:10:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 15:10:38 -0000 Subject: [GHC] #10918: Float once-used let binding into a recursive function In-Reply-To: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> References: <046.57a8bfaf928dc1d6c0d53688bcdd3dbd@haskell.org> Message-ID: <061.d9a0e92cb012103ef7ff6e9068e0ca0a@haskell.org> #10918: Float once-used let binding into a recursive function -------------------------------------+------------------------------------- Reporter: nomeata | Owner: 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by nomeata): A side effect of Call Arity setting the once-used flag on bindings is that the code generator does not create update code for such thunks (good!). With paraffin something goes wrong, and allocation skyrockets. Unfortnately, I was not able to pin-point what goes wrong, despite pulling out the ticky-ticky-hammer. (Wishful thinking: A tool that takes a -ddump-prep and a ticky report, annotates the bindings with the ticky numbers, and then removes all uniques from the report, so that I can diff that with a different compilation without the uniques obscuring the diff.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 16:21:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 16:21:27 -0000 Subject: [GHC] #10948: floatExpr tick break<26> Message-ID: <046.8e618a9b91c7b2bd375540a9a0b65ba0@haskell.org> #10948: floatExpr tick break<26> --------------------------------------+------------------------------- Reporter: devnull | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.10.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | --------------------------------------+------------------------------- -> :l Interpolation.hs [1 of 1] Compiling Main ( Interpolation.hs, interpreted ) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-mingw32): floatExpr tick break<26>() Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 16:21:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 16:21:44 -0000 Subject: [GHC] #10948: floatExpr tick break<26> In-Reply-To: <046.8e618a9b91c7b2bd375540a9a0b65ba0@haskell.org> References: <046.8e618a9b91c7b2bd375540a9a0b65ba0@haskell.org> Message-ID: <061.b7f3b58d2249fbeacb5a02fe70a600a8@haskell.org> #10948: floatExpr tick break<26> -------------------------------+-------------------------------------- Reporter: devnull | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------+-------------------------------------- Changes (by devnull): * Attachment "Interpolation.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 16:30:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 16:30:23 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.e4a99ece12fbedc151d452ac61580f86@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 5321 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by goldfire): Good observation about tracking free variables. But I think we'll have to be careful to avoid quadratic behavior. Suppose a call to `flatten_exact_fam_app_fully` creates a sequence of coercions with a quadratic size. This is exactly the case in comment:10. By the time we get to `setEvBind`, the quadratic-sized coercion is built. I thought for a moment laziness might save us, but the transformation from big coercion to `UnivCo` has to traverse the big coercion looking for coercion variables, forcing the thunks. And I think this problem might occur in places other than `flatten_exact_fam_app_fully`. One solution is to make the `mkTcXXX` functions in `TcEvidence` monadic. They could then consult the `DynFlags` to see how to proceed. At first blush, that looks terrible, but I think it's actually OK. I just searched for `mkTcTransCo`, and it is near a monad at every use site. Maybe other `mkTcXXX` functions are less well-placed, but I tend to doubt it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 16:39:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 16:39:05 -0000 Subject: [GHC] #10949: Document typed Template Haskell Message-ID: <047.35ee1a0db28e5aa516018a08926d5a2e@haskell.org> #10949: Document typed Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- As far as I can tell, typed Template Haskell is completely missing from the manual. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 16:39:36 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 16:39:36 -0000 Subject: [GHC] #10945: Typed Template Haskell splices broken in HEAD (7.11) In-Reply-To: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> References: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> Message-ID: <063.72ed20978890187da7f9f025348dcac5@haskell.org> #10945: Typed Template Haskell splices broken in HEAD (7.11) -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10945 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by goldfire): Obviously we shouldn't panic, but the code above looks utterly bogus, for two reasons: 1. According to my understanding, typed splices only work for expressions -- no other contexts allowed. 2. The contents of a typed splice (of type `a`) must be `Q (TExp a)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 17:31:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 17:31:25 -0000 Subject: [GHC] #10949: Document typed Template Haskell In-Reply-To: <047.35ee1a0db28e5aa516018a08926d5a2e@haskell.org> References: <047.35ee1a0db28e5aa516018a08926d5a2e@haskell.org> Message-ID: <062.5fc01598ed50ee524ab133c3116e2efb@haskell.org> #10949: Document typed Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.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): -------------------------------------+------------------------------------- Comment (by jstolarek): Section 7.17.1 does mention typed TH (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/template- haskell.html) so it's not completely missing. But I agree we could have some more documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 17:42:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 17:42:47 -0000 Subject: [GHC] #10949: Document typed Template Haskell In-Reply-To: <047.35ee1a0db28e5aa516018a08926d5a2e@haskell.org> References: <047.35ee1a0db28e5aa516018a08926d5a2e@haskell.org> Message-ID: <062.39802ca70f11ad8a02a8ab62f2c4b61f@haskell.org> #10949: Document typed Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: Ah. Well, all the TH docs need to be improved. But the manual indeed has what I was looking for. I was expecting a top-level section. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 18:13:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 18:13:31 -0000 Subject: [GHC] #10153: GHC mode for converting files to explicit layout In-Reply-To: <045.a5b570a1f5407066e4458fa718968fd2@haskell.org> References: <045.a5b570a1f5407066e4458fa718968fd2@haskell.org> Message-ID: <060.8b775abe4bd6493971a253e2a858d59c@haskell.org> #10153: GHC mode for converting files to explicit layout -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.11 (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): -------------------------------------+------------------------------------- Changes (by ThreeFx): * status: new => closed * resolution: => fixed Comment: Implemented with flag -ddump-parsed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 18:54:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 18:54:31 -0000 Subject: [GHC] #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression In-Reply-To: <045.67153471687796395f900337ba5220e7@haskell.org> References: <045.67153471687796395f900337ba5220e7@haskell.org> Message-ID: <060.334fc744cb221e366aec68397278f2fd@haskell.org> #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression -------------------------------------+------------------------------------- Reporter: erisco | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.8.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:D1313 -------------------------------------+------------------------------------- Comment (by RyanGlScott): On the discussion for Phab:D1313, Richard noted that in order to fix this bug properly, it would be necessary for `template-haskell` to know precisely which identifiers correspond to variables, and which correspond to data constructors. This can be surprisingly tricky, since a litmus test for variables vs. constructors must take into account infix symbols and special characters (e.g., [https://ghc.haskell.org/trac/ghc/ticket/1103 Japanese katakana or hiragana]). Such a task seems best left to a function separate from `dataToQa`, but which one? There's [https://git.haskell.org/ghc.git/blob/ea4df12f7f3fc4d1d2af335804b8ec893f45550c:/compiler/basicTypes/Lexeme.hs#l90 startsVarSym, startsVarId, startsConSym, and startsConId] from `Lexeme` in GHC, but `template-haskell` can't depend on GHC. We ought not move these to `base` either, since that we need this functionality to compile stage 1. Therefore, it seems apt to move this to a package which both `ghc` and `template-haskell` could depend on. Luckily, there's some momentum behind this already: Simon PJ [https://phabricator.haskell.org/D1200#33621 suggested] reappropriating the `bin-package-db` package to become a library which contains functionality that is needed across multiple GHC boot libraries (including GHC itself). Less fortunately, we'd probably need to give it a new name to reflect this. Here is what I propose to resolve this quagmire: 1. Rename `bin-package-db` to `ghc-common` (other naming suggestions are welcome). 2. Move `startsVarSym`, `startsVarId`, `startsConSym`, `startsConId`, `startsVarSymASCII`, and `isVarSymChar` from `Lexeme` to `ghc-common`. There are other things that could be moved, but these would be enough to fix this ticket, and don't rely on a GHC internal data type (e.g., `FastString`). 3. Make `ghc` and `template-haskell` depend on `ghc-common`. No other changes to `ghc` should be necessary. 4. Use `startsVarSym` and `startsVarId` to check if a string corresponds to a variable name within `template-haskell`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 19:20:37 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 19:20:37 -0000 Subject: [GHC] #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression In-Reply-To: <045.67153471687796395f900337ba5220e7@haskell.org> References: <045.67153471687796395f900337ba5220e7@haskell.org> Message-ID: <060.dc4bccfca09b0d960511ea4f94bfdd52@haskell.org> #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression -------------------------------------+------------------------------------- Reporter: erisco | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.8.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:D1313 -------------------------------------+------------------------------------- Comment (by goldfire): I approve this plan. Name suggestion: `ghc-boot`. It reflects the reality of the situation: it's a package needed "before" `ghc` proper. And it seems to wave a big flag saying "I'm an internal package. Don't look at me!" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 19:58:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 19:58:48 -0000 Subject: [GHC] #10947: nofib-analyze should print per-benchmark-compile time totals In-Reply-To: <046.e6aa0dcd741ff8a9fe1facb78be23202@haskell.org> References: <046.e6aa0dcd741ff8a9fe1facb78be23202@haskell.org> Message-ID: <061.34d56704c268088a20d3fde94f497123@haskell.org> #10947: nofib-analyze should print per-benchmark-compile time totals -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.11 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by thomie): This is the same as #9319? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 20:00:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 20:00:19 -0000 Subject: [GHC] #10947: nofib-analyze should print per-benchmark-compile time totals In-Reply-To: <046.e6aa0dcd741ff8a9fe1facb78be23202@haskell.org> References: <046.e6aa0dcd741ff8a9fe1facb78be23202@haskell.org> Message-ID: <061.2da779aebbd2e353e7de798fd8beb267@haskell.org> #10947: nofib-analyze should print per-benchmark-compile time totals -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.11 suite | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9319 | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => duplicate * related: => #9319 Comment: Heh. Yes. Have you memorized all trac tickets that you know even those better which I filed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 20:00:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 20:00:49 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM5MzE5OiBub2ZpYi1hbmFseXplIGRvZXNu4oCZ?= =?utf-8?q?t_provide_per-benchmark_compile_time/alloc_numbers?= In-Reply-To: <046.71bd0e7229dcd657c9f89ae42cc93a34@haskell.org> References: <046.71bd0e7229dcd657c9f89ae42cc93a34@haskell.org> Message-ID: <061.158840f96cde1bf105e7bd3fcb7d290d@haskell.org> #9319: nofib-analyze doesn?t provide per-benchmark compile time/alloc numbers -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.8.2 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by nomeata): * cc: hvr (added) Comment: Looks like I still want this; #10947 is a duplicate of this :-] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 20:03:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 20:03:46 -0000 Subject: [GHC] #10947: nofib-analyze should print per-benchmark-compile time totals In-Reply-To: <046.e6aa0dcd741ff8a9fe1facb78be23202@haskell.org> References: <046.e6aa0dcd741ff8a9fe1facb78be23202@haskell.org> Message-ID: <061.ce58c31ca39171bfa53f0c8c94081495@haskell.org> #10947: nofib-analyze should print per-benchmark-compile time totals -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.11 suite | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9319 | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by thomie): I've been wanting this as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 21:07:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 21:07:51 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.2b73134057ba9adf6db7af86f4c1ba61@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ----------------------------------------+------------------------------- Comment (by erikd): Its not mentioned in the release notes, however the IR docs for the `load` for 3.7 are here : http://llvm.org/releases/3.7.0/docs/LangRef.html#load-instruction which gives as an example: {{{ %ptr = alloca i32 ; yields i32*:ptr store i32 3, i32* %ptr ; yields void %val = load i32, i32* %ptr ; yields i32:val = i32 3 }}} For 3.6 the docs are here: http://llvm.org/releases/3.6.0/docs/LangRef.html#load-instruction and the example is: {{{ %ptr = alloca i32 ; yields i32*:ptr store i32 3, i32* %ptr ; yields void %val = load i32* %ptr ; yields i32:val = i32 3 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 8 22:42:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Oct 2015 22:42:48 -0000 Subject: [GHC] #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" Message-ID: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- During a recent validate with Sphinx (sphinx-build) 1.3.1 (as packaged by Arch Linux), I got this failure: {{{ reading sources... [ 33%] glasgow_exts Exception occurred: File "/usr/lib/python3.5/site-packages/sphinx/environment.py", line 863, in read_doc pickle.dump(doctree, f, pickle.HIGHEST_PROTOCOL) RecursionError: maximum recursion depth exceeded while pickling an object The full traceback has been saved in /tmp/sphinx-err-11x82xjc.log, if you want to report the issue to the developers. Please also report this if it was a user error, so that a better error message can be provided next time. A bug report can be filed in the tracker at . Thanks! docs/users_guide/ghc.mk:30: recipe for target 'docs/users_guide/ghc.1' failed make[1]: *** [docs/users_guide/ghc.1] Error 1 Makefile:121: recipe for target 'all' failed make: *** [all] Error 2 }}} The contents of the referenced log: {{{ # Sphinx version: 1.3.1 # Python version: 3.5.0 (CPython) # Docutils version: 0.12 release # Jinja2 version: 2.8 # Last messages: # reading sources... [ 6%] bugs # reading sources... [ 9%] codegens # reading sources... [ 12%] debugging # reading sources... [ 15%] editing-guide # reading sources... [ 18%] extending_ghc # reading sources... [ 21%] ffi-chap # reading sources... [ 24%] flags # reading sources... [ 27%] ghc # reading sources... [ 30%] ghci # reading sources... [ 33%] glasgow_exts # Loaded extensions: # sphinx.ext.extlinks (1.3.1) from /usr/lib/python3.5/site- packages/sphinx/ext/extlinks.py # alabaster (0.7.6) from /usr/lib/python3.5/site- packages/alabaster/__init__.py Traceback (most recent call last): File "/usr/lib/python3.5/site-packages/sphinx/cmdline.py", line 245, in main app.build(opts.force_all, filenames) File "/usr/lib/python3.5/site-packages/sphinx/application.py", line 264, in build self.builder.build_update() File "/usr/lib/python3.5/site-packages/sphinx/builders/__init__.py", line 240, in build_update self.build(['__all__'], to_build) File "/usr/lib/python3.5/site-packages/sphinx/builders/__init__.py", line 259, in build self.doctreedir, self.app)) File "/usr/lib/python3.5/site-packages/sphinx/environment.py", line 618, in update self._read_serial(docnames, app) File "/usr/lib/python3.5/site-packages/sphinx/environment.py", line 638, in _read_serial self.read_doc(docname, app) File "/usr/lib/python3.5/site-packages/sphinx/environment.py", line 863, in read_doc pickle.dump(doctree, f, pickle.HIGHEST_PROTOCOL) RecursionError: maximum recursion depth exceeded while pickling an object }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 02:41:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 02:41:15 -0000 Subject: [GHC] #10871: Implement "fat" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.6c814b5d6a88a6980d6c5998e1653b3d@haskell.org> #10871: Implement "fat" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by mgsloan): This is a really cool idea. I'd like to encourage putting as much info as possible into these hi-fat files (or potentially make that an option). For example, type information for every sub expression, exact names for identifiers, and SrcLoc info. Why? Because this could also potentially allow for querying information about libraries without compiling them. For example, you might jump into some library code by using "go-to- definition" in an IDE. It would be excellent to then be able to immediately get info about the code you've jumped into, via these fat hi files. I don't know much about GHC internals, so maybe this doesn't make much sense. But, something to consider! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 04:49:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 04:49:26 -0000 Subject: [GHC] #10948: floatExpr tick break<26> In-Reply-To: <046.8e618a9b91c7b2bd375540a9a0b65ba0@haskell.org> References: <046.8e618a9b91c7b2bd375540a9a0b65ba0@haskell.org> Message-ID: <061.ffb7533ff01fd447d2d4e3201127cc78@haskell.org> #10948: floatExpr tick break<26> -------------------------------+-------------------------------------- Reporter: devnull | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: GHCi | Version: 7.10.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #10549 | Differential Rev(s): -------------------------------+-------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #10549 Comment: Thank you for the report. I can reproduce the problem. With the yet unreleased version of ghc-7.10.3, the result is: {{{ when making flags consistent: Warning: -O conflicts with --interactive; -O ignored. }}} So the workaround is to remove the `{-# OPTIONS_GHC -O3 #-}` from your file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 04:52:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 04:52:22 -0000 Subject: [GHC] #1853: hpc mix files for Main modules overwrite each other In-Reply-To: <044.9b946ad54a9a35d3915c7a74c107b816@haskell.org> References: <044.9b946ad54a9a35d3915c7a74c107b816@haskell.org> Message-ID: <059.50e9aab47661319fb0265818d804d444@haskell.org> #1853: hpc mix files for Main modules overwrite each other ----------------------------------+-------------------------------------- Reporter: guest | Owner: AndyGill Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Code Coverage | Version: 6.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ----------------------------------+-------------------------------------- Comment (by mgsloan): This is also troublesome for using `hpc combine --union` to merge tix files which come from different programs. My current hack is to preprocess the tix files and remove all of the executable modules, like this: https://gist.github.com/mgsloan/e44e8775516c50f10edf I think the ideal resolution would be to prefix all of the executable modules with some better identification. How about having a new ghc flag like `--hpc-package-prefix prefix`, where the conventional value for prefix is the cabal `package:component`? Then, the tix files will use this prefix on module names, and the mix files will get outputted to a subdirectory instead of the root of the hpcdir. This convention gets a little weird due to the usage of `:` when passing `--include` and `--exclude` to the hpc program (see https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/hpc.html). However, with care, `:` should be a valid thing to use in `PACKAGE`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 05:08:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 05:08:11 -0000 Subject: [GHC] #10951: HPC program has poor error reporting / strange CLI in general Message-ID: <046.0eb67759af4f01648e433f1249d67ab5@haskell.org> #10951: HPC program has poor error reporting / strange CLI in general -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Code Coverage | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- 1. Many erroneous usages of the hpc program result in reporting 100% (0/0) coverage. Proposed resolution: * Report an error and exit with failure. I can't think of a legitimate case where you would want a report that doesn't consider any expressions / declarations. * If a --include flag is specified, I think it would be valuable to output all the module names, so that it's clearer why the --include flag didn't work. * At the very least, (0/0) coverage shouldn't be reported as "100%". 2. Positional arguments after the initial tix file get interpreted as --include filters, filtering which modules / packages are considered. By default, HPC includes all modules in the report, unless include filters are supplied. If you accidentally provide a positional argument which isn't a valid thing for "--include", then your reports will always be (0/0) coverage. Proposed resolution: * Deprecate using positional arguments for include filters. This way it will complain about this instead of yielding trivial (0/0) coverage reports 3. Ideally, you'd be able to pass in multiple tix files and combine them in memory instead of using "hpc combine" and generating intermediate tix files. This would be a better usage of positional arguments than include filters. For now, the additional tix files would need to be flag arguments. This also isn't all that useful until https://ghc.haskell.org/trac/ghc/ticket/1853 is fixed. 4. `--srcdir`, `--hpcdir`, and `--reset-hpcdirs` interface has strange semantics for searching for mix files. It literally does something roughly like `[sd hd | sd <- srcDirs, hd <- hpcDirs]`, and uses this when looking for mix files. This would be OK, except that the `srcdir` must be the work dir used for compilation, in order for source markup to be generated. This means that you are tied to having your hpcdir be a sub-directory of the compilation work dir. Proposed resolution: * Add `--mixdir`, specifying a path to a mix file directory. Can be supplied multiple times. If `--mixdir` is provided, then it's an error to also use `--hpcdir` / `--reset-hpcdirs`. Instead of fixing the hpc program, I have considered forking it and giving it a new executable name, so that the CLI and behavior can be entirely changed. Thoughts on this alternative? It is appealing because it seems tricky to fix the hpc program's CLI while ensuring that backwards compatibility is maintained. I am keen on working on fixing this situation, but I want consensus from y'all about the approach that should be taken. Maybe it makes sense for this hpc-ng program to be developed outside of the GHC repo? This way it can use more recent libraries for generating HTML and parsing command line arguments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 05:09:45 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 05:09:45 -0000 Subject: [GHC] #10952: Use IPids instead of package keys in HPC tix files Message-ID: <046.2961695834220c5d8e713a72077c82af@haskell.org> #10952: Use IPids instead of package keys in HPC tix files -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Code Coverage | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- With GHC 7.10.2, HPC module names are stored in the format "package_key/Module.Name", rather than "package_id/Module.Name". In stack, we restrict the coverage results to just the library modules by using the "--include" flag. For GHC 7.10, this means I need to ask ghc- pkg what the package key is in order to figure out what to pass in for "-- include" (see this issue: https://github.com/commercialhaskell/stack/issues/785). I thought this was done correctly, but now I'm seeing some cases where coverage is reporting (0/0) due to the wrong package key being passed in... I think I need to run the ghc-pkg query with the package's ipid rather than name.. So, I need to have the correct ipid somewhere, in order to run ghc-pkg describe, parse its results to find out what the package key is, and then finally pass this in as a CLI argument. The hpc program's CLI is already woefully error-prone (see https://ghc.haskell.org/trac/ghc/ticket/10951), but this makes it plain hellish. Is there a better way to do what I need to do here? I think the right approach to resolving this is to put the full ipid in the HPC files. Then, the hpc program should be modified to allow "-- include" argument to take multiple package identification formats - ipid, package identifier, or package name. If the full package name was included, I could at least do some custom tix file munging based on just the package name. As things stand, the only way I can meaningfully operate on tix files is if I have the correct package key. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 05:11:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 05:11:32 -0000 Subject: [GHC] #10952: Use IPids instead of package keys in HPC tix files In-Reply-To: <046.2961695834220c5d8e713a72077c82af@haskell.org> References: <046.2961695834220c5d8e713a72077c82af@haskell.org> Message-ID: <061.0a386bbe1a641482adf6bd1e2b08571a@haskell.org> #10952: Use IPids instead of package keys in HPC tix files -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Code Coverage | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Description changed by mgsloan: Old description: > With GHC 7.10.2, HPC module names are stored in the format > "package_key/Module.Name", rather than "package_id/Module.Name". In > stack, we restrict the coverage results to just the library modules by > using the "--include" flag. For GHC 7.10, this means I need to ask ghc- > pkg what the package key is in order to figure out what to pass in for " > --include" (see this issue: > https://github.com/commercialhaskell/stack/issues/785). > > I thought this was done correctly, but now I'm seeing some cases where > coverage is reporting (0/0) due to the wrong package key being passed > in... I think I need to run the ghc-pkg query with the package's ipid > rather than name.. So, I need to have the correct ipid somewhere, in > order to run ghc-pkg describe, parse its results to find out what the > package key is, and then finally pass this in as a CLI argument. The hpc > program's CLI is already woefully error-prone (see > https://ghc.haskell.org/trac/ghc/ticket/10951), but this makes it plain > hellish. > > Is there a better way to do what I need to do here? > > I think the right approach to resolving this is to put the full ipid in > the HPC files. Then, the hpc program should be modified to allow "-- > include" argument to take multiple package identification formats - ipid, > package identifier, or package name. > > If the full package name was included, I could at least do some custom > tix file munging based on just the package name. As things stand, the > only way I can meaningfully operate on tix files is if I have the correct > package key. New description: With GHC 7.10.2, HPC module names are stored in the format "package_key/Module.Name", rather than "package_id/Module.Name". In stack, we restrict the coverage results to just the library modules by using the "--include" flag. For GHC 7.10, this means I need to ask ghc- pkg what the package key is in order to figure out what to pass in for "-- include" (see this issue: https://github.com/commercialhaskell/stack/issues/785). I thought this was done correctly, but now I'm seeing some cases where coverage is reporting (0/0) due to the wrong package key being passed in... I think I need to run the ghc-pkg query with the package's ipid rather than name.. So, I need to have the correct ipid somewhere, in order to run ghc-pkg describe, parse its results to find out what the package key is, and then finally pass this in as a CLI argument. The hpc program's CLI is already woefully error-prone (see https://ghc.haskell.org/trac/ghc/ticket/10951), but this makes it plain hellish. Is there a better way to do what I need to do here? I think the right approach to resolving this is to put the full ipid in the HPC files. Then, the hpc program should be modified to allow "-- include" argument to take multiple package identification formats - ipid, package identifier, or package name. This should also make it possible to remove the explici If the full package name was included, I could at least do some custom tix file munging based on just the package name. As things stand, the only way I can meaningfully operate on tix files is if I have the correct package key. There isn't enough information in the files to perform operations based on package name. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 05:15:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 05:15:07 -0000 Subject: [GHC] #10951: HPC program has poor error reporting / strange CLI in general In-Reply-To: <046.0eb67759af4f01648e433f1249d67ab5@haskell.org> References: <046.0eb67759af4f01648e433f1249d67ab5@haskell.org> Message-ID: <061.1ea95df36feb9c761db9a84df92e66b7@haskell.org> #10951: HPC program has poor error reporting / strange CLI in general -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Code Coverage | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Description changed by mgsloan: Old description: > 1. Many erroneous usages of the hpc program result in reporting 100% > (0/0) coverage. Proposed resolution: > > * Report an error and exit with failure. I can't think of a legitimate > case where you would want a report that doesn't consider any expressions > / declarations. > > * If a --include flag is specified, I think it would be valuable to > output all the module names, so that it's clearer why the --include flag > didn't work. > > * At the very least, (0/0) coverage shouldn't be reported as "100%". > > 2. Positional arguments after the initial tix file get interpreted as > --include filters, filtering which modules / packages are considered. By > default, HPC includes all modules in the report, unless include filters > are supplied. If you accidentally provide a positional argument which > isn't a valid thing for "--include", then your reports will always be > (0/0) coverage. Proposed resolution: > > * Deprecate using positional arguments for include filters. This way it > will complain about this instead of yielding trivial (0/0) coverage > reports > > 3. Ideally, you'd be able to pass in multiple tix files and combine them > in memory instead of using "hpc combine" and generating intermediate tix > files. This would be a better usage of positional arguments than include > filters. For now, the additional tix files would need to be flag > arguments. This also isn't all that useful until > https://ghc.haskell.org/trac/ghc/ticket/1853 is fixed. > > 4. `--srcdir`, `--hpcdir`, and `--reset-hpcdirs` interface has strange > semantics for searching for mix files. It literally does something > roughly like `[sd hd | sd <- srcDirs, hd <- hpcDirs]`, and uses this > when looking for mix files. This would be OK, except that the `srcdir` > must be the work dir used for compilation, in order for source markup to > be generated. This means that you are tied to having your hpcdir be a > sub-directory of the compilation work dir. Proposed resolution: > > * Add `--mixdir`, specifying a path to a mix file directory. Can be > supplied multiple times. If `--mixdir` is provided, then it's an error > to also use `--hpcdir` / `--reset-hpcdirs`. > > Instead of fixing the hpc program, I have considered forking it and > giving it a new executable name, so that the CLI and behavior can be > entirely changed. Thoughts on this alternative? It is appealing because > it seems tricky to fix the hpc program's CLI while ensuring that > backwards compatibility is maintained. > > I am keen on working on fixing this situation, but I want consensus from > y'all about the approach that should be taken. > > Maybe it makes sense for this hpc-ng program to be developed outside of > the GHC repo? This way it can use more recent libraries for generating > HTML and parsing command line arguments. New description: 1. Many erroneous usages of the hpc program result in reporting 100% (0/0) coverage. Proposed resolution: * Report an error and exit with failure. I can't think of a legitimate case where you would want a report that doesn't consider any expressions / declarations. * If a --include flag is specified, I think it would be valuable to output all the module names, so that it's clearer why the --include flag didn't work. * At the very least, (0/0) coverage shouldn't be reported as "100%". 2. Positional arguments after the initial tix file get interpreted as --include filters, filtering which modules / packages are considered. By default, HPC includes all modules in the report, unless include filters are supplied. If you accidentally provide a positional argument which isn't a valid thing for "--include", then your reports will always be (0/0) coverage. Proposed resolution: * Deprecate using positional arguments for include filters. This way it will complain about this instead of yielding trivial (0/0) coverage reports 3. Ideally, you'd be able to pass in multiple tix files and combine them in memory instead of using "hpc combine" and generating intermediate tix files. This would be a better usage of positional arguments than include filters. For now, the additional tix files would need to be flag arguments. This also isn't all that useful until https://ghc.haskell.org/trac/ghc/ticket/1853 is fixed. 4. `--srcdir`, `--hpcdir`, and `--reset-hpcdirs` interface has strange semantics for searching for mix files. It literally does something roughly like `[sd hd | sd <- srcDirs, hd <- hpcDirs]`, and uses this when looking for mix files. This would be OK, except that the `srcdir` must be the work dir used for compilation, in order for source markup to be generated. This means that you are tied to having your hpcdir be a sub-directory of the compilation work dir. Proposed resolution: * Add `--mixdir`, specifying a path to a mix file directory. Can be supplied multiple times. If `--mixdir` is provided, then it's an error to also use `--hpcdir` / `--reset-hpcdirs`. * If GHC is provided an absolute `-hpcdir`, then use it rather than appending to the CWD. Instead of fixing the hpc program, I have considered forking it and giving it a new executable name, so that the CLI and behavior can be entirely changed. Thoughts on this alternative? It is appealing because it seems tricky to fix the hpc program's CLI while ensuring that backwards compatibility is maintained. I am keen on working on fixing this situation, but I want consensus from y'all about the approach that should be taken. Maybe it makes sense for this hpc-ng program to be developed outside of the GHC repo? This way it can use more recent libraries for generating HTML and parsing command line arguments. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 05:20:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 05:20:16 -0000 Subject: [GHC] #10952: Use IPids instead of package keys in HPC tix files In-Reply-To: <046.2961695834220c5d8e713a72077c82af@haskell.org> References: <046.2961695834220c5d8e713a72077c82af@haskell.org> Message-ID: <061.16dc5f5057d94189012692ddd2d9d262@haskell.org> #10952: Use IPids instead of package keys in HPC tix files -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Code Coverage | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * cc: ezyang (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 05:21:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 05:21:18 -0000 Subject: [GHC] #10951: HPC program has poor error reporting / strange CLI in general In-Reply-To: <046.0eb67759af4f01648e433f1249d67ab5@haskell.org> References: <046.0eb67759af4f01648e433f1249d67ab5@haskell.org> Message-ID: <061.4fa7189efe21e3f15a465d5a9cd8a8e7@haskell.org> #10951: HPC program has poor error reporting / strange CLI in general -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Code Coverage | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Description changed by mgsloan: Old description: > 1. Many erroneous usages of the hpc program result in reporting 100% > (0/0) coverage. Proposed resolution: > > * Report an error and exit with failure. I can't think of a legitimate > case where you would want a report that doesn't consider any expressions > / declarations. > > * If a --include flag is specified, I think it would be valuable to > output all the module names, so that it's clearer why the --include flag > didn't work. > > * At the very least, (0/0) coverage shouldn't be reported as "100%". > > 2. Positional arguments after the initial tix file get interpreted as > --include filters, filtering which modules / packages are considered. By > default, HPC includes all modules in the report, unless include filters > are supplied. If you accidentally provide a positional argument which > isn't a valid thing for "--include", then your reports will always be > (0/0) coverage. Proposed resolution: > > * Deprecate using positional arguments for include filters. This way it > will complain about this instead of yielding trivial (0/0) coverage > reports > > 3. Ideally, you'd be able to pass in multiple tix files and combine them > in memory instead of using "hpc combine" and generating intermediate tix > files. This would be a better usage of positional arguments than include > filters. For now, the additional tix files would need to be flag > arguments. This also isn't all that useful until > https://ghc.haskell.org/trac/ghc/ticket/1853 is fixed. > > 4. `--srcdir`, `--hpcdir`, and `--reset-hpcdirs` interface has strange > semantics for searching for mix files. It literally does something > roughly like `[sd hd | sd <- srcDirs, hd <- hpcDirs]`, and uses this > when looking for mix files. This would be OK, except that the `srcdir` > must be the work dir used for compilation, in order for source markup to > be generated. This means that you are tied to having your hpcdir be a > sub-directory of the compilation work dir. Proposed resolution: > > * Add `--mixdir`, specifying a path to a mix file directory. Can be > supplied multiple times. If `--mixdir` is provided, then it's an error > to also use `--hpcdir` / `--reset-hpcdirs`. > > * If GHC is provided an absolute `-hpcdir`, then use it rather than > appending to the CWD. > > Instead of fixing the hpc program, I have considered forking it and > giving it a new executable name, so that the CLI and behavior can be > entirely changed. Thoughts on this alternative? It is appealing because > it seems tricky to fix the hpc program's CLI while ensuring that > backwards compatibility is maintained. > > I am keen on working on fixing this situation, but I want consensus from > y'all about the approach that should be taken. > > Maybe it makes sense for this hpc-ng program to be developed outside of > the GHC repo? This way it can use more recent libraries for generating > HTML and parsing command line arguments. New description: 1. Many erroneous usages of the hpc program result in reporting 100% (0/0) coverage. Proposed resolution: * Report an error and exit with failure. I can't think of a legitimate case where you would want a report that doesn't consider any expressions / declarations. * If a --include flag is specified, I think it would be valuable to output all the module names, so that it's clearer why the --include flag didn't work. * At the very least, (0/0) coverage shouldn't be reported as "100%". 2. Positional arguments after the initial tix file get interpreted as --include filters, filtering which modules / packages are considered. By default, HPC includes all modules in the report, unless include filters are supplied. If you accidentally provide a positional argument which isn't a valid thing for "--include", then your reports will always be (0/0) coverage. Proposed resolution: * Deprecate using positional arguments for include filters. This way it will complain about this instead of yielding trivial (0/0) coverage reports 3. Ideally, you'd be able to pass in multiple tix files and combine them in memory instead of using "hpc combine" and generating intermediate tix files. This would be a better usage of positional arguments than include filters. For now, the additional tix files would need to be flag arguments. This also isn't all that useful until https://ghc.haskell.org/trac/ghc/ticket/1853 is fixed. 4. `--srcdir`, `--hpcdir`, and `--reset-hpcdirs` interface has strange semantics for searching for mix files. It literally does something roughly like `[sd hd | sd <- srcDirs, hd <- hpcDirs]`, and uses this when looking for mix files. This would be OK, except that the `srcdir` must be the work dir used for compilation, in order for source markup to be generated. This means that you are tied to having your hpcdir be a sub-directory of the compilation work dir. Proposed resolution: * Add `--mixdir`, specifying a path to a mix file directory. Can be supplied multiple times. If `--mixdir` is provided, then it's an error to also use `--hpcdir` / `--reset-hpcdirs`. * If GHC is provided an absolute `-hpcdir`, then use it rather than appending to the CWD. 5. If anything goes wrong when matching up a module in a tix file with mix metadata, the error is "can not find MODNAME in DIRS". (see the code here: https://github.com/ghc/packages- hpc/blob/fb14d3428ba24d36e779736989dae3092a50a957/Trace/Hpc/Mix.hs#L87) This is quite confusing because this same message is used for all of the following cases: * There's a parse error of the mix file * Any IO error happens * The module hash mismatches Instead of fixing the hpc program, I have considered forking it and giving it a new executable name, so that the CLI and behavior can be entirely changed. Thoughts on this alternative? It is appealing because it seems tricky to fix the hpc program's CLI while ensuring that backwards compatibility is maintained. I am keen on working on fixing this situation, but I want consensus from y'all about the approach that should be taken. Maybe it makes sense for this hpc-ng program to be developed outside of the GHC repo? This way it can use more recent libraries for generating HTML and parsing command line arguments. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 05:36:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 05:36:48 -0000 Subject: [GHC] #10951: HPC program has poor error reporting / strange CLI in general In-Reply-To: <046.0eb67759af4f01648e433f1249d67ab5@haskell.org> References: <046.0eb67759af4f01648e433f1249d67ab5@haskell.org> Message-ID: <061.7d43700c777abf534db151af376cfae1@haskell.org> #10951: HPC program has poor error reporting / strange CLI in general -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Code Coverage | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * cc: thoughtpolice (added) Comment: @mgsloan: It would be great if you could work on this. Asking @thoughtpolice to comment on the pros/cons of developing hpc outside of the GHC repository. > "can not find MODNAME in DIRS" This should be already fixed in HEAD (#10529). I fixed some other issues as well, not sure if you ran into them: https://ghc.haskell.org/trac/ghc/query?status=closed&component=Code+Coverage&milestone=8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 05:46:47 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 05:46:47 -0000 Subject: [GHC] #10951: HPC program has poor error reporting / strange CLI in general In-Reply-To: <046.0eb67759af4f01648e433f1249d67ab5@haskell.org> References: <046.0eb67759af4f01648e433f1249d67ab5@haskell.org> Message-ID: <061.ed3d7931a6e6aef8036ea362c801c0e7@haskell.org> #10951: HPC program has poor error reporting / strange CLI in general -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Code Coverage | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by mgsloan): @thomie Cool! I did indeed run into the current work directory / absolute paths handling. Glad that's fixed! I've thought about it a little more, and I think it probably doesn't make sense at this time to work on the hpc program outside of the GHC repo. So I guess the main thing is: Do my proposed resolutions seem like the right approach to resolving these issues? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 05:49:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 05:49:17 -0000 Subject: [GHC] #1853: hpc mix files for Main modules overwrite each other In-Reply-To: <044.9b946ad54a9a35d3915c7a74c107b816@haskell.org> References: <044.9b946ad54a9a35d3915c7a74c107b816@haskell.org> Message-ID: <059.d062d8927512ef4ac4649a7d9b31a12a@haskell.org> #1853: hpc mix files for Main modules overwrite each other ----------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Code Coverage | Version: 6.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ----------------------------------+-------------------------------------- Changes (by thomie): * owner: AndyGill => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 06:44:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 06:44:11 -0000 Subject: [GHC] #10952: Use IPids instead of package keys in HPC tix files In-Reply-To: <046.2961695834220c5d8e713a72077c82af@haskell.org> References: <046.2961695834220c5d8e713a72077c82af@haskell.org> Message-ID: <061.8136beab2c14969a965ce9946217c885@haskell.org> #10952: Use IPids instead of package keys in HPC tix files -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Code Coverage | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by ezyang): mgsloan, how much of this do you want to fix for the upcoming 8.0 release, as opposed to backports for 7.10? I think your life will get better when we unify IPIDs and PackageKeys, so that there will no longer be any distinction. If you're also willing to wait for 8.0, I am sure there are many affordances that could be added to hpc's API to make things better. Ultimately, I do think it is right for GHC to output Tix files based on the "package key" (which happened to just be the "package id" in the past, but only accidentally). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 06:48:52 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 06:48:52 -0000 Subject: [GHC] #10952: Use IPids instead of package keys in HPC tix files In-Reply-To: <046.2961695834220c5d8e713a72077c82af@haskell.org> References: <046.2961695834220c5d8e713a72077c82af@haskell.org> Message-ID: <061.1ab6e5fc52a623e04fefb2fc62ff6ef9@haskell.org> #10952: Use IPids instead of package keys in HPC tix files -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Code Coverage | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by mgsloan): Hi ezyang! I'm glad to hear that IPIDs and PackageKeys will be unified. Does that mean that the tix module names will include the full package name + possibly the version number? I don't think there is much value in backporting things to 7.10, I just want to see this fixed in 8.0. So, if this will be fixed as a side effect of that unification, and the unification is sure to happen, feel free to close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 07:57:19 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 07:57:19 -0000 Subject: [GHC] #10432: panic with kind polymorphism In-Reply-To: <053.23d99653504b87c50e0b0230cb7a3ff8@haskell.org> References: <053.23d99653504b87c50e0b0230cb7a3ff8@haskell.org> Message-ID: <068.2c5717a8999c526be763bc6b9a0a4ee0@haskell.org> #10432: panic with kind polymorphism -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by simonpj): It does not work in HEAD for me. I get {{{ simonpj at cam-05-unx:~/tmp$ ~/5builds/HEAD-4/inplace/bin/ghc-stage1 -c -dcore-lint T10432.hs RAE1 [W] cobox_arV :: ka1_arO[sk] ~ kb1_arP[sk] (CNonCanonical) ka1_arO[sk] kb1_arP[sk] False T10432.hs:17:15: error: Couldn't match kind ?ka1? with ?kb1? ?ka1? is untouchable inside the constraints: 'WrapType a1 ~ 'WrapType b1 bound by the type signature for: foo :: ('WrapType a1 ~ 'WrapType b1) => r1 at T10432.hs:17:15-46ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.11.20151006 for x86_64-unknown-linux): No skolem info: kb1_arP[sk] }}} for the code in comment:1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 09:15:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 09:15:07 -0000 Subject: [GHC] #10376: arm/linux linking failure In-Reply-To: <044.29ac411aa184ff9b10d3766853c9a35d@haskell.org> References: <044.29ac411aa184ff9b10d3766853c9a35d@haskell.org> Message-ID: <059.c86daa056e1538edb0af8049b6e4e8bf@haskell.org> #10376: arm/linux linking failure -------------------------------------+----------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10464 | Differential Rev(s): -------------------------------------+----------------------------- Comment (by k-bx): @thomie thank you! It helped. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 09:54:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 09:54:39 -0000 Subject: [GHC] #10953: Switch to LLVM 3.7 Message-ID: <044.001611d6f47af3fe74e4a46f1d21d31f@haskell.org> #10953: Switch to LLVM 3.7 -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (LLVM) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- LLVM 3.6 is broken on AArch64/Arm64 and LLVM 3.7 was released in August. I already have git master building with LLVM-3.7 on x86_64/linux and can test on numerous others. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 10:09:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 10:09:39 -0000 Subject: [GHC] #10432: panic with kind polymorphism In-Reply-To: <053.23d99653504b87c50e0b0230cb7a3ff8@haskell.org> References: <053.23d99653504b87c50e0b0230cb7a3ff8@haskell.org> Message-ID: <068.a013d74771447b751a679ce274011c42@haskell.org> #10432: panic with kind polymorphism -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by jstolarek): I'm using a compiler built by `./validate` from commit e2b579e8d77357e8b36f57d15daead101586ac8e and here's what I get for originally reported code: {{{ [killy at xerxes : /dane/projekty/ghc/ghc-tests/types/T10432] cat T10432.hs {-# LANGUAGE ExistentialQuantification, PolyKinds, DataKinds, RankNTypes, GADTs, TypeOperators #-} module T10432 where import Data.Type.Equality data WrappedType = forall a. WrapType a; matchReflK :: forall (a :: ka) (b :: kb) (r :: *). ('WrapType a :~: 'WrapType b) -> (('WrapType a ~ 'WrapType b) => r) -> r; matchReflK Refl r = r; [killy at xerxes : /dane/projekty/ghc/ghc-tests/types/T10432] ghc-validate- stage1 -c -dcore-lint T10432.hs T10432.hs:8:15: error: Could not deduce: ka ~ kb from the context: 'WrapType a ~ 'WrapType b bound by the type signature for: matchReflK :: ('WrapType a ~ 'WrapType b) => r at T10432.hs:(8,15)-(9,74) ?ka? is a rigid type variable bound by the type signature for: matchReflK :: 'WrapType a :~: 'WrapType b -> (('WrapType a ~ 'WrapType b) => r) -> r at T10432.hs:8:15 ?kb? is a rigid type variable bound by the type signature for: matchReflK :: 'WrapType a :~: 'WrapType b -> (('WrapType a ~ 'WrapType b) => r) -> r at T10432.hs:8:15 Expected type: 'WrapType b Actual type: 'WrapType a In the ambiguity check for the type signature for ?matchReflK?: matchReflK :: forall (ka :: BOX) (kb :: BOX) (a :: ka) (b :: kb) r. 'WrapType a :~: 'WrapType b -> (('WrapType a ~ 'WrapType b) => r) -> r To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature for ?matchReflK?: matchReflK :: forall (a :: ka) (b :: kb) (r :: *). (WrapType a :~: WrapType b) -> ((WrapType a ~ WrapType b) => r) -> r }}} And for the code in comment:1: {{{ [killy at xerxes : /dane/projekty/ghc/ghc-tests/types/T10432] cat T10432.hs {-# LANGUAGE ExistentialQuantification, PolyKinds, DataKinds, RankNTypes, GADTs, TypeOperators #-} module T10432 where import Data.Type.Equality data WrappedType = forall a. WrapType a; matchReflK2 :: forall (a :: ka) (b :: kb) (r :: *). ('WrapType a :~: 'WrapType b) -> r matchReflK2 x = let foo :: ('WrapType a ~ 'WrapType b) => r foo = undefined in undefined [killy at xerxes : /dane/projekty/ghc/ghc-tests/types/T10432] ghc-validate- stage1 -c -dcore-lint T10432.hs [killy at xerxes : /dane/projekty/ghc/ghc-tests/types/T10432] }}} I have no idea why are we getting different behaviours :-/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 10:10:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 10:10:57 -0000 Subject: [GHC] #10432: panic with kind polymorphism In-Reply-To: <053.23d99653504b87c50e0b0230cb7a3ff8@haskell.org> References: <053.23d99653504b87c50e0b0230cb7a3ff8@haskell.org> Message-ID: <068.22912a7dd7cec18d6fff374ac2fb5c97@haskell.org> #10432: panic with kind polymorphism -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by thomie): I can reproduce jstolarek's findings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 10:58:52 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 10:58:52 -0000 Subject: [GHC] #10267: Add support for typed holes in Template Haskell In-Reply-To: <048.c1c64a1e465638edb9cc6eb9b5affa9b@haskell.org> References: <048.c1c64a1e465638edb9cc6eb9b5affa9b@haskell.org> Message-ID: <063.f33175ac9256529af7420748ea95662d@haskell.org> #10267: Add support for typed holes in Template Haskell -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10945, #10946 | Differential Rev(s): Phab:D835 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * related: => #10945, #10946 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 16:22:45 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 16:22:45 -0000 Subject: [GHC] #10343: Make Typeable track kind information better In-Reply-To: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> References: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> Message-ID: <060.c24cbbeab4f1abb800ea16dacd302ada@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: typeOf :: | Typeable (a::k) => Proxy a -> | TypeRep Blocked By: | Blocking: Related Tickets: #9858 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sweirich): * cc: sweirich (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 16:50:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 16:50:22 -0000 Subject: [GHC] #10954: Add class/context information to typed hole relevant bindings Message-ID: <045.32f5d1e1940c448cdbb57da9612bf97b@haskell.org> #10954: Add class/context information to typed hole relevant bindings -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #9479 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC's typed hole messages don't currently include any known context information for relevant bindings. For example: {{{#!hs bar :: a ~ b => a -> b -> Int bar x y = _ }}} gets me {{{ Found hole ?_? with type: Int Relevant bindings include y :: b (bound at :8:42) x :: a (bound at :8:40) bar :: a -> b -> Int (bound at :8:36) In the expression: _ In an equation for ?bar?: bar x y = _ }}} The types `a` and `b` are not unified, and the `a ~ b` constraint is not shown. {{{#!hs foo :: Show a => a -> Int foo x = _ }}} gets me {{{ Found hole ?_? with type: Int Relevant bindings include x :: a (bound at :4:36) foo :: a -> Int (bound at :4:32) In the expression: _ In an equation for ?foo?: foo x = _ }}} The `Show` constraint is lost. === What I want === I'd like context information for all type variables in known bindings, so I can see all the pieces available to help me fill in the hole. === Related ticket === In #9479, Dominique Devriese wants to see any constraints ''on'' an ambiguously-typed hole. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 20:35:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 20:35:58 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.426347d123d14b585af103bad4063a22@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by erikd): I have a patch in progress that allows building GHC with llvm-3.7 and `BuildFlavour=quick-llvm` on x86_64. In the process of testing that on arm64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 21:03:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 21:03:31 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.4ca748dd283f7ea6cfc322a58908953d@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 (Linking) | Resolution: | Keywords: Debian Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: low => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 23:49:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 23:49:01 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.e2169651a872beb2dc95a4134d25c2d1@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by erikd): It lives! GHC now builds registerised, with the LLVM backend in the `wip/aarch64-regd` branch in the GHC git repo. Need to clean it up and will then put it through Phab. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 9 23:56:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Oct 2015 23:56:26 -0000 Subject: [GHC] #10848: GHC/GHCi should optionally print errors in reversed order In-Reply-To: <043.346863bae2dced560ac8325c22b2fccb@haskell.org> References: <043.346863bae2dced560ac8325c22b2fccb@haskell.org> Message-ID: <058.18296674624d314459fe519a6ad2f00f@haskell.org> #10848: GHC/GHCi should optionally print errors in reversed order -------------------------------------+------------------------------------- Reporter: osa1 | Owner: siddhanathan Type: feature request | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 7.11 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 bernalex): Still working on this, siddhanathan? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 00:04:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 00:04:57 -0000 Subject: [GHC] #10848: GHC/GHCi should optionally print errors in reversed order In-Reply-To: <043.346863bae2dced560ac8325c22b2fccb@haskell.org> References: <043.346863bae2dced560ac8325c22b2fccb@haskell.org> Message-ID: <058.b8afe7c0595dcc3378639d22c4a47c0c@haskell.org> #10848: GHC/GHCi should optionally print errors in reversed order -------------------------------------+------------------------------------- Reporter: osa1 | Owner: siddhanathan Type: feature request | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 7.11 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 siddhanathan): Yeah, I'm almost done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 07:04:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 07:04:12 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.dda46fd2a5520b9aab8c298ea08aae5c@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dreixel): Replying to [comment:7 mpickering]: > Adding Edward and Pedro as they are the only two other authors to (publicly) use them. To be honest I don't remember where I publicly used them, but I am perfectly happy with keeping the current syntax, but with reversed ordering. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 07:38:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 07:38:52 -0000 Subject: [GHC] #10953: Switch to LLVM 3.7 In-Reply-To: <044.001611d6f47af3fe74e4a46f1d21d31f@haskell.org> References: <044.001611d6f47af3fe74e4a46f1d21d31f@haskell.org> Message-ID: <059.3c8379b1137fc85848aec4606f3e5a97@haskell.org> #10953: Switch to LLVM 3.7 -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.11 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:D1320 -------------------------------------+------------------------------------- Changes (by erikd): * differential: => Phab:D1320 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 07:58:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 07:58:50 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.589e550f07ad19eabf4e4c6e0b039b8d@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by edmund): That's excellent! Some questions: - Did you run the testsuite? - Are there any regressions? - Is concurrency ("-threaded") now enabled? - Did that get tested by the testsuite? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 08:19:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 08:19:54 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.b0dc5933bc4c282d98051d7f7d6f6b21@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by erikd): Haven't run the test suite yet, but I know GHCi is busted: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151009 for aarch64-unknown-linux): mkJumpToAddr not defined for ArchARM64 }}} Working on a fix for that. Yes, threaded is working. Probably not going to get much time to work on this until Monday. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 09:02:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 09:02:23 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.edd691f99f862071a2ff76af7c69e5b8@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by erikd): There is definitely some work to do: {{{ OVERALL SUMMARY for test run started at Sat Oct 10 08:41:17 2015 UTC 0:28:32 spent to go through 4693 total tests, which gave rise to 14892 test cases, of which 10249 were skipped 72 had missing libraries 4146 expected passes 100 expected failures 21 caused framework failures 0 unexpected passes 307 unexpected failures 14 unexpected stat failures }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 10:57:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 10:57:19 -0000 Subject: [GHC] #10935: More unused and non-deprecated warning flags In-Reply-To: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> References: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> Message-ID: <058.32f26473b7ab0947329a732898d44466@haskell.org> #10935: More unused and non-deprecated warning flags -------------------------------------+------------------------------------- Reporter: osa1 | Owner: bernalex Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10752, #8176 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bernalex): * owner: => bernalex -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 12:26:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 12:26:32 -0000 Subject: [GHC] #10935: More unused and non-deprecated warning flags In-Reply-To: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> References: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> Message-ID: <058.59d62fb7381d4069372bbb9900d8b2bc@haskell.org> #10935: More unused and non-deprecated warning flags -------------------------------------+------------------------------------- Reporter: osa1 | Owner: bernalex Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10752, #8176 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): The only real issue here is: * Either reimplement or remove (it even has documentation!) `-fwarn- monomorphism-restriction` (it went away in d2ce0f52d "Super-monster patch implementing the new typechecker -- at last" from 2010) `-fwarn-alternative-layout-rule-transitional` is apparently intentionally not documented (49fc268e2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 13:01:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 13:01:39 -0000 Subject: [GHC] #10935: More unused and non-deprecated warning flags In-Reply-To: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> References: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> Message-ID: <058.3c07fe0ccb1005c72ca53fdd20afa419@haskell.org> #10935: More unused and non-deprecated warning flags -------------------------------------+------------------------------------- Reporter: osa1 | Owner: bernalex Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10752, #8176 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bernalex): I'll look into reimplementing the monomorphism restriction flag. I don't find ?I think the alternative layout rule flags are deliberately not documented at the moment? a very convincing argument. Maybe Ian can clarify? I don't know his trac account. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 13:22:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 13:22:01 -0000 Subject: [GHC] #10936: Can't fire up GHCi with Mueval In-Reply-To: <048.a6b78e942d795aa593f02c79cf06f467@haskell.org> References: <048.a6b78e942d795aa593f02c79cf06f467@haskell.org> Message-ID: <063.43241ffd09873547d52563f64926ce21@haskell.org> #10936: Can't fire up GHCi with Mueval -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1314 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"e331392e1891941916ee8e508a127ec7fec33d3d/ghc" e331392e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e331392e1891941916ee8e508a127ec7fec33d3d" Fix error msg: ghci can't be used with -prof or -static (#10936) Reviewed by: austin Differential Revision: https://phabricator.haskell.org/D1314 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 13:22:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 13:22:01 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.3e34c42045b0662f3a0124757f3820f9@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Phyx- Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D586 | Phab:D587 Phab:D1244 Phab:D1310 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"5d841108acef950fed6a5e608ac9b18e7431aa87/ghc" 5d84110/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5d841108acef950fed6a5e608ac9b18e7431aa87" Add short library names support to Windows linker Make Linker.hs try asking gcc for lib%s.dll as well, also changed tryGcc to pass -L to all components by using -B instead. These two fix shortnames linking on windows. re-enabled tests: ghcilink003, ghcilink006 and T3333 Added two tests: load_short_name and enabled T1407 on windows. Reviewed By: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1310 GHC Trac Issues: #9878, #1407, #1883, #5289 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 13:22:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 13:22:01 -0000 Subject: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files In-Reply-To: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> References: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> Message-ID: <059.89d9405095d28a12915e547c1c1a562b@haskell.org> #1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: archblob Type: feature request | Status: merge Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 6.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D194 | Phab:D1310 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"5d841108acef950fed6a5e608ac9b18e7431aa87/ghc" 5d84110/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5d841108acef950fed6a5e608ac9b18e7431aa87" Add short library names support to Windows linker Make Linker.hs try asking gcc for lib%s.dll as well, also changed tryGcc to pass -L to all components by using -B instead. These two fix shortnames linking on windows. re-enabled tests: ghcilink003, ghcilink006 and T3333 Added two tests: load_short_name and enabled T1407 on windows. Reviewed By: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1310 GHC Trac Issues: #9878, #1407, #1883, #5289 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 13:22:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 13:22:01 -0000 Subject: [GHC] #1883: GHC can't find library using "short" name In-Reply-To: <045.76e5dee1da7bd3e6c3d26431d4641cce@haskell.org> References: <045.76e5dee1da7bd3e6c3d26431d4641cce@haskell.org> Message-ID: <060.7ca336ec30eb00b468edb3c9ccd9d738@haskell.org> #1883: GHC can't find library using "short" name -------------------------------------+------------------------------------- Reporter: m4dc4p | Owner: Phyx- Type: bug | Status: patch Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: link library | windows Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #2283 #3242 | Differential Rev(s): Phab:D1310 #1883 #7097 | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"5d841108acef950fed6a5e608ac9b18e7431aa87/ghc" 5d84110/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5d841108acef950fed6a5e608ac9b18e7431aa87" Add short library names support to Windows linker Make Linker.hs try asking gcc for lib%s.dll as well, also changed tryGcc to pass -L to all components by using -B instead. These two fix shortnames linking on windows. re-enabled tests: ghcilink003, ghcilink006 and T3333 Added two tests: load_short_name and enabled T1407 on windows. Reviewed By: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1310 GHC Trac Issues: #9878, #1407, #1883, #5289 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 13:22:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 13:22:01 -0000 Subject: [GHC] #5289: Can't use ghci with a library linked against libstdc++ In-Reply-To: <042.ca5f68f0f4907cc12990f083dfa50f2f@haskell.org> References: <042.ca5f68f0f4907cc12990f083dfa50f2f@haskell.org> Message-ID: <057.acb8972c1c87d35d2b2f6588bdf2003b@haskell.org> #5289: Can't use ghci with a library linked against libstdc++ -------------------------------+---------------------------------------- Reporter: bos | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1310 -------------------------------+---------------------------------------- Comment (by Thomas Miedema ): In [changeset:"5d841108acef950fed6a5e608ac9b18e7431aa87/ghc" 5d84110/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5d841108acef950fed6a5e608ac9b18e7431aa87" Add short library names support to Windows linker Make Linker.hs try asking gcc for lib%s.dll as well, also changed tryGcc to pass -L to all components by using -B instead. These two fix shortnames linking on windows. re-enabled tests: ghcilink003, ghcilink006 and T3333 Added two tests: load_short_name and enabled T1407 on windows. Reviewed By: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1310 GHC Trac Issues: #9878, #1407, #1883, #5289 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 13:28:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 13:28:27 -0000 Subject: [GHC] #10936: Can't fire up GHCi with Mueval In-Reply-To: <048.a6b78e942d795aa593f02c79cf06f467@haskell.org> References: <048.a6b78e942d795aa593f02c79cf06f467@haskell.org> Message-ID: <063.92ab41bef0c6ec3c42fd5e1d958b16ea@haskell.org> #10936: Can't fire up GHCi with Mueval -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1314 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 13:28:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 13:28:37 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.4c68d3710a714e199cb7832746bd3f57@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I'm wondering if anyone's making any progress on this? I'm still suffering from this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 13:39:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 13:39:33 -0000 Subject: [GHC] #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" In-Reply-To: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> References: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> Message-ID: <060.752612d58b6d902676c37a428f01e581@haskell.org> #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fa5eabec43a71546afba6dec7508ae5afb23b805/ghc" fa5eabe/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fa5eabec43a71546afba6dec7508ae5afb23b805" sphinx: Don't share doctrees between targets Sphinx may trip over itself when multiple instances are run in parallel. Fixes #10950. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 13:39:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 13:39:33 -0000 Subject: [GHC] #10571: GHC 7.10.1 segfaults when shiftL-ing Integers by negative amounts In-Reply-To: <046.5fe10823e2d0a9badb1b3a63cbe8bcdb@haskell.org> References: <046.5fe10823e2d0a9badb1b3a63cbe8bcdb@haskell.org> Message-ID: <061.a4def2f812f56e20a60f287d54d8d2d9@haskell.org> #10571: GHC 7.10.1 segfaults when shiftL-ing Integers by negative amounts ----------------------------------+-------------------------------------- Reporter: anders_ | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ----------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"182c44da50db028a432a81789048c87922bd30f4/ghc" 182c44da/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="182c44da50db028a432a81789048c87922bd30f4" Keep `shift{L,R}` on `Integer` from segfaulting This can happen because the underlying primitive operations in `integer-gmp` don't support negative shift-amounts, and since `integer-gmp` can't throw proper exceptions and just provides a low-level API, it simply segfaults instead... This patch simply removes the `shift{L,R}` method definitions (and defines `unsafeShift{L,R}` instead) whose default-impls fallback on using `shift` which properly handles negative shift arguments. This addresses #10571 Test Plan: harbormaster can do it Reviewers: hvr, austin, rwbarton Subscribers: rwbarton, thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1018 GHC Trac Issues: #10571 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 13:44:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 13:44:45 -0000 Subject: [GHC] #1883: GHC can't find library using "short" name In-Reply-To: <045.76e5dee1da7bd3e6c3d26431d4641cce@haskell.org> References: <045.76e5dee1da7bd3e6c3d26431d4641cce@haskell.org> Message-ID: <060.bade729412e51e6f85e06a4698b5b841@haskell.org> #1883: GHC can't find library using "short" name -------------------------------------+------------------------------------- Reporter: m4dc4p | Owner: Phyx- Type: bug | Status: closed Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.6.1 Resolution: fixed | Keywords: link library | windows Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #2283 #3242 | Differential Rev(s): Phab:D1310 #1883 #7097 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 13:45:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 13:45:13 -0000 Subject: [GHC] #5289: Can't use ghci with a library linked against libstdc++ In-Reply-To: <042.ca5f68f0f4907cc12990f083dfa50f2f@haskell.org> References: <042.ca5f68f0f4907cc12990f083dfa50f2f@haskell.org> Message-ID: <057.773712e7cca2a1005cac1720638a7dc4@haskell.org> #5289: Can't use ghci with a library linked against libstdc++ -------------------------------+---------------------------------------- Reporter: bos | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.0.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1310 Wiki Page: | -------------------------------+---------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 14:12:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 14:12:13 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.5426bb5707a14af083e077ce4029bb59@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) Comment: I should say that I'm willing to work on this myself, but I have no ideas how TH splices compiled/linked etc. and what's the deal with package ids. If someone can give me some pointers I'd like to give it a try. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 15:21:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 15:21:29 -0000 Subject: [GHC] #3333: GHCi doesn't load weak symbols In-Reply-To: <047.f7df20b3080234226b9f5744151738a8@haskell.org> References: <047.f7df20b3080234226b9f5744151738a8@haskell.org> Message-ID: <062.8c10ac02697e634b89075132a12a7b1b@haskell.org> #3333: GHCi doesn't load weak symbols -------------------------------------+------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 6.10.4 Resolution: fixed | Keywords: weak, dynamic | loading Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): In commit 736ed65532d12a3d2d8c79a1dcce1004499bc740: {{{ Author: Takano Akio Date: Sat Dec 29 11:47:22 2012 +0900 Linker.c: remove stablehash, which is no longer used Signed-off-by: Austin Seipp }}} In commit 41fb63668352eb4f04f4aaca27ef3ad09025afc3: {{{ Author: Takano Akio <> Date: Sat Dec 29 11:59:34 2012 +0900 ghci: add support for ELF weak symbols Signed-off-by: Austin Seipp }}} In commit 645eadb99493129a53021e31c43d3526eb59a496: {{{ Author: Takano Akio <> Date: Sun Jan 6 17:51:19 2013 +0900 Linker.c: add dso_handle to the symbol table Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 15:31:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 15:31:53 -0000 Subject: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space In-Reply-To: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> References: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> Message-ID: <064.8b4458de4b78965c5dff4148b46a3464@haskell.org> #5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: dimitris Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by basvandijk): Just a heads-ups that a user of aeson just [https://github.com/bos/aeson/issues/296 ran into this]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 15:38:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 15:38:50 -0000 Subject: [GHC] #10955: GHC on windows does not resolve DLL dependencies Message-ID: <044.d1371f1a3dafc9d7220a00358a56f239@haskell.org> #10955: GHC on windows does not resolve DLL dependencies -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime | Version: 7.10.2 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC does not correctly tell the Windows Loader how to handle dependencies to dll's that are not on the standard windows load path: 1. The directory from which the application loaded. 2. The current directory. 3. The system directory. Use the `GetSystemDirectory` function to get the path of this directory. 4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched. 5. The Windows directory. Use the `GetWindowsDirectory` function to get the path of this directory. 6. The directories that are listed in the `PATH` environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path. So what this means is given two DLLs `A` and `B` and `B` depending on `A`. If we put both DLLs into a new folder `bin` and then call GHC with: `ghc -L$(PWD)/bin -lB` the loading will fail as the Windows loader will try to load the dependency of `B` and fail since it cannot find `A`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 15:40:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 15:40:09 -0000 Subject: [GHC] #10955: GHC on windows does not resolve DLL dependencies In-Reply-To: <044.d1371f1a3dafc9d7220a00358a56f239@haskell.org> References: <044.d1371f1a3dafc9d7220a00358a56f239@haskell.org> Message-ID: <059.1aaf55ec64911ea6c08a5adf7a3519fd@haskell.org> #10955: GHC on windows does not resolve DLL dependencies -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 (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 Phyx-): There are new APIs introduced in Windows vista+ that allow us to modify the loader load path reliably. However this means dropping XP support. If XP Support is required we can resort to modifying the `PATH` variables. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 15:44:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 15:44:41 -0000 Subject: [GHC] #7298: GHCi is setting stdin/stdout to NoBuffering in runghc when DYNAMIC_GHC_PROGRAMS=YES (was: Test 2228 fails with dynamic-by-default) In-Reply-To: <044.34213a5738911dce009c62eab496ee22@haskell.org> References: <044.34213a5738911dce009c62eab496ee22@haskell.org> Message-ID: <059.ac71c1093711f63c0a4a5efbd8a0338c@haskell.org> #7298: GHCi is setting stdin/stdout to NoBuffering in runghc when DYNAMIC_GHC_PROGRAMS=YES -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghc-e/should_run/T2228 Blocked By: | Blocking: Related Tickets: #2228 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * cc: hvr (removed) * related: => #2228 * testcase: => ghc-e/should_run/T2228 * resolution: wontfix => Comment: This issue is not fixed. According to ticket:2228#6, `runghc` shouldn't set stdin/stdout to `NoBuffering`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 16:31:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 16:31:41 -0000 Subject: [GHC] #3333: GHCi doesn't load weak symbols In-Reply-To: <047.f7df20b3080234226b9f5744151738a8@haskell.org> References: <047.f7df20b3080234226b9f5744151738a8@haskell.org> Message-ID: <062.ad56c9eb7b275de076898fda8513c524@haskell.org> #3333: GHCi doesn't load weak symbols -------------------------------------+------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 6.10.4 Resolution: fixed | Keywords: weak, dynamic | loading Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"614ce4b0b93ec1f9c308589b956b725535c57111/ghc" 614ce4b0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="614ce4b0b93ec1f9c308589b956b725535c57111" Testsuite: T3333 still fails on non-linux statically linked ghci (#3333) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 16:32:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 16:32:58 -0000 Subject: [GHC] #3333: GHCi doesn't load weak symbols In-Reply-To: <047.f7df20b3080234226b9f5744151738a8@haskell.org> References: <047.f7df20b3080234226b9f5744151738a8@haskell.org> Message-ID: <062.d1dc87169003b378e713d6e644d17b9c@haskell.org> #3333: GHCi doesn't load weak symbols -------------------------------------+------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 6.10.4 Resolution: | Keywords: weak, dynamic | loading 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 thomie): * status: closed => new * os: Linux => Unknown/Multiple * priority: high => normal * architecture: x86 => Unknown/Multiple * milestone: 7.8.1 => 8.0.1 * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 18:08:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 18:08:53 -0000 Subject: [GHC] #10956: Allow default keyboard behavior to be easily overriden Message-ID: <055.2754ac4eafd0365b8157ce3312593a45@haskell.org> #10956: Allow default keyboard behavior to be easily overriden -------------------------------------+------------------------------------- Reporter: | Owner: BalinKingOfMoria | Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: io input raw | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I press the up or down arrow keys, GHC kicks in and makes it so that the last line of text comes back instead of letting me intercept the arrow key. From what I have seen, you need third-party libraries to override the default behavior, but when would a user actually want that behavior in an application instead of letting the programmer handle it? Can there be a switch (like a special LANGUAGE pragma or whatever) to enable raw input capture? Console text editing applications are greatly hindered by this automatic behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 18:23:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 18:23:19 -0000 Subject: [GHC] #10956: Allow default keyboard behavior to be easily overriden In-Reply-To: <055.2754ac4eafd0365b8157ce3312593a45@haskell.org> References: <055.2754ac4eafd0365b8157ce3312593a45@haskell.org> Message-ID: <070.fc4a8ee5aee30033881e15fa2d1678ee@haskell.org> #10956: Allow default keyboard behavior to be easily overriden -------------------------------------+------------------------------------- Reporter: BalinKingOfMoria | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: io input raw Operating System: Windows | 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 ezyang): Do you mean... in GHCi? GHCi uses readline, which is why you see this behavior. If you just have a normal GHC compiled program, you get raw input capture. (Of course, actually programming this correctly is quite involved, which is why people use libraries like ncurses in this case.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 18:54:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 18:54:20 -0000 Subject: [GHC] #10956: Allow default keyboard behavior to be easily overriden In-Reply-To: <055.2754ac4eafd0365b8157ce3312593a45@haskell.org> References: <055.2754ac4eafd0365b8157ce3312593a45@haskell.org> Message-ID: <070.5f1a79e69de9451bfd84b85afd3ecdd8@haskell.org> #10956: Allow default keyboard behavior to be easily overriden -------------------------------------+------------------------------------- Reporter: BalinKingOfMoria | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: io input raw Operating System: Windows | 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 rwbarton): Since this is on Windows, I wouldn't put it past the console to do this whenever the terminal is in cooked mode (or Windows equivalent). Maybe you just want `hSetBuffering stdin NoBuffering`? That would put the terminal in raw mode on non-Windows systems, but apparently it doesn't work on Windows, see #2189. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 19:26:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 19:26:20 -0000 Subject: [GHC] #10956: Allow default keyboard behavior to be easily overriden In-Reply-To: <055.2754ac4eafd0365b8157ce3312593a45@haskell.org> References: <055.2754ac4eafd0365b8157ce3312593a45@haskell.org> Message-ID: <070.4c5a44d9f0d6a5a0f70352e25868cddb@haskell.org> #10956: Allow default keyboard behavior to be easily overriden -------------------------------------+------------------------------------- Reporter: BalinKingOfMoria | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: io input raw Operating System: Windows | 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 BalinKingOfMoria): Replying to [comment:1 ezyang]: > Do you mean... in GHCi? GHCi uses readline, which is why you see this behavior. If you just have a normal GHC compiled program, you get raw input capture. (Of course, actually programming this correctly is quite involved, which is why people use libraries like ncurses in this case.) No, it's GHC (I already tried); "ghc editor.hs" would do it, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 19:28:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 19:28:17 -0000 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@haskell.org> References: <047.b31f95b84e60784da45a33105d44ed84@haskell.org> Message-ID: <062.4d69d7654ad241bc7f777a5f0b804c59@haskell.org> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows -------------------------------------+------------------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Core Libraries | Version: 6.8.2 Resolution: | Keywords: hsetbuffering | buffering buffer Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by BalinKingOfMoria): * cc: ekmett (added) * milestone: 8.0.1 => 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 19:30:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 19:30:46 -0000 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@haskell.org> References: <047.b31f95b84e60784da45a33105d44ed84@haskell.org> Message-ID: <062.ccc53fb82db475367131a46cee2ef9fc@haskell.org> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows -------------------------------------+------------------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 6.8.2 Resolution: | Keywords: hsetbuffering | buffering buffer Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * milestone: 7.10.3 => 8.0.1 Comment: Definitely not going to happen for 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 19:33:25 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 19:33:25 -0000 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@haskell.org> References: <047.b31f95b84e60784da45a33105d44ed84@haskell.org> Message-ID: <062.d5f60bf3dcd614d52b43c9e62f846f36@haskell.org> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows -------------------------------------+------------------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 6.8.2 Resolution: | Keywords: hsetbuffering | buffering buffer Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by BalinKingOfMoria): Replying to [comment:48 rwbarton]: > Definitely not going to happen for 7.10.3. In the meantime, are there any viable workarounds (that haven't since been rolled back)? Raw input would be very helpful on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 20:47:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 20:47:40 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.50f58df90af7d139c8773e6316e3ffcc@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1284 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): RyanGIScott: The plan around any sort of eventual consolidation of `First` and `Last` is definitely punted several years down the road. Once `Maybe` has the `Semigroup`-based `Monoid` instance, `Maybe (First a)` using the semigroup `First` has more or less the semantics of the existing monoidal `First a`. However, at this current moment such things have to be implemented in terms of `Option`, which is considerably more painful! After enough time has passed I can envision a situation where we might eventually choose to deprecate the existing Monoid versions, but that is far enough out that any proposal about it at this stage would be so much hand-waving. If it takes us 3 years to get `Semigroup` in as a superclass of `Monoid`, it'd likely take us another 3 years to get to where the new `Semigroup` forms of those constructions have wide enough distribution to even start considering deprecation of the originals. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 21:16:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 21:16:58 -0000 Subject: [GHC] #1883: GHC can't find library using "short" name In-Reply-To: <045.76e5dee1da7bd3e6c3d26431d4641cce@haskell.org> References: <045.76e5dee1da7bd3e6c3d26431d4641cce@haskell.org> Message-ID: <060.2d9b1beec86aecdede15098b1d1c9c2b@haskell.org> #1883: GHC can't find library using "short" name -------------------------------------+------------------------------------- Reporter: m4dc4p | Owner: Phyx- Type: bug | Status: closed Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.6.1 Resolution: fixed | Keywords: link library | windows Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #2283 #3242 | Differential Rev(s): Phab:D1310 #1883 #7097 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by m4dc4p): So awesome to see this fixed! nice work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 10 23:45:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Oct 2015 23:45:14 -0000 Subject: [GHC] #10913: deprecate and then remove -fwarn-hi-shadowing In-Reply-To: <043.5271c7f4effd317ccfe2016268f0bde8@haskell.org> References: <043.5271c7f4effd317ccfe2016268f0bde8@haskell.org> Message-ID: <058.8ebe325bec00051c3b6c5e902875e49d@haskell.org> #10913: deprecate and then remove -fwarn-hi-shadowing -------------------------------------+------------------------------------- Reporter: osa1 | Owner: ChrisU Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.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 ChrisU): Should I deprecate it, or just remove it immediately? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 11 01:00:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Oct 2015 01:00:57 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.fdf092b3db3430b5a6e726c76b8a2c5c@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1284 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): bgamari: Regarding `words`, that simply looks like a bug and it should have the type you've suggested. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 11 05:14:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Oct 2015 05:14:34 -0000 Subject: [GHC] #10870: PPC.Ppr: Shift by 32 bits is not allowed. In-Reply-To: <046.266af0561f46fb382b81907ac208339a@haskell.org> References: <046.266af0561f46fb382b81907ac208339a@haskell.org> Message-ID: <061.b2b7bca429c840b8e4597baa597f3d19@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1322 Wiki Page: | ---------------------------------------+---------------------------------- Changes (by erikd): * differential: => Phab:D1322 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 11 10:09:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Oct 2015 10:09:55 -0000 Subject: [GHC] #10957: getExecutablePath adds " (deleted)" suffix if executable was deleted under linux Message-ID: <047.9c6f417035b8e10ce588ba217f863194@haskell.org> #10957: getExecutablePath adds " (deleted)" suffix if executable was deleted under linux -------------------------------------+------------------------------------- Reporter: aslpavel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.2 Libraries | Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If we remove current executable or update it with a new one, getExecutablePath returns path with added " (deleted)" suffix. I think it is incorrect behavior , for example if you updated binary and want to exec a new one, the obvious way to go is to call getExecutablePath and use it. Moreover it is inconsistent between platforms. Problem stems from the fact the getExecutablePath is implemented as readlink on /proc/self/exe and it contains gibberish once file has been deleted. Example: {{{#!hs module Main (main) where import System.Environment (getExecutablePath) import System.Directory (removeFile) main :: IO () main = do before <- getExecutablePath putStrLn $ "Before: " ++ before removeFile before after <- getExecutablePath putStrLn $ "After: " ++ after }}} Output: {{{ $ ./getExecutablePath Before: /mnt/data/Maggot/getExecutablePath After: /mnt/data/Maggot/getExecutablePath (deleted) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 11 12:05:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Oct 2015 12:05:15 -0000 Subject: [GHC] #10958: "Annotating pure code for parallelism" docs based on old par/pseq primitives Message-ID: <051.c6c45266fc5f87d1eb4c881e200bec98@haskell.org> #10958: "Annotating pure code for parallelism" docs based on old par/pseq primitives -------------------------------------+------------------------------------- Reporter: robstewartuk | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Keywords: parallelim | 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 example code in GHC 7.10.2 docs "7.28. Concurrent and Parallel Haskell", then in "7.15.4. Annotating pure code for parallelism" the recommendation is to use `par` and `pseq`. These primitives pre-dates the strategy combinators `rpar` and `rseq`. The example given is: {{{#!hs import Control.Parallel nfib :: Int -> Int nfib n | n <= 1 = 1 | otherwise = par n1 (seq n2 (n1 + n2 + 1)) where n1 = nfib (n-1) n2 = nfib (n-2) }}} The paper "Seq no more: Better Strategies for Parallel Haskell" ([http://www.macs.hw.ac.uk/~hwloidl/publications/strategies10.pdf]) advocates `Eval` as an "evaluation order" monad, as preferable (versus `par` and `seq`) for loose control of evaluation order of parallelism. Moreover, Simon Marlow's "Parallel and Concurrent Programming in Haskell" doesn't mention the `par` and `seq` primitives at all. Should the GHC docs for "Concurrent and Parallel Haskell" encourage the use Eval combinators, either in addition to or instead of the `par` and `seq` primitives? I'd be happy to contribute an update to the docs if people agree to a shift in emphasis towards the Eval monad in the docs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 11 13:51:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Oct 2015 13:51:24 -0000 Subject: [GHC] #10959: MINIMAL pragma and default implementations Message-ID: <049.85d8787946f3bf6572d68ae7b06b8e4f@haskell.org> #10959: MINIMAL pragma and default implementations -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 `ToJSON` class from the `aeson` library recently gained the new method `toEncoding` which has a default implementation based on the existing `toJSON` method. A MINIMAL pragma was added to `toJSON` to make sure instances will define it. However, `toJSON` also has a default implementation but only if the type has an instance for `Generic`: {{{ class ToJSON a where toJSON :: a -> Value {-# MINIMAL toJSON #-} default toJSON :: (Generic a, GToJSON (Rep a)) => a -> Value toJSON = genericToJSON defaultOptions toEncoding :: a -> Encoding toEncoding = Encoding . E.encodeToBuilder . toJSON }}} The problem is that users of `aeson` who are using the generic implementation get warnings that their `toJSON` method is not defined: {{{ No explicit implementation for ?toJSON? In the instance declaration for ?ToJSON MyType? }}} It would be nice if GHC is a bit smarter in this case so that when a a default implementation is used it won't give the warning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 11 20:07:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Oct 2015 20:07:37 -0000 Subject: [GHC] #10959: MINIMAL pragma and default implementations In-Reply-To: <049.85d8787946f3bf6572d68ae7b06b8e4f@haskell.org> References: <049.85d8787946f3bf6572d68ae7b06b8e4f@haskell.org> Message-ID: <064.1aa7c886ff920c002e0280f09b867d4a@haskell.org> #10959: MINIMAL pragma and default implementations -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | 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: | -------------------------------------+------------------------------------- Comment (by hvr): Why is there a `MINIMAL` pragma in the first place btw? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 11 20:38:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Oct 2015 20:38:15 -0000 Subject: [GHC] #10959: MINIMAL pragma and default implementations In-Reply-To: <049.85d8787946f3bf6572d68ae7b06b8e4f@haskell.org> References: <049.85d8787946f3bf6572d68ae7b06b8e4f@haskell.org> Message-ID: <064.c76f8b711c5fe4f5e89233f900e523bd@haskell.org> #10959: MINIMAL pragma and default implementations -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | 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: | -------------------------------------+------------------------------------- Comment (by basvandijk): I guess Bryan added because it's the only required method to implement since `toEncoding` is defined in terms of it. However I just read in the GHC user guide that: "If no MINIMAL pragma is given in the class declaration, it is just as if a pragma {-# MINIMAL op1, op2, ..., opn #-} was given, where the opi are the methods (a) that lack a default method in the class declaration..." So this means we can just safely remove the pragma. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 11 21:29:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Oct 2015 21:29:01 -0000 Subject: [GHC] #10956: Allow default keyboard behavior to be easily overriden In-Reply-To: <055.2754ac4eafd0365b8157ce3312593a45@haskell.org> References: <055.2754ac4eafd0365b8157ce3312593a45@haskell.org> Message-ID: <070.d45e1b29bbaf98be66b7bd30a7bb84f5@haskell.org> #10956: Allow default keyboard behavior to be easily overriden -------------------------------------+------------------------------------- Reporter: BalinKingOfMoria | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: io input raw Operating System: Windows | 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 goldfire): Can you describe the sequence of steps necessary to reproduce? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 11 21:31:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Oct 2015 21:31:31 -0000 Subject: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space In-Reply-To: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> References: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> Message-ID: <064.9225a8b6fd29956403a7b8197d8d1816@haskell.org> #5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: dimitris => bgamari Comment: I'll be looking into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 11 21:40:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Oct 2015 21:40:26 -0000 Subject: [GHC] #10583: Chaos in Lexeme.hs In-Reply-To: <047.ca228b2a0d43586fb2828ecd680f46fc@haskell.org> References: <047.ca228b2a0d43586fb2828ecd680f46fc@haskell.org> Message-ID: <062.beee30b257665516d80ca0ccb5da5514@haskell.org> #10583: Chaos in Lexeme.hs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 10582 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Update: This just got a bit more annoying, because some of the chaotic implementation has been moved to `ghc-boot`. See Phab:D1313. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 11 21:52:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Oct 2015 21:52:26 -0000 Subject: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space In-Reply-To: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> References: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> Message-ID: <064.25fb2791043b49cdf7d933635699919e@haskell.org> #5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record this sounds quite similar to #8095 in that the compiler seems to be creating long strings of coercions (although here the simplifier doesn't even seem capable of eliminating them). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 11 21:52:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Oct 2015 21:52:52 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.6b5845c18795155297c16470dfb7e37d@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 5321 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm not yet certain but #5645 may be another instance of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 11 22:08:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Oct 2015 22:08:33 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.6415bdde6a643b725e9d63de622e9236@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1323 Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * differential: => Phab:D1323 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 11 22:13:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Oct 2015 22:13:50 -0000 Subject: [GHC] #10956: Allow default keyboard behavior to be easily overriden In-Reply-To: <055.2754ac4eafd0365b8157ce3312593a45@haskell.org> References: <055.2754ac4eafd0365b8157ce3312593a45@haskell.org> Message-ID: <070.25ba99261b554a5ef718596f3891c93a@haskell.org> #10956: Allow default keyboard behavior to be easily overriden -------------------------------------+------------------------------------- Reporter: BalinKingOfMoria | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: io input raw Operating System: Windows | 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 BalinKingOfMoria): Replying to [comment:4 goldfire]: > Can you describe the sequence of steps necessary to reproduce? Thanks! 1. Setup prompt at Windows console (infinite recursion with getLine will do it) 2. Type something into the prompt and hit Enter 3. Press the up arrow and watch the text you entered last come back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 11 22:18:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Oct 2015 22:18:11 -0000 Subject: [GHC] #10956: Allow default keyboard behavior to be easily overriden In-Reply-To: <055.2754ac4eafd0365b8157ce3312593a45@haskell.org> References: <055.2754ac4eafd0365b8157ce3312593a45@haskell.org> Message-ID: <070.6148c7256a77949162f63d823894158e@haskell.org> #10956: Allow default keyboard behavior to be easily overriden -------------------------------------+------------------------------------- Reporter: BalinKingOfMoria | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: io input raw Operating System: Windows | 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 rwbarton): You skipped some steps in step 1. I *think* what you mean is: 1a. Create this file `uptest.hs` {{{ import Control.Monad main = forever getLine }}} 1b. Compile with `ghc uptest` 1c. Run `./uptest` (or whatever Windows equivalent) but I'm not sure especially about 1b and 1c, so please correct me if this is wrong! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 11 22:24:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Oct 2015 22:24:28 -0000 Subject: [GHC] #10956: Allow default keyboard behavior to be easily overriden In-Reply-To: <055.2754ac4eafd0365b8157ce3312593a45@haskell.org> References: <055.2754ac4eafd0365b8157ce3312593a45@haskell.org> Message-ID: <070.414bd08b877dcdf52940ecbb2776a553@haskell.org> #10956: Allow default keyboard behavior to be easily overriden -------------------------------------+------------------------------------- Reporter: BalinKingOfMoria | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: io input raw Operating System: Windows | 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 BalinKingOfMoria): Sorry for the confusion... I just used getLine as an example of the function to get input. The program (test.hs) would look something like this {{{ main = do getLine main }}} I'd then run "ghc test.hs" at the command line and "test" to run the program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 00:12:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 00:12:17 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.4849fb314a33f02658fe647522ebb91a@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1323 Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Haven't run the full test suite yet, but running: {{{ make test TEST="print018 print020 print021 print022 print025 ghci053 ghcirun001 ghcirun002" }}} which used to result in 8 failing tests, now results in 8 passing tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 04:03:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 04:03:30 -0000 Subject: [GHC] #10870: PPC.Ppr: Shift by 32 bits is not allowed. In-Reply-To: <046.266af0561f46fb382b81907ac208339a@haskell.org> References: <046.266af0561f46fb382b81907ac208339a@haskell.org> Message-ID: <061.97294f3c08c105c2f8726fd6c975619c@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1322 Wiki Page: | ---------------------------------------+---------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"4bd58c179b8d0f8cf2850acb920cef8605826a2a/ghc" 4bd58c1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4bd58c179b8d0f8cf2850acb920cef8605826a2a" PPC: Fix right shift by 32 bits #10870 Summary: Test included. Test Plan: Run test T10870.hs on X86/X86_64/Arm/Arm64 etc Reviewers: bgamari, nomeata, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1322 GHC Trac Issues: #10870 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 04:14:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 04:14:17 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.119537f5d6feb1f4f3a257c5f20b8233@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1323 Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): After running the full test suite: {{{ OVERALL SUMMARY for test run started at Mon Oct 12 11:15:08 2015 AEDT 3:52:23 spent to go through 4694 total tests, which gave rise to 14893 test cases, of which 10265 were skipped 72 had missing libraries 4445 expected passes 100 expected failures 0 caused framework failures 0 unexpected passes 9 unexpected failures 2 unexpected stat failures Unexpected failures: codeGen/should_compile T10518 [exit code non-0] (normal) codeGen/should_run CmmSwitchTest [exit code non-0] (normal,g1) numeric/should_run T8726 [bad exit code] (normal) primops/should_run T9430 [bad exit code] (normal) programs/barton-mangler-bug barton-mangler-bug [exit code non-0] (normal) programs/joao-circular joao-circular [exit code non-0] (normal) rts T3424 [exit code non-0] (normal) rts outofmem [bad stdout] (normal) Unexpected stat failures: perf/should_run Conversions [stat not good enough] (normal) perf/should_run T9203 [stat not good enough] (normal) }}} All of the ghci test failures are gone! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 08:20:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 08:20:01 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.312825422e3bab7ae431239799d2befe@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by erikd): I now seem to have GHCi working as well. Current version is in the `wip/aarch64-regd` branch of the main repo. Tomorrow I will clean this up and submit a Phab review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 08:45:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 08:45:22 -0000 Subject: [GHC] #10959: MINIMAL pragma and default implementations In-Reply-To: <049.85d8787946f3bf6572d68ae7b06b8e4f@haskell.org> References: <049.85d8787946f3bf6572d68ae7b06b8e4f@haskell.org> Message-ID: <064.123059cc990bf3bbf03ceb7cdb6d8fbe@haskell.org> #10959: MINIMAL pragma and default implementations -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): So is the conclusion here that GHC doesn't need to be smarter; it's a source-code issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 08:53:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 08:53:30 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.6c55f92f7114aee2d81a75fd071b6e0c@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by erikd): Now that GHCi is working: {{{ OVERALL SUMMARY for test run started at Mon Oct 12 08:37:45 2015 UTC 0:30:52 spent to go through 4695 total tests, which gave rise to 14901 test cases, of which 10255 were skipped 72 had missing libraries 4284 expected passes 100 expected failures 22 caused framework failures 0 unexpected passes 172 unexpected failures 14 unexpected stat failures }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 09:04:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 09:04:07 -0000 Subject: [GHC] #10951: HPC program has poor error reporting / strange CLI in general In-Reply-To: <046.0eb67759af4f01648e433f1249d67ab5@haskell.org> References: <046.0eb67759af4f01648e433f1249d67ab5@haskell.org> Message-ID: <061.d6335f163582ba91a31b0170f42061af@haskell.org> #10951: HPC program has poor error reporting / strange CLI in general -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Code Coverage | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: andygill@? (added) Comment: 1. yes 2. is it worth breaking backward compatibility here, after 1. is fixed? Maybe there are scripts in existence that make use of positional arguments. 3. seems like a less pressing need, but why not. This effectively folds `hpc combine` into `hpc report` and `hpc markup`, using a new `--tixfile` or so flag. Might be difficult to explain why `hpc sum` and `hpc combine` still exist after this. 4. maybe not needed anymore, now that `-hpcdir` takes absolute paths, but why not. 5. should be fixed, but please make changes as you see fit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 09:05:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 09:05:10 -0000 Subject: [GHC] #10959: MINIMAL pragma and default implementations In-Reply-To: <049.85d8787946f3bf6572d68ae7b06b8e4f@haskell.org> References: <049.85d8787946f3bf6572d68ae7b06b8e4f@haskell.org> Message-ID: <064.3aa40a7fbe0a2462ecc30ceb53dfd406@haskell.org> #10959: MINIMAL pragma and default implementations -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | 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: | -------------------------------------+------------------------------------- Comment (by basvandijk): > So is the conclusion here that GHC doesn't need to be smarter; it's a source-code issue? Not really. I can fix it in aeson by simply removing the MINIMAL pragma but the issue does remain for other cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 09:22:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 09:22:57 -0000 Subject: [GHC] #10959: MINIMAL pragma and default implementations In-Reply-To: <049.85d8787946f3bf6572d68ae7b06b8e4f@haskell.org> References: <049.85d8787946f3bf6572d68ae7b06b8e4f@haskell.org> Message-ID: <064.16c40f9b42cb1562adcdb1579d7f39c0@haskell.org> #10959: MINIMAL pragma and default implementations -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): OK. Can you give a small standalone case that illustrates the issue you are raising? I don't get it yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 09:42:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 09:42:54 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.a046ec4b74670d7be63d4194b180b93a@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by edmund): That sounds good! Are you sure that commit cc4522de4b60d975836a444a61a123011a496349 ("Fix clobbered regs list for aarch64 StgRun") is correct and necessary? Firstly, why is "%d15" missing from the list? Secondly, why are callee- save registers being saved and restored by the assembly code AND being described as clobbered so that the C compiler generates code to save and restore them? Isn't that just going to result in all those registers being saved and restored twice? However, it presumably doesn't hurt the correctness, so perhaps you should for now just add "%d15" to the list and insert a warning comment: "Callee- save registers are perhaps being saved and restored twice, redundantly!" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 09:44:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 09:44:39 -0000 Subject: [GHC] #1853: hpc mix files for Main modules overwrite each other In-Reply-To: <044.9b946ad54a9a35d3915c7a74c107b816@haskell.org> References: <044.9b946ad54a9a35d3915c7a74c107b816@haskell.org> Message-ID: <059.7562b33cc412ce2f08eea5f8452a6bc9@haskell.org> #1853: hpc mix files for Main modules overwrite each other ----------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Code Coverage | Version: 6.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by thomie): * cc: andygill@? (added) Comment: @AndyGill: any comments on the proposal from comment:18? @mgsloan: I'm still curious what Andy (the creator of hpc) had in mind in comment:12, but if your proposal solves the problem, and you don't hear from Andy, please go ahead. Sorry for not giving real feedback. I don't really know much about hpc at all, and I don't think anyone else does either (*cough* technical debt *cough*), but I trust you to do the right thing and will make sure your patches get reviewed/merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 10:12:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 10:12:36 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.302dbe99db6b3da057da4a91769aa100@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 5321 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What makes you think they are connected? #5645 is to do with sharing a big data structure at runtime. This ticket is about big coercion structures at compile time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 10:19:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 10:19:09 -0000 Subject: [GHC] #10942: CPP pragma ignored if top comments and Opt_KeepRawTokenStream In-Reply-To: <044.3dc1d52508bafa33dfb53526bcdd251c@haskell.org> References: <044.3dc1d52508bafa33dfb53526bcdd251c@haskell.org> Message-ID: <059.a5a8de6af79357151b4ddb47e7f40b64@haskell.org> #10942: CPP pragma ignored if top comments and Opt_KeepRawTokenStream -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 (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 thomie): * component: Compiler => Compiler (Parser) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 10:21:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 10:21:33 -0000 Subject: [GHC] #10733: Improving the error message for type variable ambiguity In-Reply-To: <049.e68ae3d7f8aaef94b3cdeb692d3e5ac5@haskell.org> References: <049.e68ae3d7f8aaef94b3cdeb692d3e5ac5@haskell.org> Message-ID: <064.5d219b481535db7592d753df5c5cad38@haskell.org> #10733: Improving the error message for type variable ambiguity -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: kanetw Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/tcfail133 and | others Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1182 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => typecheck/should_fail/tcfail133 and others * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 10:23:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 10:23:47 -0000 Subject: [GHC] #10747: Infix pattern synonyms fail to parse (regression) In-Reply-To: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> References: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> Message-ID: <063.a1c2c3552a1196c35dc619cc09e80c78@haskell.org> #10747: Infix pattern synonyms fail to parse (regression) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: mpickering Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | patsyn/should_compile/T10747 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1295 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => merge * testcase: => patsyn/should_compile/T10747 Comment: One line fix, should be easy to merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 10:25:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 10:25:55 -0000 Subject: [GHC] #10498: "if ... then \case -> else ..." causes a "missing else clause" error In-Reply-To: <050.28cad0c5bb9248828a1f63b683a53853@haskell.org> References: <050.28cad0c5bb9248828a1f63b683a53853@haskell.org> Message-ID: <065.6e9c5f59bf1223dd040ead54a8bc1985@haskell.org> #10498: "if ... then \case -> else ..." causes a "missing else clause" error -------------------------------------+------------------------------------- Reporter: dramforever | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1309 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 10:27:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 10:27:53 -0000 Subject: [GHC] #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" In-Reply-To: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> References: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> Message-ID: <060.bf849042280524b3be2a2bc7525f39ac@haskell.org> #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: Assuming this is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 11:00:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 11:00:58 -0000 Subject: [GHC] #10957: getExecutablePath adds " (deleted)" suffix if executable was deleted under linux In-Reply-To: <047.9c6f417035b8e10ce588ba217f863194@haskell.org> References: <047.9c6f417035b8e10ce588ba217f863194@haskell.org> Message-ID: <062.476a08f27796d81f531e1fc7c492f86c@haskell.org> #10957: getExecutablePath adds " (deleted)" suffix if executable was deleted under linux -------------------------------------+------------------------------------- Reporter: aslpavel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): What are you proposing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 11:02:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 11:02:48 -0000 Subject: [GHC] #10611: Runtime crash while running psc In-Reply-To: <044.6711fcf2994b3fa4d0ff74f3c08bc1a4@haskell.org> References: <044.6711fcf2994b3fa4d0ff74f3c08bc1a4@haskell.org> Message-ID: <059.f729fc2f1ed25d9bbb1771e6d25c1703@haskell.org> #10611: Runtime crash while running psc ----------------------------------+-------------------------------------- Reporter: qxjit | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 qxjit): That's quite difficult since I wasn't able to reproduce it originally. Feel free to close the ticket if nothing can be done without more info. Sorry for taking up your time! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 11:13:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 11:13:25 -0000 Subject: [GHC] #10611: Runtime crash while running psc In-Reply-To: <044.6711fcf2994b3fa4d0ff74f3c08bc1a4@haskell.org> References: <044.6711fcf2994b3fa4d0ff74f3c08bc1a4@haskell.org> Message-ID: <059.18d0375f26aeec63c9908e99e49e543b@haskell.org> #10611: Runtime crash while running psc ----------------------------------+-------------------------------------- Reporter: qxjit | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: worksforme | 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 thomie): * status: infoneeded => closed * resolution: => worksforme Comment: Replying to [comment:2 qxjit]: > That's quite difficult since I wasn't able to reproduce it originally. Feel free to close the ticket if nothing can be done without more info. Ok, I will. Bugs that resulted in the same error message have been fixed since 7.8.3, so I hope this one is fixed as well. Thanks for reporting, and don't hesitate to report any future issues you might run into. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 12:31:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 12:31:26 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.8d77f35cd74390840d5fa7d3717cd640@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10528 | Differential Rev(s): Phab:D1246 Wiki Page: | -------------------------------------+------------------------------------- Comment (by afarmer): Alright, I built 7.10.2+LHS patch+this patch and then used that to build stackage (LTS 3.8) as a smoke test. Every package built and tested (for whatever testing stackage-curator does) successfully. I'll see if I can run benchmark suite on something like text/aeson as a further smoke test, but hopefully this is good to go. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 13:10:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 13:10:48 -0000 Subject: [GHC] #10959: MINIMAL pragma and default implementations In-Reply-To: <049.85d8787946f3bf6572d68ae7b06b8e4f@haskell.org> References: <049.85d8787946f3bf6572d68ae7b06b8e4f@haskell.org> Message-ID: <064.56d1db3f7bb20f6c0bffc76222070f6b@haskell.org> #10959: MINIMAL pragma and default implementations -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | 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: | -------------------------------------+------------------------------------- Comment (by rwbarton): {{{ {-# LANGUAGE DefaultSignatures #-} module Min where class C a where meth :: a -> a {-# MINIMAL meth #-} default meth :: Enum a => a -> a meth = succ instance C Int {- Min.hs:11:10: Warning: No explicit implementation for ?meth? In the instance declaration for ?C Int? -} }}} It's true there is no ''explicit'' implementation, but surely the intention of the MINIMAL pragma was to warn if we end up with the `meth = error "..."` implementation that the compiler would supply if there was no other implementation at all. If we end up using the default implementation `meth = succ` then it should count towards satisfying the MINIMAL pragma. Incidentally, as I just discovered in testing, the MINIMAL pragma is totally useless in this case: if you don't include an implementation for `meth` in an instance for `C`, ghc will try to use the default implementation, and if it doesn't type check (if there is no instance of `Enum`), that's an error; it doesn't fall back on the `meth = error "..."` implementation for a missing method. So there is no way you can ever not have an implementation for `meth`. (That's not how I thought it worked; I thought the default implementation would just be ignored if it doesn't type check. But it is consistent with the documentation. `default meth :: Enum a => a -> a` is a type signature on ''the'' default implementation, not a description of when to provide ''a'' default implementation.) So I guess an even more minimal example would be {{{ module Min where class C a where meth :: a -> a meth = id {-# MINIMAL meth #-} instance C Int {- Min.hs:7:10: Warning: No explicit implementation for ?meth? In the instance declaration for ?C Int? -} }}} and now I've convinced myself that there is no bug here at all, just wrong use of MINIMAL. A correct use in conjunction with DefaultSignatures would be if you had two methods in a class, each with a default implementation (using DefaultSignatures) in terms of the other. Then the default implementations should not count for satisfying MINIMAL! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 13:22:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 13:22:30 -0000 Subject: [GHC] #10959: MINIMAL pragma and default implementations In-Reply-To: <049.85d8787946f3bf6572d68ae7b06b8e4f@haskell.org> References: <049.85d8787946f3bf6572d68ae7b06b8e4f@haskell.org> Message-ID: <064.4c83024ad37ba4a2a169ce6365760df2@haskell.org> #10959: MINIMAL pragma and default implementations -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): > surely the intention of the MINIMAL pragma was to warn if we end up with the meth = error "..." implementation that the compiler would supply if there was no other implementation at all Not only that. Bur also {{{ class Eq a where (==), (/=) :: a -> a -> Bool (==) a b = not (a /= b) (/=) a b = not (a == b) }}} Here we have code for both `(==)` and `(/=)` (no `error` here), but the MINIMAL pragma allows you to say that you should supply a "real" implementation for one or the other. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 14:10:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 14:10:09 -0000 Subject: [GHC] #10958: "Annotating pure code for parallelism" docs based on old par/pseq primitives In-Reply-To: <051.c6c45266fc5f87d1eb4c881e200bec98@haskell.org> References: <051.c6c45266fc5f87d1eb4c881e200bec98@haskell.org> Message-ID: <066.71643ea2858cf646d0830ce769d9d578@haskell.org> #10958: "Annotating pure code for parallelism" docs based on old par/pseq primitives -------------------------------------+------------------------------------- Reporter: robstewartuk | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Resolution: | Keywords: parallelim Operating System: 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): Sure, I think it would be great to update the docs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 14:36:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 14:36:13 -0000 Subject: [GHC] #10959: MINIMAL pragma and default implementations In-Reply-To: <049.85d8787946f3bf6572d68ae7b06b8e4f@haskell.org> References: <049.85d8787946f3bf6572d68ae7b06b8e4f@haskell.org> Message-ID: <064.b4efbd0b2ba3c37e095126c3e5fe20c4@haskell.org> #10959: MINIMAL pragma and default implementations -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: | -------------------------------------+------------------------------------- Changes (by basvandijk): * status: new => closed * resolution: => invalid Comment: Thanks, I now understand MINIMAL better. Sorry for the noise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 14:40:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 14:40:11 -0000 Subject: [GHC] #10959: MINIMAL pragma and default implementations In-Reply-To: <049.85d8787946f3bf6572d68ae7b06b8e4f@haskell.org> References: <049.85d8787946f3bf6572d68ae7b06b8e4f@haskell.org> Message-ID: <064.ddda0a62c6a6184e79eea8bf6317640f@haskell.org> #10959: MINIMAL pragma and default implementations -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: | -------------------------------------+------------------------------------- Comment (by simonpj): Great. Could you suggest some improvements to the wording in the user manual that would make it easier to understand what it does? Maybe less ambiguous? Better text would be v helpful. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 16:06:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 16:06:02 -0000 Subject: [GHC] #10931: layers-0.1 does not compile with ghc-7.10 (likely a regression from ghc-7.8) In-Reply-To: <045.19b8056b1d70bf96a656ae7348a956cb@haskell.org> References: <045.19b8056b1d70bf96a656ae7348a956cb@haskell.org> Message-ID: <060.c9a9d1788cc3e7294a6bc2d08084a072@haskell.org> #10931: layers-0.1 does not compile with ghc-7.10 (likely a regression from ghc-7.8) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"6b7bad92c52d9cb0d17f75af1059315ddef0646e/ghc" 6b7bad9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6b7bad92c52d9cb0d17f75af1059315ddef0646e" Test Trac #10931 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 16:06:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 16:06:02 -0000 Subject: [GHC] #10935: More unused and non-deprecated warning flags In-Reply-To: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> References: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> Message-ID: <058.2b8939dd10bae580bd08a8e53e311656@haskell.org> #10935: More unused and non-deprecated warning flags -------------------------------------+------------------------------------- Reporter: osa1 | Owner: bernalex Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10752, #8176 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f8fbf385b879fe177409a25cc9499275ea3dc45d/ghc" f8fbf385/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f8fbf385b879fe177409a25cc9499275ea3dc45d" Reinstate monomorphism-restriction warnings This patch is driven by Trac #10935, and reinstates the -fwarn-monomorphism-restriction warning. It was first lost in 2010: d2ce0f52d "Super-monster patch implementing the new typechecker -- at last" I think the existing documentation is accurate; it is not even turned on by -Wall. I added one test. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 16:07:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 16:07:05 -0000 Subject: [GHC] #10935: More unused and non-deprecated warning flags In-Reply-To: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> References: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> Message-ID: <058.df9092ffe5af9ab82a1bef7a95ff0c63@haskell.org> #10935: More unused and non-deprecated warning flags -------------------------------------+------------------------------------- Reporter: osa1 | Owner: bernalex Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10752, #8176 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: igloo (added) Comment: I took a spare moment to deal with `-fwarn-monomorphism-restriction`. I don't know about alternative layout, so leaving this open. But cc'ing Ian (igloo). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 16:07:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 16:07:24 -0000 Subject: [GHC] #10935: More unused and non-deprecated warning flags In-Reply-To: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> References: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> Message-ID: <058.f28e3752a95f622497f93cdbaf9a43a3@haskell.org> #10935: More unused and non-deprecated warning flags -------------------------------------+------------------------------------- Reporter: osa1 | Owner: bernalex Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10935 Blocked By: | Blocking: Related Tickets: #10752, #8176 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_compile/T10935 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 16:37:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 16:37:32 -0000 Subject: [GHC] #10908: -fwarn-missing-exported-sigs doesn't respect qualified names In-Reply-To: <047.8049acc3e53dbcc2c0ac7fc46b25d3cc@haskell.org> References: <047.8049acc3e53dbcc2c0ac7fc46b25d3cc@haskell.org> Message-ID: <062.c681c1f2c7d75dfecd95911ca120d98d@haskell.org> #10908: -fwarn-missing-exported-sigs doesn't respect qualified names -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > Trying to help @mpickering with Phab:D1258, I looked at the code in > `tcRnSrcDecls` and was surprised to see that exports are renamed after > this function is complete. This didn't make any sense to me. And, indeed, > it's wrong, witness by this example: > > {{{ > {-# OPTIONS_GHC -fwarn-missing-exported-sigs #-} > > module Bug (Data.List.intercalate, x) where > > import qualified Data.List > > intercalate = True > > x :: Bool > x = intercalate > }}} > > This produces > > {{{ > Bug.hs:7:1: Warning: > Top-level binding with no type signature: intercalate :: Bool > }}} > > This warning should not be emitted. > > I'm not all that concerned about this scenario biting in the wild, but it > suggests that refactoring this code is a good thing, and not something > Phab:D1258 should take pains to avoid. New description: Trying to help @mpickering with Phab:D1258, I looked at the code in `tcRnSrcDecls` and was surprised to see that exports are renamed after this function is complete. This didn't make any sense to me. And, indeed, it's wrong, witness by this example: {{{ {-# OPTIONS_GHC -fwarn-missing-exported-sigs #-} module Bug (Data.List.intercalate, x) where import qualified Data.List intercalate = True x :: Bool x = intercalate }}} This produces {{{ Bug.hs:7:1: Warning: Top-level binding with no type signature: intercalate :: Bool }}} This warning should not be emitted, because `Bug.intercalate` is not exported. I'm not all that concerned about this scenario biting in the wild, but it suggests that refactoring this code is a good thing, and not something Phab:D1258 should take pains to avoid. -- Comment (by simonpj): Quite right. I think the right thing is to remove all the `sig_warn` stuff from `TcHsSyn` (zonking; it doesn't belong there) and put it in `reportUnusedNames` (perhaps with a better function name). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 17:43:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 17:43:08 -0000 Subject: [GHC] #10955: GHC on windows does not resolve DLL dependencies In-Reply-To: <044.d1371f1a3dafc9d7220a00358a56f239@haskell.org> References: <044.d1371f1a3dafc9d7220a00358a56f239@haskell.org> Message-ID: <059.208efe7006c76bf62f04b7aee4dc15d2@haskell.org> #10955: GHC on windows does not resolve DLL dependencies -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 (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 thoughtpolice): I proposed quite a while back to actually drop XP support: https://mail.haskell.org/pipermail/ghc-devs/2014-November/007199.html Personally, I say we go for it. Of course, some people might not like this, but I think dropping XP for 8.0 is pretty reasonable. Even Windows Server 2k3 is EOL now, and we won't be releasing for a few months still. And it's not like 7.10 or whatever will stop existing. At the very least, if you can cook up a patch and people rally against it, we can apply it to HEAD and just say 8.2 will definitively remove it and that's that. But I imagine it would be fine for 8.0 as well. In short, you have my permission to use the launch codes, and nuke it from orbit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 18:21:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 18:21:01 -0000 Subject: [GHC] #10957: getExecutablePath adds " (deleted)" suffix if executable was deleted under linux In-Reply-To: <047.9c6f417035b8e10ce588ba217f863194@haskell.org> References: <047.9c6f417035b8e10ce588ba217f863194@haskell.org> Message-ID: <062.0dc51b7894ef86815b123a1bae92931c@haskell.org> #10957: getExecutablePath adds " (deleted)" suffix if executable was deleted under linux -------------------------------------+------------------------------------- Reporter: aslpavel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aslpavel): API break is not very good choice, otherwise I would suggest return some optional type, so we can add an explicit hack to handle this Linux quirk by either returning trimmed string or throwing an exceptin -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 18:53:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 18:53:00 -0000 Subject: [GHC] #10960: Closed type families don't reduce on data family instances Message-ID: <046.bd0b902b8438f4afa2a10f7aa62fe839@haskell.org> #10960: Closed type families don't reduce on data family instances -------------------------------------+------------------------------------- Reporter: exFalso | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: closed type | Operating System: Linux family data | Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code doesn't compile: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Tmp where data family D a data instance D () = D type family T a where T () = () T a = Char try :: T (D ()) ~ Char => () try = () main :: IO () main = return try }}} giving {{{ Tmp.hs:15:15: Couldn't match expected type ?Char? with actual type ?T (D ())? In the first argument of ?return?, namely ?try? In the expression: return try In an equation for ?main?: main = return try }}} Is this a known limitation of closed type families? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 19:15:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 19:15:10 -0000 Subject: [GHC] #10961: Make it possible to purely use the parser Message-ID: <049.fcc8c76168c1ad7ed5e00c80467dcc18@haskell.org> #10961: Make it possible to purely use the parser -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | 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: -------------------------------------+------------------------------------- It is claimed that the parser is pure but one of the arguments is `DynFlags`. The only safe way to construct a copy of `DynFlags` requires IO so it is not possible to use the parser purely. I propose to introduce a new datatype `ParserOptions` which contains the options used by the parser and a function `DynFlags -> ParserOptions` so that it is possible to purely construct a `ParserOptions` and use the parser purely. This would be useful for external users of the parser. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 20:32:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 20:32:07 -0000 Subject: [GHC] #10960: Closed type families don't reduce on data family instances In-Reply-To: <046.bd0b902b8438f4afa2a10f7aa62fe839@haskell.org> References: <046.bd0b902b8438f4afa2a10f7aa62fe839@haskell.org> Message-ID: <061.b19ccb87f0b70c67b81e388a667638bc@haskell.org> #10960: Closed type families don't reduce on data family instances -------------------------------------+------------------------------------- Reporter: exFalso | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: duplicate | Keywords: closed type | family data 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 goldfire): * status: new => closed * resolution: => duplicate Comment: It's a bug. Fixed in HEAD and the fix will be in 7.10.3. See #10713. Thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 21:04:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 21:04:17 -0000 Subject: [GHC] #10962: Improved arithmetic primops Message-ID: <050.9a384d25dddf3580aebe73d3e27aa54b@haskell.org> #10962: Improved arithmetic primops -------------------------------------+------------------------------------- Reporter: nkaretnikov | Owner: nkaretnikov Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/ImprovedArithmeticPrimops -------------------------------------+------------------------------------- See the todo list on the wiki page. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 21:06:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 21:06:50 -0000 Subject: [GHC] #10962: Improved arithmetic primops In-Reply-To: <050.9a384d25dddf3580aebe73d3e27aa54b@haskell.org> References: <050.9a384d25dddf3580aebe73d3e27aa54b@haskell.org> Message-ID: <065.b3e30de52a5dd34f3d9f901e05ad498b@haskell.org> #10962: Improved arithmetic primops -------------------------------------+------------------------------------- Reporter: nkaretnikov | Owner: nkaretnikov Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | wiki:ImprovedArithmeticPrimops | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * wikipage: https://ghc.haskell.org/trac/ghc/wiki/ImprovedArithmeticPrimops => wiki:ImprovedArithmeticPrimops * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 21:24:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 21:24:10 -0000 Subject: [GHC] #10962: Improved arithmetic primops In-Reply-To: <050.9a384d25dddf3580aebe73d3e27aa54b@haskell.org> References: <050.9a384d25dddf3580aebe73d3e27aa54b@haskell.org> Message-ID: <065.24d2ff625b9d8f6ae780d82535408b65@haskell.org> #10962: Improved arithmetic primops -------------------------------------+------------------------------------- Reporter: nkaretnikov | Owner: nkaretnikov Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | wiki:ImprovedArithmeticPrimops | -------------------------------------+------------------------------------- Description changed by nkaretnikov: Old description: > See the todo list on the wiki page. New description: There are a few primops that report arithmetic overflow, which work on `Int`s and a couple or so for `Word`s. But that's not enough! Let's add more and clean up the existing code (e.g., make overflow-reporting helpers proper primops) on the go. See the wiki page for the proposal. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 21:25:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 21:25:05 -0000 Subject: [GHC] #10962: Improved arithmetic primops In-Reply-To: <050.9a384d25dddf3580aebe73d3e27aa54b@haskell.org> References: <050.9a384d25dddf3580aebe73d3e27aa54b@haskell.org> Message-ID: <065.1fd9223862876777dad5da89a4cf3c5c@haskell.org> #10962: Improved arithmetic primops -------------------------------------+------------------------------------- Reporter: nkaretnikov | Owner: nkaretnikov Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | wiki:ImprovedArithmeticPrimops | -------------------------------------+------------------------------------- Old description: > There are a few primops that report arithmetic overflow, which work on > `Int`s and a couple or so for `Word`s. But that's not enough! Let's add > more and clean up the existing code (e.g., make overflow-reporting > helpers proper primops) on the go. See the wiki page for the proposal. New description: See the todo list on the wiki page. -- Comment (by tibbe): Could you clarify (on the wiki) what assembly you get if you just implement this in Haskell (on top of the "unsafe" primops) and what assembly you'd like to see. Elsewhere (e.g. with the shift primops) we have been able to implement "safe" primops on top of the unsafe ones. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 12 21:40:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Oct 2015 21:40:39 -0000 Subject: [GHC] #10962: Improved arithmetic primops In-Reply-To: <050.9a384d25dddf3580aebe73d3e27aa54b@haskell.org> References: <050.9a384d25dddf3580aebe73d3e27aa54b@haskell.org> Message-ID: <065.23a0e671e20c97000a15376e777fc985@haskell.org> #10962: Improved arithmetic primops -------------------------------------+------------------------------------- Reporter: nkaretnikov | Owner: nkaretnikov Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | wiki:ImprovedArithmeticPrimops | -------------------------------------+------------------------------------- Description changed by thoughtpolice: Old description: > See the todo list on the wiki page. New description: There are a few primops that report arithmetic overflow, which work on `Int`s and a couple or so for `Word`s. But that's not enough! Let's add more and clean up the existing code (e.g., make overflow-reporting helpers proper primops) on the go. See the wiki page for the proposal. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 02:27:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 02:27:19 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.62b449bcda9fccef1f4b6cff7f863d58@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10528 | Differential Rev(s): Phab:D1246 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"dcc342870b4d8a739ccbed3ae26e84dcc3579914/ghc" dcc3428/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dcc342870b4d8a739ccbed3ae26e84dcc3579914" Don't inline/apply other rules when simplifying a rule RHS. HERMIT users depend on RULES to specify equational properties. 7.10.2 performed both inlining and simplification in both sides of the rules, meaning they can't really be used for this. This breaks most HERMIT use cases. A separate commit already disabled this for the LHS of rules. This does so for the RHS. See Trac #10829 for nofib results. Reviewed By: austin, bgamari, simonpj Differential Revision: https://phabricator.haskell.org/D1246 GHC Trac Issues: #10829 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 02:27:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 02:27:50 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.6418a2ee5e0c8383d7a96f3cd6335824@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10528 | Differential Rev(s): Phab:D1246 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 02:34:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 02:34:23 -0000 Subject: [GHC] #10935: More unused and non-deprecated warning flags In-Reply-To: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> References: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> Message-ID: <058.1112e1559a22d10c6f1369ebabbbf3f5@haskell.org> #10935: More unused and non-deprecated warning flags -------------------------------------+------------------------------------- Reporter: osa1 | Owner: bernalex Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10935 Blocked By: | Blocking: Related Tickets: #10752, #8176 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"330ba6ad361b696492676345da132b8f98b26370/ghc" 330ba6ad/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="330ba6ad361b696492676345da132b8f98b26370" testsuite: attempt fixing T10935 output This fallout was caused by f8fbf385b879fe17740 (see #10935), and looks easy enough, but admittedly I just tried patching the output, so we're doing it live. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 03:58:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 03:58:36 -0000 Subject: [GHC] #10963: Beginner-targeted language extension Message-ID: <045.cc74d15b01a49696436fbbb3b560b576@haskell.org> #10963: Beginner-targeted language extension -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- FMP significantly complicated type signatures such as `length :: Foldable t => t a -> Int`, which makes teaching Haskell more difficult. I propose a language extension `-XBeginner` which instructs GHC(i) to specialize `Foldable` and `Traversable` to `[]` when possible and in case of an ambiguous instance, default those to `[]`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 05:46:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 05:46:44 -0000 Subject: [GHC] #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression In-Reply-To: <045.67153471687796395f900337ba5220e7@haskell.org> References: <045.67153471687796395f900337ba5220e7@haskell.org> Message-ID: <060.648c5f83b89838358be37ac81c3ad7b9@haskell.org> #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression -------------------------------------+------------------------------------- Reporter: erisco | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.8.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:D1313 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"d2f9972a35ce05ceb8a78893e433ef1df06f73ef/ghc" d2f9972/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d2f9972a35ce05ceb8a78893e433ef1df06f73ef" Make dataToQa aware of Data instances which use functions to implement toConstr Trac #10796 exposes a way to make `template-haskell`'s `dataToQa` function freak out if using a `Data` instance that produces a `Constr` (by means of `toConstr`) using a function name instead of a data constructor name. While such `Data` instances are somewhat questionable, they are nevertheless present in popular libraries (e.g., `containers`), so we can at least make `dataToQa` aware of their existence. In order to properly distinguish strings which represent variables (as opposed to data constructors), it was necessary to move functionality from `Lexeme` (in `ghc`) to `GHC.Lexeme` in a new `ghc-boot` library (which was previously named `bin-package-db`). Reviewed By: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D1313 GHC Trac Issues: #10796 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 05:46:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 05:46:44 -0000 Subject: [GHC] #10890: Incorrect redundant import warning for type classes In-Reply-To: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> References: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> Message-ID: <060.3009bf9798ab9cd60d3e0d85e31df25f@haskell.org> #10890: Incorrect redundant import warning for type classes -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1257 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"1818b48e420fd0f689105da76721895aadee7fd6/ghc" 1818b48/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1818b48e420fd0f689105da76721895aadee7fd6" Fix incorrect import warnings when methods with identical names are imported Currently, GHC's warning generation code is assuming that a name (`RdrName`) can be imported at most once. This is a correct assumption, because 1) it's OK to import same names as long as we don't use any of them 2) when we use one of them, GHC generates an error because it doesn't disambiguate it automatically. But apparently the story is different with typeclass methods. If I import two methods with same names, it's OK to use them in typeclass instance declarations, because the context specifies which one to use. For example, this is OK (where modules A and B define typeclasses A and B, both with a function has), import A import B data Blah = Blah instance A Blah where has = Blah instance B Blah where has = Blah But GHC's warning generator is not taking this into account, and so if I change import list of this program to: import A (A (has)) import B (B (has)) GHC is printing these warnings: Main.hs:5:1: Warning: The import of ?A.has? from module ?A? is redundant Main.hs:6:1: Warning: The import of ?B.has? from module ?B? is redundant Why? Because warning generation code is _silently_ ignoring multiple symbols with same names. With this patch, GHC takes this into account. If there's only one name, then this patch reduces to the previous version, that is, it works exactly the same as current GHC (thanks goes to @quchen for realizing this). Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1257 GHC Trac Issues: #10890 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 05:56:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 05:56:34 -0000 Subject: [GHC] #10831: Document conditions on deriving Functor In-Reply-To: <048.8298ed09a98386a50539acd12ba36fa5@haskell.org> References: <048.8298ed09a98386a50539acd12ba36fa5@haskell.org> Message-ID: <063.69f96fb131c32a5786e7e2f2d6e5ccbe@haskell.org> #10831: Document conditions on deriving Functor -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: RyanGlScott Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1293 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"e5bfd704a6391e74f3797d78d19c4e4877f512da/ghc" e5bfd70/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e5bfd704a6391e74f3797d78d19c4e4877f512da" docs: overhaul Derive{Functor,Foldable,Traversable} notes The previous users' guide documentation was too implementation-oriented. This attempts to make it more accessible to those who aren't familiar with how `-XDeriveFunctor` and friends work (and more importantly, what will not work when using them). Fixes #10831. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1293 GHC Trac Issues: #10831 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 05:57:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 05:57:12 -0000 Subject: [GHC] #10831: Document conditions on deriving Functor In-Reply-To: <048.8298ed09a98386a50539acd12ba36fa5@haskell.org> References: <048.8298ed09a98386a50539acd12ba36fa5@haskell.org> Message-ID: <063.e048507712c33d44bb14b868657f7a66@haskell.org> #10831: Document conditions on deriving Functor -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: RyanGlScott Type: bug | Status: merge Priority: low | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1293 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => merge * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 05:57:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 05:57:40 -0000 Subject: [GHC] #10831: Document conditions on deriving Functor In-Reply-To: <048.8298ed09a98386a50539acd12ba36fa5@haskell.org> References: <048.8298ed09a98386a50539acd12ba36fa5@haskell.org> Message-ID: <063.fdc61af657f44f35a394f463a80577ee@haskell.org> #10831: Document conditions on deriving Functor -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: RyanGlScott Type: bug | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | 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): Phab:D1293 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Whoops. Thanks for the fix Ryan - closing this, not setting it to merge. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 05:59:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 05:59:02 -0000 Subject: [GHC] #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression In-Reply-To: <045.67153471687796395f900337ba5220e7@haskell.org> References: <045.67153471687796395f900337ba5220e7@haskell.org> Message-ID: <060.697dbcc36cb812f10cdbf586c874f6c4@haskell.org> #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression -------------------------------------+------------------------------------- Reporter: erisco | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.8.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:D1313 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Thanks Ryan - I think this should be handled now, so closing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 05:59:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 05:59:34 -0000 Subject: [GHC] #10890: Incorrect redundant import warning for type classes In-Reply-To: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> References: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> Message-ID: <060.9fccec29b3e3846060ac54cd0272d9b8@haskell.org> #10890: Incorrect redundant import warning for type classes -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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:D1257 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Thanks ?mer! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 06:09:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 06:09:51 -0000 Subject: [GHC] #8010: Add forkOSUnmasked (patch) In-Reply-To: <048.eb7119d903e5adba0673b07e7cf0b9ea@haskell.org> References: <048.eb7119d903e5adba0673b07e7cf0b9ea@haskell.org> Message-ID: <063.8dd6ae7a86a4e53142dd6aea68a53e08@haskell.org> #8010: Add forkOSUnmasked (patch) -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"dec5cd4085488686b5ed50bb26ccbc0ba7b645ec/ghc" dec5cd4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dec5cd4085488686b5ed50bb26ccbc0ba7b645ec" base: Add forkOSWithUnmask Fixes #8010, according to the specified libraries proposal. [1] Also, some minor wordsmithing. [1] http://thread.gmane.org/gmane.comp.lang.haskell.libraries/22709 Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 06:10:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 06:10:15 -0000 Subject: [GHC] #8010: Add forkOSUnmasked (patch) In-Reply-To: <048.eb7119d903e5adba0673b07e7cf0b9ea@haskell.org> References: <048.eb7119d903e5adba0673b07e7cf0b9ea@haskell.org> Message-ID: <063.4fedb51143a03edac43e9d6b8bd549fa@haskell.org> #8010: Add forkOSUnmasked (patch) -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.7 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 thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks Joey, and sorry this took a ridiculously long time... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 09:25:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 09:25:59 -0000 Subject: [GHC] #10870: PPC.Ppr: Shift by 32 bits is not allowed. In-Reply-To: <046.266af0561f46fb382b81907ac208339a@haskell.org> References: <046.266af0561f46fb382b81907ac208339a@haskell.org> Message-ID: <061.7da58dc9f81074602c4c23fc18e66666@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1322 Wiki Page: | ---------------------------------------+---------------------------------- Changes (by erikd): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 10:02:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 10:02:46 -0000 Subject: [GHC] #10960: Closed type families don't reduce on data family instances In-Reply-To: <046.bd0b902b8438f4afa2a10f7aa62fe839@haskell.org> References: <046.bd0b902b8438f4afa2a10f7aa62fe839@haskell.org> Message-ID: <061.f3204536a2b0df6a3740b1675306a8e7@haskell.org> #10960: Closed type families don't reduce on data family instances -------------------------------------+------------------------------------- Reporter: exFalso | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: duplicate | Keywords: closed type | family data 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: | -------------------------------------+------------------------------------- Comment (by exFalso): A note to anyone encountering this same problem: There is a weird workaround, at least for the above problem: {{{#!hs type family T a where T () = () T (f a) = Char -- (D ()) reduces here T a = Char }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 10:47:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 10:47:02 -0000 Subject: [GHC] #10935: More unused and non-deprecated warning flags In-Reply-To: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> References: <043.3dcba055ec843ec6893b1fd8bf5869e6@haskell.org> Message-ID: <058.d871af5c8568deca83a6ec7406328c93@haskell.org> #10935: More unused and non-deprecated warning flags -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10935 Blocked By: | Blocking: Related Tickets: #10752, #8176 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bernalex): * owner: bernalex => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 12:00:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 12:00:30 -0000 Subject: [GHC] #10963: Beginner-targeted language extension In-Reply-To: <045.cc74d15b01a49696436fbbb3b560b576@haskell.org> References: <045.cc74d15b01a49696436fbbb3b560b576@haskell.org> Message-ID: <060.d2944c5757f1aedc04dcf2d82cddd3e9@haskell.org> #10963: Beginner-targeted language extension -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I very much like your general idea here, but I have different suggestions as to the particulars. Here is my counter-proposal: * Extend `-XExtendedDefaultRules` to allow defaulting when one of the classes involved is `Foldable` or `Traversable`. (See the current rules [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide /interactive-evaluation.html#extended-default-rules here].) This will mean, essentially, that there will be two lists of default types, one list at kind `*` and one at kind `* -> *`. Both lists should be settable by the user by the `default` directive. (GHC can figure out which list is being set quite easily.) The default `default` list for `* -> *` will be `[]`. * Add a new command to GHCi, `:binfo` (for "beginner info") (please suggest a better name) that is like `:info` but presents different information. It suppresses in-scope instances, but attempts to specialize a function's type and presents specializations, using heuristics. So when we say `:binfo find`, we'll see `Foldable t => (a -> Bool) -> t a -> Maybe a` but also `(a -> Bool) -> [a] -> Maybe a`. Would this address your use-case? One advantage to my counter-proposal is it means that you don't actually need students to specify a language extension, because `-XExtendedDefaultRules` is on by default in GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 12:01:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 12:01:11 -0000 Subject: [GHC] #10964: User's Guide build error on Debian Wheezy Message-ID: <048.8967d262318647c29b8ad8ebceab90fa@haskell.org> #10964: User's Guide build error on Debian Wheezy -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.11 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: -------------------------------------+------------------------------------- User's Guide fails to build on Debian Wheezy - see attached log. I'm doing a devel2 build in a separate symlinked build tree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 12:01:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 12:01:28 -0000 Subject: [GHC] #10964: User's Guide build error on Debian Wheezy In-Reply-To: <048.8967d262318647c29b8ad8ebceab90fa@haskell.org> References: <048.8967d262318647c29b8ad8ebceab90fa@haskell.org> Message-ID: <063.1bfa9eb02e72b6cacc62fc95598ec79f@haskell.org> #10964: User's Guide build error on Debian Wheezy -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.11 Resolution: | Keywords: 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 jstolarek): * Attachment "user_guide_build_error.log" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 12:21:42 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 12:21:42 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDIxNjogQWxsb3cgYXJyIOKIpyAoZmlyc3Qg?= =?utf-8?q?=E2=88=A8_=28***=29=29_as_minimal_definition_of_Arrow_?= =?utf-8?q?instance?= In-Reply-To: <048.64b271a00a46843da0df000240882f80@haskell.org> References: <048.64b271a00a46843da0df000240882f80@haskell.org> Message-ID: <063.6d8a954ec50aeeab10ce3f849de2b34c@haskell.org> #10216: Allow arr ? (first ? (***)) as minimal definition of Arrow instance -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.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): -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"e8c8173923302268ef950c3b21e276779e45ac83/ghc" e8c81739/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e8c8173923302268ef950c3b21e276779e45ac83" Allow arr ? (first ? (***)) as minimal definition of Arrow instance See #10216. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 12:22:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 12:22:36 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDIxNjogQWxsb3cgYXJyIOKIpyAoZmlyc3Qg?= =?utf-8?q?=E2=88=A8_=28***=29=29_as_minimal_definition_of_Arrow_?= =?utf-8?q?instance?= In-Reply-To: <048.64b271a00a46843da0df000240882f80@haskell.org> References: <048.64b271a00a46843da0df000240882f80@haskell.org> Message-ID: <063.5e3212ba4dfe5f98db75887660037581@haskell.org> #10216: Allow arr ? (first ? (***)) as minimal definition of Arrow instance -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.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 thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Thanks, merged! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 13:53:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 13:53:50 -0000 Subject: [GHC] #10965: GHC Panic on import with 'OPTIONS_GHC -fobject-code -O' Message-ID: <044.d2359d5edaaed9fe3a9870eb9b625099@haskell.org> #10965: GHC Panic on import with 'OPTIONS_GHC -fobject-code -O' --------------------------------------+--------------------------------- Reporter: Orome | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- I get {{{ > :l Test.hs [1 of 1] Compiling Main ( Test.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-apple-darwin): floatExpr tick break<11>() Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} with Test.hs: {{{ {-# OPTIONS_GHC -fobject-code -O #-} import Control.Exception (assert) import Data.Char (ord) f :: String -> String f s = assert (all (`elem` letters) s) $ (letters!!) <$> (ix <$> s) where ix ch = (ord ch - ord 'A') letters = ['A'..'Z'] }}} OSX 10.11, GHC 7.10.2; uad-core 64-bit haswell; Homebrew GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 14:26:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 14:26:45 -0000 Subject: [GHC] #10963: Beginner-targeted language extension In-Reply-To: <045.cc74d15b01a49696436fbbb3b560b576@haskell.org> References: <045.cc74d15b01a49696436fbbb3b560b576@haskell.org> Message-ID: <060.452617e731054fd27e97679a1a7ae654@haskell.org> #10963: Beginner-targeted language extension -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kanetw): Yes, that seems like a good idea. That might still leave confusing errors when writing code outside of GHCi, but I think that by the time students are advanced enough to use modules/write `main` themselves they won't be as scared of type class errors anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 14:59:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 14:59:35 -0000 Subject: [GHC] #10964: User's Guide build error on Debian Wheezy In-Reply-To: <048.8967d262318647c29b8ad8ebceab90fa@haskell.org> References: <048.8967d262318647c29b8ad8ebceab90fa@haskell.org> Message-ID: <063.d8da15c0cae01152c278ed8e2c756fab@haskell.org> #10964: User's Guide build error on Debian Wheezy -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.11 Resolution: | Keywords: 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 thomie): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 17:25:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 17:25:54 -0000 Subject: [GHC] #10966: dirtiness checking isn't keeping track of which source file contained Main Message-ID: <044.5fcdeb9071ae79d9f9b6bcbc72d714db@haskell.org> #10966: dirtiness checking isn't keeping track of which source file contained Main -------------------------------------+------------------------------------- Reporter: gueux | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See https://github.com/commercialhaskell/stack/issues/1127#issuecomment-146781161 for the description of the issue and https://gist.github.com/snoyberg/aa6ce5247f9a0d1b5f95 for a minimal example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 20:09:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 20:09:28 -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.8b48b70c6bb62f2eef5642a98a231c65@haskell.org> #10965: GHC Panic on import with 'OPTIONS_GHC -fobject-code -O' ---------------------------------+-------------------------------------- Reporter: Orome | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: duplicate | 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 bgamari): * status: new => closed * resolution: => duplicate * related: => #10549 Comment: Thanks for your report. This is a duplicate of #10549 which will be fixed in 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 22:18:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 22:18:03 -0000 Subject: [GHC] #10953: Switch to LLVM 3.7 In-Reply-To: <044.001611d6f47af3fe74e4a46f1d21d31f@haskell.org> References: <044.001611d6f47af3fe74e4a46f1d21d31f@haskell.org> Message-ID: <059.dce5529bfc2a1889fd913353b38fc439@haskell.org> #10953: Switch to LLVM 3.7 -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.11 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:D1320 -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"29310b622801733e1b29a9a61988406872db13ca/ghc" 29310b62/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="29310b622801733e1b29a9a61988406872db13ca" Switch to LLVM version 3.7 Before this commit, GHC only supported LLVM 3.6. Now it only supports LLVM 3.7 which was released in August 2015. LLVM version 3.6 and earlier do not work on AArch64/Arm64, but 3.7 does. Also: * Add CC_Ghc constructor to LlvmCallConvention. * Replace `maxSupportLlvmVersion`/`minSupportLlvmVersion` with a single `supportedLlvmVersion` variable. * Get `supportedLlvmVersion` from version specified in configure.ac. * Drop llvmVersion field from DynFlags (no longer needed because only one version is supported). Test Plan: Validate on x86_64 and arm Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1320 GHC Trac Issues: #10953 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 22:23:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 22:23:13 -0000 Subject: [GHC] #10953: Switch to LLVM 3.7 In-Reply-To: <044.001611d6f47af3fe74e4a46f1d21d31f@haskell.org> References: <044.001611d6f47af3fe74e4a46f1d21d31f@haskell.org> Message-ID: <059.265c89d02c23e27dfa84213294cf7701@haskell.org> #10953: Switch to LLVM 3.7 -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.11 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:D1320 Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 13 22:23:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Oct 2015 22:23:27 -0000 Subject: [GHC] #10953: Switch to LLVM 3.7 In-Reply-To: <044.001611d6f47af3fe74e4a46f1d21d31f@haskell.org> References: <044.001611d6f47af3fe74e4a46f1d21d31f@haskell.org> Message-ID: <059.8d8bbcad780492ee989706ce1764d5e0@haskell.org> #10953: Switch to LLVM 3.7 -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.11 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:D1320 Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 02:32:29 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 02:32:29 -0000 Subject: [GHC] #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ In-Reply-To: <048.86721c518b657437564df331356981ea@haskell.org> References: <048.86721c518b657437564df331356981ea@haskell.org> Message-ID: <063.b38c4b231ccaefcde2216d9e02215303@haskell.org> #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by strake888): * Attachment "0001-generalize-filterM-mapAndUnzipM-zipWithM- zipWithM_-r.patch" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 02:32:29 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 02:32:29 -0000 Subject: [GHC] #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ In-Reply-To: <048.86721c518b657437564df331356981ea@haskell.org> References: <048.86721c518b657437564df331356981ea@haskell.org> Message-ID: <063.5fdf6fa66e0c251fe454de8cf13be7d4@haskell.org> #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by strake888): * Attachment "0001-generalize-filterM-mapAndUnzipM-zipWithM- zipWithM_-r.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 02:36:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 02:36:31 -0000 Subject: [GHC] #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ In-Reply-To: <048.86721c518b657437564df331356981ea@haskell.org> References: <048.86721c518b657437564df331356981ea@haskell.org> Message-ID: <063.dc332b7d1b765a5ac4e0ba3942f01add@haskell.org> #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): 1324 Wiki Page: | -------------------------------------+------------------------------------- Changes (by strake888): * status: infoneeded => patch * differential: => 1324 Comment: Replying to [comment:10 bgamari]: Yes, done -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 05:43:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 05:43:18 -0000 Subject: [GHC] #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ In-Reply-To: <048.86721c518b657437564df331356981ea@haskell.org> References: <048.86721c518b657437564df331356981ea@haskell.org> Message-ID: <063.0f4a7528d5fa2385b81153f77bf7ca99@haskell.org> #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:1324 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * differential: 1324 => Phab:1324 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 05:43:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 05:43:55 -0000 Subject: [GHC] #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ In-Reply-To: <048.86721c518b657437564df331356981ea@haskell.org> References: <048.86721c518b657437564df331356981ea@haskell.org> Message-ID: <063.5baee760113f4032796473bbecaa9fbb@haskell.org> #10168: generalize filterM, mapAndUnzipM, zipWithM, zipWithM_, replicateM, replicateM_ -------------------------------------+------------------------------------- Reporter: strake888 | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1324 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * differential: 1324 => Phab:D1324 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 06:19:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 06:19:41 -0000 Subject: [GHC] #10089: feature: warn about unused data definitions (with typeclass instances) In-Reply-To: <045.113d906ba3b76ec22ad2f715d9c6da96@haskell.org> References: <045.113d906ba3b76ec22ad2f715d9c6da96@haskell.org> Message-ID: <060.02846cd6ddd34a025f932bc62a4ec603@haskell.org> #10089: feature: warn about unused data definitions (with typeclass instances) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: dfordivam Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 3221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfordivam): * related: => 3221 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 06:20:34 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 06:20:34 -0000 Subject: [GHC] #10089: feature: warn about unused data definitions (with typeclass instances) In-Reply-To: <045.113d906ba3b76ec22ad2f715d9c6da96@haskell.org> References: <045.113d906ba3b76ec22ad2f715d9c6da96@haskell.org> Message-ID: <060.64f84bfdcb023bb973e3e0cc656baaa7@haskell.org> #10089: feature: warn about unused data definitions (with typeclass instances) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: dfordivam Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfordivam): * related: 3221 => #3221 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 10:03:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 10:03:15 -0000 Subject: [GHC] #10931: layers-0.1 does not compile with ghc-7.10 (likely a regression from ghc-7.8) In-Reply-To: <045.19b8056b1d70bf96a656ae7348a956cb@haskell.org> References: <045.19b8056b1d70bf96a656ae7348a956cb@haskell.org> Message-ID: <060.03a11e3e877e718d8cdbacd549f3ab7e@haskell.org> #10931: layers-0.1 does not compile with ghc-7.10 (likely a regression from ghc-7.8) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T10931 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => indexed-types/should_compile/T10931 * milestone: => 8.0.1 Comment: Replying to [comment:4 goldfire]: > This seems to have many of the same elements to #10009, which indeed cannot be merged. Replying to [comment:5 slyfox]: > Nonworking library in 7.10 is absolutely not a problem for me. Let's close this one then, it is fixed in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 12:45:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 12:45:27 -0000 Subject: [GHC] #10007: Fix misattribution of Cost Centre profiles to lintAnnots In-Reply-To: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> References: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> Message-ID: <067.f2d100158141ab3e2a6293656e62b567@haskell.org> #10007: Fix misattribution of Cost Centre profiles to lintAnnots -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: scpmw Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Profiling | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9961,#5654 | Differential Rev(s): Phab:D616 Wiki Page: | Phab:D636 -------------------------------------+------------------------------------- Changes (by bgamari): * related: #9961 => #9961,#5654 Comment: This may be related to #5654. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 12:45:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 12:45:41 -0000 Subject: [GHC] #5654: Profiling semantics bug In-Reply-To: <047.ac296d247951e42a341a674c3c07d355@haskell.org> References: <047.ac296d247951e42a341a674c3c07d355@haskell.org> Message-ID: <062.65bdf19ba607c5e7cdffa3503d1add2b@haskell.org> #5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #10007 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 12:49:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 12:49:13 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.9013d52c351c083e346cbdea5856dc88@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 5321 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Oh dear, I cited the wrong ticket; I meant #5642 which also appears to be generating large strings coercions (in particular when deriving `Generic` on a large product type). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 12:50:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 12:50:51 -0000 Subject: [GHC] #6166: Performance regression in mwc-random since 7.0.x In-Reply-To: <042.f838154dee2d7e7158fd4f9ebd6ea928@haskell.org> References: <042.f838154dee2d7e7158fd4f9ebd6ea928@haskell.org> Message-ID: <057.d13ce3ed681c1ae7fd72e3f4d4841e30@haskell.org> #6166: Performance regression in mwc-random since 7.0.x -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > I've had a report that the performance of the mwc-random package has > regressed seriously after upgrading from GHC 7.0 to 7.4. It turns out > that 7.2 also has the regression. > > Here's a sample program. > > {{{ > import qualified Data.Vector.Unboxed as U > > import qualified System.Random.MWC as R > import System.Random.MWC.Distributions (standard) > > count = 1000 * 1000 > > fast gen = standard gen > > slow gen = standard gen >>= return > > -- Edit this to choose fast or slow. > which gen = slow gen > > main = do > gen <- R.create > v <- U.replicateM count (which gen) > print (U.last v) > }}} > > With GHC 7.0.3 -O2, this runs in 0.294 sec, regardless of whether `fast` > or `slow` is used. > > Under 7.4, `fast` runs in 0.062 sec (a nice speedup!), but `slow` now > takes 9.2 sec (yikes!). > > Roman suggested compiling the `slow` version with `-fno-state-hack`, > which brings performance back up to 0.062 sec. New description: I've had a report that the performance of the mwc-random package has regressed seriously after upgrading from GHC 7.0 to 7.4. It turns out that 7.2 also has the regression. Here's a sample program. {{{#!hs import qualified Data.Vector.Unboxed as U import qualified System.Random.MWC as R import System.Random.MWC.Distributions (standard) count = 1000 * 1000 fast gen = standard gen slow gen = standard gen >>= return -- Edit this to choose fast or slow. which gen = slow gen main = do gen <- R.create v <- U.replicateM count (which gen) print (U.last v) }}} With GHC 7.0.3 -O2, this runs in 0.294 sec, regardless of whether `fast` or `slow` is used. Under 7.4, `fast` runs in 0.062 sec (a nice speedup!), but `slow` now takes 9.2 sec (yikes!). Roman suggested compiling the `slow` version with `-fno-state-hack`, which brings performance back up to 0.062 sec. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 12:52:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 12:52:31 -0000 Subject: [GHC] #6166: Performance regression in mwc-random since 7.0.x In-Reply-To: <042.f838154dee2d7e7158fd4f9ebd6ea928@haskell.org> References: <042.f838154dee2d7e7158fd4f9ebd6ea928@haskell.org> Message-ID: <057.82ea5701162a9dc874c4ee425bdbb222@haskell.org> #6166: Performance regression in mwc-random since 7.0.x -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high Comment: This looks like a pretty serious performance regression, bumping priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 13:09:29 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 13:09:29 -0000 Subject: [GHC] #6166: Performance regression in mwc-random since 7.0.x In-Reply-To: <042.f838154dee2d7e7158fd4f9ebd6ea928@haskell.org> References: <042.f838154dee2d7e7158fd4f9ebd6ea928@haskell.org> Message-ID: <057.e213c1e6569394efe59b87a66fe79cfd@haskell.org> #6166: Performance regression in mwc-random since 7.0.x -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Khudyakov): Does same regression present in latest version of mwc-random? AFAIR performance regression appears because GHC sometimes chose to inline lookup table in where block. It's marked as NOINLINE. It thus was recalculated on each call and caused slowdown. I moved it at top level and problem disapeared. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 13:16:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 13:16:39 -0000 Subject: [GHC] #10967: Release a new stm package on Hackage Message-ID: <048.5f8e847ed74659a561fb4c92223590be@haskell.org> #10967: Release a new stm package on Hackage -------------------------------------+------------------------------------- Reporter: svenpanne | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: (other) | Keywords: stm | 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, the latest stm package on Hackage (2.4.4) doesn't compile with GHC HEAD (see e.g. https://travis-ci.org/haskell- opengl/OpenGL/jobs/85320391), which makes testing of various other packages with HEAD imposiible. Things seem to be fixed in git already, can we have a new release of stm? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 13:20:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 13:20:33 -0000 Subject: [GHC] #10964: User's Guide build error on Debian Wheezy In-Reply-To: <048.8967d262318647c29b8ad8ebceab90fa@haskell.org> References: <048.8967d262318647c29b8ad8ebceab90fa@haskell.org> Message-ID: <063.d8855e09412db798f65f5841131c8029@haskell.org> #10964: User's Guide build error on Debian Wheezy -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.11 Resolution: | Keywords: Operating System: 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): Hmm, very odd. This very much looks like a sphinx bug (one that is apparently already fixed in Debian Jessie). If you would like you can bring this up with the Sphinx folks otherwise the obvious workaround would be to simply disable building of the LaTeX version of the users guide (set `BUILD_SPHINX_HTML=NO`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 13:21:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 13:21:04 -0000 Subject: [GHC] #10964: User's Guide build error on Debian Wheezy In-Reply-To: <048.8967d262318647c29b8ad8ebceab90fa@haskell.org> References: <048.8967d262318647c29b8ad8ebceab90fa@haskell.org> Message-ID: <063.23981fdc19808a989293c7ec8062650f@haskell.org> #10964: User's Guide build error on Debian Wheezy -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.11 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 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 15:57:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 15:57:23 -0000 Subject: [GHC] #10967: Release a new stm package on Hackage In-Reply-To: <048.5f8e847ed74659a561fb4c92223590be@haskell.org> References: <048.5f8e847ed74659a561fb4c92223590be@haskell.org> Message-ID: <063.15f3eff3e2a10cacd5edbc4724f70b91@haskell.org> #10967: Release a new stm package on Hackage -------------------------------------+------------------------------------- Reporter: svenpanne | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: libraries | Version: (other) | 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: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr (added) * type: bug => task * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 16:01:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 16:01:17 -0000 Subject: [GHC] #10931: layers-0.1 does not compile with ghc-7.10 (likely a regression from ghc-7.8) In-Reply-To: <045.19b8056b1d70bf96a656ae7348a956cb@haskell.org> References: <045.19b8056b1d70bf96a656ae7348a956cb@haskell.org> Message-ID: <060.8306b2f411da0fd187bc6eaf8677cd0e@haskell.org> #10931: layers-0.1 does not compile with ghc-7.10 (likely a regression from ghc-7.8) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T10931 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 16:06:45 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 16:06:45 -0000 Subject: [GHC] #10968: Type hole cause bad type checking Message-ID: <049.4a3c7764d1bd9d3c6fd3ad1fc44fc805@haskell.org> #10968: Type hole cause bad type checking -------------------------------------+------------------------------------- Reporter: ndtimofeev | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've tried to compile that incorrect code on ghc-7.10.2 linux x86_64: {{{#!hs import Control.Monad.Reader type Tst m = ReaderT () (ReaderT Int m) f :: Monad m => Tst m () f = return () f1 :: ReaderT () m () -> ReaderT () m () f1 ev = f >> _ >> ev main :: IO () main = print $ runReaderT (f1 (return ())) () }}} But ?ypechecker does not reject f1 and have that: {{{ [1 of 1] Compiling Main ( /home/ndtimofeev/tst.hs, /home/ndtimofeev/tst.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): StgCmmEnv: variable not found $dFunctor_aYS local binds for: f_rsZ Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} If switch hole to undefined, i have normal typechecking error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 16:27:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 16:27:54 -0000 Subject: [GHC] #10968: Type hole cause bad type checking In-Reply-To: <049.4a3c7764d1bd9d3c6fd3ad1fc44fc805@haskell.org> References: <049.4a3c7764d1bd9d3c6fd3ad1fc44fc805@haskell.org> Message-ID: <064.30b247e1e5892c9c64a10ac99c7aa5e0@haskell.org> #10968: Type hole cause bad type checking -------------------------------------+------------------------------------- Reporter: ndtimofeev | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I can't reproduce this. How are you running ghc? {{{ GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( test.hs, interpreted ) test.hs:10:14: Found hole ?_? with type: ReaderT () m a0 Where: ?m? is a rigid type variable bound by the type signature for f1 :: ReaderT () m () -> ReaderT () m () at test.hs:9:7 ?a0? is an ambiguous type variable Relevant bindings include ev :: ReaderT () m () (bound at test.hs:10:4) f1 :: ReaderT () m () -> ReaderT () m () (bound at test.hs:10:1) In the second argument of ?(>>)?, namely ?_? In the first argument of ?(>>)?, namely ?f >> _? In the expression: f >> _ >> ev Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 16:30:49 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 16:30:49 -0000 Subject: [GHC] #10968: Type hole cause bad type checking In-Reply-To: <049.4a3c7764d1bd9d3c6fd3ad1fc44fc805@haskell.org> References: <049.4a3c7764d1bd9d3c6fd3ad1fc44fc805@haskell.org> Message-ID: <064.b84cb269323ae0194b181d619eeba3d8@haskell.org> #10968: Type hole cause bad type checking -------------------------------------+------------------------------------- Reporter: ndtimofeev | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ndtimofeev): I lost the line when the edit issue. {{{ $ ghc ~/tst.hs -fdefer-typed-holes -fno-warn-typed-holes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 16:35:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 16:35:18 -0000 Subject: [GHC] #10968: Type hole cause bad type checking In-Reply-To: <049.4a3c7764d1bd9d3c6fd3ad1fc44fc805@haskell.org> References: <049.4a3c7764d1bd9d3c6fd3ad1fc44fc805@haskell.org> Message-ID: <064.6730ded182aa13a6732ded8f538d43a3@haskell.org> #10968: Type hole cause bad type checking -------------------------------------+------------------------------------- Reporter: ndtimofeev | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > I've tried to compile that incorrect code on ghc-7.10.2 linux x86_64: > > {{{#!hs > import Control.Monad.Reader > > type Tst m = ReaderT () (ReaderT Int m) > > f :: Monad m => Tst m () > f = return () > > f1 :: ReaderT () m () -> ReaderT () m () > f1 ev = f >> _ >> ev > > main :: IO () > main = print $ runReaderT (f1 (return ())) () > }}} > > But ?ypechecker does not reject f1 and have that: > > {{{ > [1 of 1] Compiling Main ( /home/ndtimofeev/tst.hs, > /home/ndtimofeev/tst.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 7.10.2 for x86_64-unknown-linux): > StgCmmEnv: variable not found > $dFunctor_aYS > local binds for: > f_rsZ > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > If switch hole to undefined, i have normal typechecking error. New description: I've tried to compile that incorrect code on ghc-7.10.2 linux x86_64: {{{#!hs import Control.Monad.Trans.Reader type Tst m = ReaderT () (ReaderT Int m) f :: Monad m => Tst m () f = return () f1 :: ReaderT () m () -> ReaderT () m () f1 ev = f >> _ >> ev main :: IO () main = print $ runReaderT (f1 (return ())) () }}} But ?ypechecker does not reject f1 and have that: {{{ [1 of 1] Compiling Main ( /home/ndtimofeev/tst.hs, /home/ndtimofeev/tst.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): StgCmmEnv: variable not found $dFunctor_aYS local binds for: f_rsZ Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} If switch hole to undefined, i have normal typechecking error. -- Comment (by mpickering): OK, I can reproduce this now. With HEAD, I instead get the following errors.. which I can't comment any further on. I also changed the test to use Control.Monad.Trans.Reader instead of the mtl import. {{{ ~/Documents/haskell/ghc/inplace:./bin/ghc-stage2 test.hs -fdefer-typed- holes -fno-warn-typed-holes [1 of 1] Compiling Main ( test.hs, test.o ) test.hs:10:9: error: Couldn't match type ?m? with ?ReaderT Int m0? ?m? is a rigid type variable bound by the type signature for: f1 :: ReaderT () m () -> ReaderT () m () at test.hs:9:7 Expected type: ReaderT () m () Actual type: Tst m0 () Relevant bindings include ev :: ReaderT () m () (bound at test.hs:10:4) f1 :: ReaderT () m () -> ReaderT () m () (bound at test.hs:10:1) In the first argument of ?(>>)?, namely ?f? In the first argument of ?(>>)?, namely ?f >> _? test.hs:13:8: error: Ambiguous type variable ?m1? arising from a use of ?print? prevents the constraint ?(Show (m1 ()))? from being solved. Probable fix: use a type annotation to specify what ?m1? should be. These potential instances exist: instance Show a => Show (Maybe a) -- Defined in ?GHC.Show? instance (Show a, Show b) => Show (a, b) -- Defined in ?GHC.Show? instance (Show a, Show b, Show c) => Show (a, b, c) -- Defined in ?GHC.Show? ...plus 13 others (use -fprint-potential-instances to see them all) In the expression: print In the expression: print $ runReaderT (f1 (return ())) () In an equation for ?main?: main = print $ runReaderT (f1 (return ())) () test.hs:13:32: error: Ambiguous type variable ?m1? arising from a use of ?return? prevents the constraint ?(Monad m1)? from being solved. Probable fix: use a type annotation to specify what ?m1? should be. These potential instances exist: instance [safe] Monad m => Monad (ReaderT r m) -- Defined in ?Control.Monad.Trans.Reader? instance Monad IO -- Defined in ?GHC.Base? instance Monad Maybe -- Defined in ?GHC.Base? ...plus three others (use -fprint-potential-instances to see them all) In the first argument of ?f1?, namely ?(return ())? In the first argument of ?runReaderT?, namely ?(f1 (return ()))? In the second argument of ?($)?, namely ?runReaderT (f1 (return ())) ()? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 18:36:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 18:36:04 -0000 Subject: [GHC] #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" In-Reply-To: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> References: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> Message-ID: <060.5f309511bcc25a8b0f1aa98094de46fe@haskell.org> #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I was waiting to hear back from ezyang before closing but it's quite likely that this is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 18:46:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 18:46:33 -0000 Subject: [GHC] #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" In-Reply-To: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> References: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> Message-ID: <060.5462994dfb8bdafabc91621e2686a79b@haskell.org> #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Sorry! I haven't seen the error recently, so looks OK. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 20:36:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 20:36:03 -0000 Subject: [GHC] #1853: hpc mix files for Main modules overwrite each other In-Reply-To: <044.9b946ad54a9a35d3915c7a74c107b816@haskell.org> References: <044.9b946ad54a9a35d3915c7a74c107b816@haskell.org> Message-ID: <059.986245b9041e362a6e5447720adeebdf@haskell.org> #1853: hpc mix files for Main modules overwrite each other ----------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Code Coverage | Version: 6.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by andygill): Replying to [comment:18 mgsloan]: I would support this change, or in general, adding some type of way of designating the location and/or naming of the .tix file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 20:38:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 20:38:41 -0000 Subject: [GHC] #1853: hpc mix files for Main modules overwrite each other In-Reply-To: <044.9b946ad54a9a35d3915c7a74c107b816@haskell.org> References: <044.9b946ad54a9a35d3915c7a74c107b816@haskell.org> Message-ID: <059.3a8cdbc020c9400e34d7ff2f8265c858@haskell.org> #1853: hpc mix files for Main modules overwrite each other ----------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Code Coverage | Version: 6.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by andygill): I've not touched hpc for years, but am happy to try help. Perhaps we could work on a concrete failure, and decide where to go from there? Can we create a small github repo with the failures, for example. The solution would need to integrate with cabal, for example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 22:08:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 22:08:22 -0000 Subject: [GHC] #10870: PPC.Ppr: Shift by 32 bits is not allowed. In-Reply-To: <046.266af0561f46fb382b81907ac208339a@haskell.org> References: <046.266af0561f46fb382b81907ac208339a@haskell.org> Message-ID: <061.e2a40da2cbb0f55f9b423dd0662ef885@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler (CodeGen) | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1322 Wiki Page: | ---------------------------------------+---------------------------------- Changes (by erikd): * milestone: => 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 23:09:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 23:09:57 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.10c47c0b3ead336264869d4f9f095569@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1323 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"933adc0f31164cb651d11ecfcfe612ac429f714f/ghc" 933adc0f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="933adc0f31164cb651d11ecfcfe612ac429f714f" Fix GHCi on Arm (#10375). Arm has two instruction sets, Arm and Thumb, and an execution mode for each. Executing Arm code in Thumb mode or vice-versa will likely result in an Illegal instruction exception. Furthermore, Haskell code compiled via LLVM was generating Arm instructions while C code compiled via GCC was generating Thumb code by default. When these two object code types were being linked by the system linker, all was fine, because the system linker knows how to jump and call from one instruction set to the other. The first problem was with GHCi's object code loader which did not know about Thumb vs Arm. When loading an object file `StgCRun` would jump into the loaded object which could change the mode causing a crash after it returned. This was fixed by forcing all C code to generate Arm instructions by passing `-marm` to GCC. The second problem was the `mkJumpToAddr` function which was generating Thumb instructions. Changing that to generate Arm instructions instead results in a working GHCi on Arm. Test Plan: validate on x86_64 and arm Reviewers: bgamari, austin, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1323 GHC Trac Issues: #10375 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 23:11:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 23:11:14 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.264e8d8a2f1b337464f08c2e68a7a265@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1323 Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 23:38:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 23:38:54 -0000 Subject: [GHC] #10969: Arm: Investigate Thumb2/Arm interworking Message-ID: <044.fa8c11149986ab1ddb8a06ca3760d5cd@haskell.org> #10969: Arm: Investigate Thumb2/Arm interworking -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Keywords: arm, thumb | Operating System: Unknown/Multiple Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #10375 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Arm (32 bit) has two commonly used instruction sets; Thumb2 and Arm. The former is encoded in two bytes per instruction and the latter in four bytes. The CPU also has a bit in the flags register specifyng which code execution mode the CPU is currently in. The important thing to note is that executing Arm code when in Thumb2 mode (or vice versa) will sooner or later result in an illegal insruction or segfault. During debugging of #10375, I found that Haskell code compiled via the LLVM backend was generating Arm instructions, while C code compiled via GCC was generating Thumb2 code. When object code from these two paths are linked by the system linker everything is fine because the system linker knows how to link Thumb code to Arm code to produce a valid binary. The problem in #10375 was that in GHCi, the runtime linker was loading object files without the correct fixups between Thumb2 and Arm so that Thumb2 code in the `StgRun` function was jumping correctly into Arm code in the loaded object and returning to the Thumb2 code in `StgRun` while still in Arm execution mode and then crashing. In commit [changeset:"933adc0f31164cb651d11ecfcfe612ac429f714f/ghc" 933adc0f/ghc] I fixed GHCi for Arm by forcing GHC to generate only Arm code. As discussed in the associated Phab:D1323 it would be nice to investigate this further to see if its possible to make GHC generate Thumb2 code (which potentially has some performance benefits since it encodes all instructions in two bytes) and/or fix Thumb2/Arm interop. However, that interop may not be possible. In one of the comments in the Phab:D1323, @bgamari said: > That being said, I don't think we'll ever be able to support linking of Thumb Haskell code with ARM Haskell code. The reason for this is that interop requires the use of a trampoline, which breaks tables-next-to- code. Two possible outcomes for this ticket are: * We somehow get proper Thumb2/Arm code interoperation working. * We decide that interop is too difficult or not worthwhile and a) document this somewhere in the code and b) remove the Thumb2 relocation code in `rts/Linker.c` and all other references to Thumb2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 14 23:39:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Oct 2015 23:39:59 -0000 Subject: [GHC] #10969: Arm: Investigate Thumb2/Arm interworking In-Reply-To: <044.fa8c11149986ab1ddb8a06ca3760d5cd@haskell.org> References: <044.fa8c11149986ab1ddb8a06ca3760d5cd@haskell.org> Message-ID: <059.a11f68884ce92413221de90dba351046@haskell.org> #10969: Arm: Investigate Thumb2/Arm interworking ---------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.11 Resolution: | Keywords: arm, thumb Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10375 | Differential Rev(s): Wiki Page: | ---------------------------------------+---------------------------------- Changes (by erikd): * cc: bgamari, kgardas (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 00:00:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 00:00:58 -0000 Subject: [GHC] #10969: Arm: Investigate Thumb2/Arm interworking In-Reply-To: <044.fa8c11149986ab1ddb8a06ca3760d5cd@haskell.org> References: <044.fa8c11149986ab1ddb8a06ca3760d5cd@haskell.org> Message-ID: <059.dbf450294ae5b5ea52212ea78f0869e7@haskell.org> #10969: Arm: Investigate Thumb2/Arm interworking ---------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.11 Resolution: | Keywords: arm, thumb Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10375 | Differential Rev(s): Wiki Page: | ---------------------------------------+---------------------------------- Comment (by erikd): Before I wrote up this ticket I actually did some testing, building GHC with three changes on top of what became commit [changeset:"933adc0f31164cb651d11ecfcfe612ac429f714f/ghc" 933adc0f/ghc]: * Removed the `-marm` that was being passed to gcc. * In `compiler/llvmGen/LlvmCodeGen/Ppr.hs` set the target triple to `thumbv6-unknown-linux-gnueabihb` to force the Haskell via LLVM path to generate Thumb2 code. * Revert the change to `compiler/ghci/ByteCodeItbls.hs` so that it generates Thumb2 code. I also manually checked (using `objdump -d` on the object files) that both the via-gcc and the via-llvm paths were generating Thumb2 code. However, with the changes above the first stage2 execuable to run crashes immediately with an illegal instruction. Unfortunately I don't have time to work on this further right now as I would like to prioritize getting Arm64 working for the 8.0 release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 00:01:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 00:01:53 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.0d6f11244e3f387125f5135f52da95e2@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #10969 | Differential Rev(s): Phab:D1323 Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * related: => #10969 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 04:38:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 04:38:28 -0000 Subject: [GHC] #10714: After implementing new installed package ID (hash of sdist), get rid of package keys In-Reply-To: <045.13deae8316589a147d8e83f0a90ec4d1@haskell.org> References: <045.13deae8316589a147d8e83f0a90ec4d1@haskell.org> Message-ID: <060.008b8d54c36f92a7aee8857df6b798f2@haskell.org> #10714: After implementing new installed package ID (hash of sdist), get rid of package keys -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"5b0191f74ab05b187f81ea037623338a615b1619/ghc" 5b0191f7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5b0191f74ab05b187f81ea037623338a615b1619" Update Cabal to HEAD, IPID renamed to Component ID. This commit contains a Cabal submodule update which unifies installed package IDs and package keys under a single notion, a Component ID. We update GHC to keep follow this unification. However, this commit does NOT rename installed package ID to component ID and package key to unit ID; the plan is to do that in a companion commit. - Compiler info now has "Requires unified installed package IDs" - 'exposed' is now expected to contain unit keys, not IPIDs. - Shadowing is no more. We now just have a very simple strategy to deal with duplicate unit keys in combined package databases: if their ABIs are the same, use the latest one; otherwise error. Package databases maintain the invariant that there can only be one entry of a unit ID. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin, bgamari, hvr, goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1184 GHC Trac Issues: #10714 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 04:50:40 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 04:50:40 -0000 Subject: [GHC] #10714: After implementing new installed package ID (hash of sdist), get rid of package keys In-Reply-To: <045.13deae8316589a147d8e83f0a90ec4d1@haskell.org> References: <045.13deae8316589a147d8e83f0a90ec4d1@haskell.org> Message-ID: <060.cc2989f72846cbe273be8dca90212090@haskell.org> #10714: After implementing new installed package ID (hash of sdist), get rid of package keys -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: Component: Package system | Version: 7.10.2 Resolution: fixed | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 06:10:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 06:10:06 -0000 Subject: [GHC] #10970: Built in MIN_VERSION macro support Message-ID: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> #10970: Built in MIN_VERSION macro support -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- Pursuant to https://mail.haskell.org/pipermail/ghc- devs/2015-September/010015.html Recapped here: when preprocessing Haskell source code, we generate a temporary stub header file which defines a number of MIN_VERSION macros, ala what Cabal generates today. Specifically, for every explicitly specified package dependency (via a `-package` or `-package-id` argument), we generate a `MIN_VERSION_pkgname` macro which tests for the version recorded for the package database. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 11:08:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 11:08:57 -0000 Subject: [GHC] #10966: dirtiness checking isn't keeping track of which source file contained Main In-Reply-To: <044.5fcdeb9071ae79d9f9b6bcbc72d714db@haskell.org> References: <044.5fcdeb9071ae79d9f9b6bcbc72d714db@haskell.org> Message-ID: <059.59f48eda38b63903b47b60ff0da76fb0@haskell.org> #10966: dirtiness checking isn't keeping track of which source file contained Main -------------------------------------+------------------------------------- Reporter: gueux | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * Attachment "Devel.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 11:09:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 11:09:11 -0000 Subject: [GHC] #10966: dirtiness checking isn't keeping track of which source file contained Main In-Reply-To: <044.5fcdeb9071ae79d9f9b6bcbc72d714db@haskell.org> References: <044.5fcdeb9071ae79d9f9b6bcbc72d714db@haskell.org> Message-ID: <059.fd86bce64560705f1ebb84d2d44e2b88@haskell.org> #10966: dirtiness checking isn't keeping track of which source file contained Main -------------------------------------+------------------------------------- Reporter: gueux | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * Attachment "Main.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 11:15:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 11:15:00 -0000 Subject: [GHC] #10966: dirtiness checking isn't keeping track of which source file contained Main In-Reply-To: <044.5fcdeb9071ae79d9f9b6bcbc72d714db@haskell.org> References: <044.5fcdeb9071ae79d9f9b6bcbc72d714db@haskell.org> Message-ID: <059.81de58802878b478fde0034e0fb3c244@haskell.org> #10966: dirtiness checking isn't keeping track of which source file contained Main -------------------------------------+------------------------------------- Reporter: gueux | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): To reproduce: {{{ $ ghc Devel.hs -o foo $ ./foo # prints: "dev". Ok. $ ghc Main.hs -o foo $ ./foo # prints: "not dev". Ok. $ ghc Devel.hs -o foo $ ./foo # prints: "not dev". Should print "dev" (this is the bug). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 11:17:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 11:17:00 -0000 Subject: [GHC] #10966: dirtiness checking isn't keeping track of which source file contained Main In-Reply-To: <044.5fcdeb9071ae79d9f9b6bcbc72d714db@haskell.org> References: <044.5fcdeb9071ae79d9f9b6bcbc72d714db@haskell.org> Message-ID: <059.e92410782f4862078f29de94a1e813e9@haskell.org> #10966: dirtiness checking isn't keeping track of which source file contained Main -------------------------------------+------------------------------------- Reporter: gueux | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Driver -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 11:17:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 11:17:55 -0000 Subject: [GHC] #10871: Implement "fat" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.40d708342a977c5e650a3dbe51ff3b86@haskell.org> #10871: Implement "fat" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: 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): Hmmm... as you know, I'm pretty strongly opposed to the idea of saving source code, and this just seems like another variant of saving source code. When the instantiations of the holes are available, just compile the source code against the now-concrete dependencies. Until the concrete instantiations are available, you can typecheck but do nothing else. There are good reasons to want to do it this way - the main one being that "cabal install" should be an effect-free operation, except insofar as it makes things available in GHCi. If "cabal install" has a side effect, then it becomes very hard to explain the user interface, because we have to take into account the state of the system somehow, and I'm sure this will cause problems for users. We really want "cabal install" to depend on its inputs and nothing more. I understand that the motivation is to compile "the same thing that we typechecked" in some sense, but the right way to ensure that is to make sure you give "cabal install" the same inputs that it had when you typechecked, that is, move the guarantee of consistency to a higher level. I don't object to the idea of fat interface files per se, but I wonder whether it's a feature that will pay for itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 11:25:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 11:25:49 -0000 Subject: [GHC] #10969: Arm: Investigate Thumb2/Arm interworking In-Reply-To: <044.fa8c11149986ab1ddb8a06ca3760d5cd@haskell.org> References: <044.fa8c11149986ab1ddb8a06ca3760d5cd@haskell.org> Message-ID: <059.5fbbb8a5852707dd17ca2a447d097f01@haskell.org> #10969: Arm: Investigate Thumb2/Arm interworking ---------------------------------------+---------------------------------- Reporter: erikd | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.11 Resolution: | Keywords: arm, thumb Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10375 | Differential Rev(s): Wiki Page: | ---------------------------------------+---------------------------------- Changes (by thomie): * type: bug => task -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 12:19:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 12:19:21 -0000 Subject: [GHC] #10272: hsc2hs : directive let cannot be handled in cross-compilation mode In-Reply-To: <044.8913742417593b59443e51343d8c3d48@haskell.org> References: <044.8913742417593b59443e51343d8c3d48@haskell.org> Message-ID: <059.e158006fa0055f53be8ce000c453b62d@haskell.org> #10272: hsc2hs : directive let cannot be handled in cross-compilation mode -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: hsc2hs | Version: 7.11 Resolution: | Keywords: cross- | compiling Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #10070 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 14:53:17 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 14:53:17 -0000 Subject: [GHC] #10971: ExtendedDefaultRules defaults to [] for Foldable/Traversable Message-ID: <045.2898b5f70867473328360d4f8d9156ac@haskell.org> #10971: ExtendedDefaultRules defaults to [] for Foldable/Traversable -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 10963 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From goldfire: > Extend -XExtendedDefaultRules to allow defaulting when one of the classes involved is Foldable or Traversable. (See the current rules ?here.) This will mean, essentially, that there will be two lists of default types, one list at kind * and one at kind * -> *. Both lists should be settable by the user by the default directive. (GHC can figure out which list is being set quite easily.) The default default list for * -> * will be []. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 14:54:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 14:54:48 -0000 Subject: [GHC] #10972: Add a :binfo (beginner info) GHCi command Message-ID: <045.69c25027f6e9192e0896957840c11b0e@haskell.org> #10972: Add a :binfo (beginner info) GHCi command -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10963 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From goldfire: > Add a new command to GHCi, :binfo (for "beginner info") (please suggest a better name) that is like :info but presents different information. It suppresses in-scope instances, but attempts to specialize a function's type and presents specializations, using heuristics. So when we say :binfo find, we'll see Foldable t => (a -> Bool) -> t a -> Maybe a but also (a -> Bool) -> [a] -> Maybe a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 14:55:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 14:55:11 -0000 Subject: [GHC] #10971: ExtendedDefaultRules defaults to [] for Foldable/Traversable In-Reply-To: <045.2898b5f70867473328360d4f8d9156ac@haskell.org> References: <045.2898b5f70867473328360d4f8d9156ac@haskell.org> Message-ID: <060.3c1e1d77cf5be0f3eac63b04ec7ed5f2@haskell.org> #10971: ExtendedDefaultRules defaults to [] for Foldable/Traversable -------------------------------------+------------------------------------- Reporter: kanetw | Owner: kanetw Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kanetw): * owner: => kanetw * related: 10963 => #10963 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 18:14:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 18:14:03 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.32dab599259a0242f2507e8a0a611d8e@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1259 Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): I'm not very impressed with the performance metrics on Phab:D1259 ([https://gist.github.com/gridaphobe/0657f02571e6df4588f7 nofib diff]), and I have a small example that I think may illustrate the problem. {{{ foo x = "foo" ++ x boo = "foo" }}} Compare what ghc-master does {{{ % ghc -O -fforce-recomp -ddump-simpl -dsuppress-all Foo.hs [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) ==================== Tidy Core ==================== Result size of Tidy Core = {terms: 8, types: 8, coercions: 0} boo boo = unpackCString# "foo"# foo foo = \ x_amS -> unpackAppendCString# "foo"# x_amS }}} to what my branch does {{{ % ./inplace/bin/ghc-stage2 -O -fforce-recomp -ddump-simpl -dsuppress-all Foo.hs [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) ==================== Tidy Core ==================== Result size of Tidy Core = {terms: 8, types: 9, coercions: 0} -- RHS size: {terms: 2, types: 0, coercions: 0} boo boo = unpackCString# "foo"# -- RHS size: {terms: 4, types: 3, coercions: 0} foo foo = \ x_anI -> ++ boo x_anI }}} Lifting the boxed string literal to a top-level binder prevents ghc from rewriting the `++` to `unpackAppendCString#`. Why? Because `boo` is a `String` not an `Addr#`, so applying the rewrite would require inlining the `"foo"#` string literal, which ghc does not want to do. What we really want (I think) is to make a top-level binder for `"foo"# :: Addr#`, so we'd end up with something like {{{ foo# = "foo"# boo = unpackCString# foo# foo = \ x_amS -> unpackAppendCString# foo# x_amS }}} Concretely, I propose that the desugarer-specific `mkStringExpr` function create '''two''' top-level binders, one for the `Addr#` and one for the `String`. That should let us share the unboxed string '''and''' the boxed string. Does this seem reasonable? Or is my sample program simply a non-issue? (Sorry to keep jumping back and forth between phab and trac, but this seemed to fit better on the ticket than on the diff.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 18:59:01 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 18:59:01 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.de2b9177f7b37cb94ad0b79ee224b23f@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1259 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See #7307 and #8472. But if `unpackCString#` is marked CONLIKE, the rewrites for `++` should still work. Don't they? That's the whole point of CONLIKE -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 20:12:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 20:12:38 -0000 Subject: [GHC] #10871: Implement "fat" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.0a2cccdca4758b9fad0cfda538df7ccb@haskell.org> #10871: Implement "fat" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): I would agree that the primary payoff of this feature is Backpack; without it, I think there is much less motivation. I think the "external core" use-case could be quite compelling, but there's more work to do extracting the interface file parser into its own library. Do fat interfaces violate cabal install "depending on its inputs, and nothing more"? When I try to answer this question, I find myself asking, "what distinguishes these from normal interface files which we save for packages that are already installed?" Let me recap Duncan's new plan for implementing cabal install so that it is minimally affected by the existing database of packages: 1. We first solve dependencies, without making any reference to the existing package database. This allows us to compute a number of IPIDs of configured packages. 2. Then, we *improve* these configured packages into installed packages simply by looking up their IPIDs in the package database. 3. When we compile, we begin as if we had already compiled the already installed packages, and finish up building and installing the rest of the packages in the plan. The emphasis seems to be removing side effects from step (1); but of course we do want to avoid rebuilding things that are already built, so (2) is "effectful" but in a benign way. I think this plan, which avoids side-effects during dependency resolution, works for Backpack fat interfaces too. Here's how it looks: 1. Once again, we solve dependencies. This gives a number of component IDs for all configured components. 2. We improve these configured components into installed components. Some of these will map to pre-compiled components, but others will map to *indefinite components* which were installed with fat interface file 3. When we compile, we begin as if we had compiled all the installed packages, and partially compiled all the indefinite ones, and just "finish" up the rest of the build according to the plan. There is extra complexity with ensuring that instantiated units get deduplicated correctly (arising from Backpack's applicativity) but I really think that fat interface files support the method that you are looking for. Let me also point out the other big difference between fat interface files and source files: GHC *always* knows how to compile fat interface files. You cannot have any sort of custom build system associated with them. They're just a big pile of inlinings; there's no external C code, no preprocessing, etc. This means, for example, that if you want a indefinite component with some C code, the C code gets built ONCE when you initially installed the indefinite package, not each time you instantiate the component. I'd really like to get you on board with this new plan, so let me know if you want to chat about it some more. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 20:18:17 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 20:18:17 -0000 Subject: [GHC] #10973: Building git HEAD with a singe make job fails due to dependency problem Message-ID: <044.ce71bd5536233be44928eb09733a9711@haskell.org> #10973: Building git HEAD with a singe make job fails due to dependency problem -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 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: -------------------------------------+------------------------------------- If I clone git HEAD and do: {{{ perl boot && ./configure && make }}} The build fails with: {{{ /usr/bin/ld: cannot find -lHSghc-boot-0.0.0.0 collect2: error: ld returned 1 exit status }}} and it keeps failing if I run `make` without any `-j` option. Building with `make -j` where `N` is 2 or more is fine. Looks like some sort of dependency problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 20:20:41 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 20:20:41 -0000 Subject: [GHC] #10973: Building git HEAD with a singe make job fails due to dependency problem In-Reply-To: <044.ce71bd5536233be44928eb09733a9711@haskell.org> References: <044.ce71bd5536233be44928eb09733a9711@haskell.org> Message-ID: <059.37cf8286f2c011da9e638a22a4b1c344@haskell.org> #10973: Building git HEAD with a singe make job fails due to dependency problem -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 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: | -------------------------------------+------------------------------------- Description changed by erikd: Old description: > If I clone git HEAD and do: > > {{{ > perl boot && ./configure && make > }}} > > The build fails with: > > {{{ > /usr/bin/ld: cannot find -lHSghc-boot-0.0.0.0 > collect2: error: ld returned 1 exit status > }}} > > and it keeps failing if I run `make` without any `-j` option. > > Building with `make -j` where `N` is 2 or more is fine. > > Looks like some sort of dependency problem. New description: If I clone git HEAD and do: {{{ perl boot && ./configure && make }}} The build fails with: {{{ /usr/bin/ld: cannot find -lHSghc-boot-0.0.0.0 collect2: error: ld returned 1 exit status }}} and after that point it keeps failing no matter what I do. Doing a `make clean` followed by `make -j` with N >= 2 is fine. Akso building from scratch with: {{{ perl boot && ./configure && make -j }}} with N of 2 or more is fine. Looks like some sort of dependency problem. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 21:06:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 21:06:49 -0000 Subject: [GHC] #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name Message-ID: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name -------------------------------------+------------------------------------- Reporter: ony | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: driver/recomp011 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Some linux systems may use target-prefixed names for `binutils`. For example on my Exherbo Linux readelf is named as `x86_64-pc-linux-gnu- readelf`. This leads to errors like: > readelf: createProcess: runInteractiveProcess: exec: does not exist (No such file or directory) To fix this GHC needs to give ability to configure name of this tool (like `SysTools.runSplit` and `SysTools.runCc`) or use `libelf`-like library. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 21:08:22 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 21:08:22 -0000 Subject: [GHC] #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name In-Reply-To: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> References: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> Message-ID: <057.c6473104662a136165405842ee73527c@haskell.org> #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name -------------------------------------+------------------------------------- Reporter: ony | Owner: Type: bug | 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: | driver/recomp011 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ony): * status: new => patch Comment: See arc diff for this: https://phabricator.haskell.org/D1326 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 21:12:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 21:12:11 -0000 Subject: [GHC] #10149: The argument of mask does not always restore the masking state In-Reply-To: <056.a022411c5d769cb0ad858891d8d4fe85@haskell.org> References: <056.a022411c5d769cb0ad858891d8d4fe85@haskell.org> Message-ID: <071.d2255e856878a0501597c00d92c71ac9@haskell.org> #10149: The argument of mask does not always restore the masking state -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.11 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:D1327 Wiki Page: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * owner: => facundo.dominguez * differential: => Phab:D1327 * version: 7.8.4 => 7.11 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 21:12:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 21:12:25 -0000 Subject: [GHC] #10149: The argument of mask does not always restore the masking state In-Reply-To: <056.a022411c5d769cb0ad858891d8d4fe85@haskell.org> References: <056.a022411c5d769cb0ad858891d8d4fe85@haskell.org> Message-ID: <071.ed29f9c67b2cba57c9fcded0a41cfc88@haskell.org> #10149: The argument of mask does not always restore the masking state -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.11 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:D1327 Wiki Page: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 21:45:26 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 21:45:26 -0000 Subject: [GHC] #10967: Release a new stm package on Hackage In-Reply-To: <048.5f8e847ed74659a561fb4c92223590be@haskell.org> References: <048.5f8e847ed74659a561fb4c92223590be@haskell.org> Message-ID: <063.c1cbe7ea0463120666252bd872e91c46@haskell.org> #10967: Release a new stm package on Hackage -------------------------------------+------------------------------------- Reporter: svenpanne | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: libraries | Version: (other) | 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: | -------------------------------------+------------------------------------- Changes (by hvr): * owner: => hvr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 21:54:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 21:54:31 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.2a93b9a971bc9c1576757c87fd84c16d@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1259 Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): Unfortunately the rules don't seem to fire in the right order. The key step appears to be when we get to the following state. {{{ boo = build (\ @ b_aog -> unpackFoldrCString# "foo"#) lvl_spB = \ @ b_aot c_aou n_aov -> foldr c_aou n_aov boo foo = \ x_anI -> augment lvl_spB x_anI }}} At this point, I would want `fold/build` to fire on `lvl_spB`, giving us {{{ lvl_spB = \ @ b_aot c_aou n_aov -> unpackFoldrCString# "foo"# c_aou n_aov }}} followed by `unpack-append` on `foo`, which would finally give us {{{ foo = \ x_anI -> unpackAppendCString# "foo"# x_anI }}} But instead `foldr/app` fires, collapsing `foo` back into a use of `++`. If I add a special rule for `++` on strings {{{ {-# RULES "++-string" forall xs ys. unpackCString# xs ++ ys = unpackAppendCString# xs ys #-} }}} I can coax GHC into generating the same Core as on master, but this is not very satisfying. It seems like we already have all of the necessary rules available. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 15 23:05:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Oct 2015 23:05:10 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.b80eeda40ea066e675e0bc5143c539b6@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1259 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Why doeesn't `foldr/build` fire? Becuase `build` isn't CONLIKE. You want `cheapBuild`; see #7206. It's parked there, because it wasn't always a win; but you could use it for this narrower case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 01:18:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 01:18:34 -0000 Subject: [GHC] #10888: ghci crashes In-Reply-To: <048.cd08c1c66af702cf9c35bbada74b978c@haskell.org> References: <048.cd08c1c66af702cf9c35bbada74b978c@haskell.org> Message-ID: <063.2442daeab337a892e1449c84791b735e@haskell.org> #10888: ghci crashes -------------------------------+------------------------------ Reporter: parsifal9 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+------------------------------ Changes (by erikd): * status: new => closed * resolution: => duplicate Comment: This is *definitely* a dupe of #10375 which has been fixed in git HEAD and will almost certainly be in any 7.10.3 release. Closing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 01:19:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 01:19:35 -0000 Subject: [GHC] #10633: GHCi segfaults on arm In-Reply-To: <045.ce30a9b63cbcf433a0315ff9f9caf317@haskell.org> References: <045.ce30a9b63cbcf433a0315ff9f9caf317@haskell.org> Message-ID: <060.49cbf5db12b3f214eca11d0fd3c336e5@haskell.org> #10633: GHCi segfaults on arm -------------------------------+------------------------------ Reporter: Thra11 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+------------------------------ Changes (by erikd): * status: new => closed * resolution: => duplicate Comment: This is *definitely* a dupe of #10375 which has been fixed in git HEAD and will almost certainly be in any 7.10.3 release. Closing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 01:23:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 01:23:35 -0000 Subject: [GHC] #8652: Cross-compiling broken for ARM/Linux target In-Reply-To: <046.33a5a63859df99c4c61a0ea3e5b20d78@haskell.org> References: <046.33a5a63859df99c4c61a0ea3e5b20d78@haskell.org> Message-ID: <061.50ae41042c52e4bcbfa175ba2cb35a8e@haskell.org> #8652: Cross-compiling broken for ARM/Linux target ----------------------------------------+------------------------------ Reporter: kgardas | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | 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 erikd): * status: new => closed * resolution: => fixed Comment: This is fixed both in the master branch (7.11) and the current stable release branch (7.10). Closing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 01:27:37 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 01:27:37 -0000 Subject: [GHC] #10975: At program exit, finalizer runs while foreign function is running Message-ID: <043.458893037bebf4938faaf143f16800cc@haskell.org> #10975: At program exit, finalizer runs while foreign function is running -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | 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: -------------------------------------+------------------------------------- The following code prints "finalized", which means the finalizer runs while the "call" function is still running. Steps to reproduce: {{{ % ghc finalizer.hs foreign.c -threaded % ./finalizer }}} finalizer.hs: {{{#!hs import Control.Concurrent import Control.Monad import Foreign.C.Types import Foreign.ForeignPtr import Foreign.Ptr main :: IO () main = do _ <- forkIO $ do fptr <- newForeignPtr finalizer nullPtr forever $ withForeignPtr fptr call threadDelay 1000000 foreign import ccall "&finalizer" finalizer :: FunPtr (Ptr CInt -> IO ()) foreign import ccall "call" call :: Ptr CInt -> IO () }}} foreign.c {{{#!c #include int finalized = 0; void finalizer(int *a) { finalized = 1; puts("finalizer"); } void call(int *a) { int i; unsigned w = 0; puts("begin call"); for(i = 0; i < 100000000; i++) { if(finalized) puts("finalized"); w += i; } printf("end call: %u\n", w); } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 01:39:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 01:39:24 -0000 Subject: [GHC] #3971: FFI callback segfaults on PPC In-Reply-To: <044.e937eb224c523ec01b4a6d9fbf68a3ed@haskell.org> References: <044.e937eb224c523ec01b4a6d9fbf68a3ed@haskell.org> Message-ID: <059.acfead586a821f88b349e5cd5546dd00@haskell.org> #3971: FFI callback segfaults on PPC -----------------------------------+------------------------------- Reporter: wkahl | Owner: Type: bug | Status: closed Priority: normal | Milestone: ? Component: Compiler (FFI) | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+------------------------------- Changes (by erikd): * status: new => closed * resolution: => fixed Comment: Just compiled and ran the `CallBacker" example on PowerPC with ghc 7.8.4 (last stable release) and ghc 7.10.2 (the current stable release). Both worked fine without any segfault. Closing this as fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 03:24:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 03:24:16 -0000 Subject: [GHC] #487: powerpc/linux segfaulting binaries In-Reply-To: <043.e4c96af6f7160fcdea6756f17c3ec89f@haskell.org> References: <043.e4c96af6f7160fcdea6756f17c3ec89f@haskell.org> Message-ID: <058.33e6c1a9e202be628ac704d150039f61@haskell.org> #487: powerpc/linux segfaulting binaries ----------------------------------+------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.4.1 Resolution: None | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------- Changes (by erikd): * cc: erikd (added) Comment: Using ghc 7.10.2 (patched with two recent fixes from git HEAD) on powerpc/linux, I just set up a cabal sandbox and after installing required C libraries was able to do `cabal install yi` and then actually run it. I didn't do any serious editing with it, but it ran without a problem. I'm going to test this again with either the 7.10.3 release (if it happens) or the 8.0 release and then close it if all is still good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 03:26:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 03:26:04 -0000 Subject: [GHC] #487: powerpc/linux segfaulting binaries In-Reply-To: <043.e4c96af6f7160fcdea6756f17c3ec89f@haskell.org> References: <043.e4c96af6f7160fcdea6756f17c3ec89f@haskell.org> Message-ID: <058.4aeb8e6cd0551925d16103dff9bfdc0e@haskell.org> #487: powerpc/linux segfaulting binaries ----------------------------------+------------------------------- Reporter: dons | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.4.1 Resolution: None | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime crash | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------- Changes (by erikd): * owner: => erikd -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 03:54:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 03:54:07 -0000 Subject: [GHC] #10971: ExtendedDefaultRules defaults to [] for Foldable/Traversable In-Reply-To: <045.2898b5f70867473328360d4f8d9156ac@haskell.org> References: <045.2898b5f70867473328360d4f8d9156ac@haskell.org> Message-ID: <060.5489a0f912c57b43d0b48d49ba9c832e@haskell.org> #10971: ExtendedDefaultRules defaults to [] for Foldable/Traversable -------------------------------------+------------------------------------- Reporter: kanetw | Owner: kanetw Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10963 | Differential Rev(s): phab:D1329 Wiki Page: | -------------------------------------+------------------------------------- Changes (by kanetw): * status: new => patch * differential: => phab:D1329 Comment: I implemented this a bit differently from what goldfire lined out. There's still just a single default list, but it accepts any kind now instead of only OpenKind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 03:54:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 03:54:29 -0000 Subject: [GHC] #10972: Add a :binfo (beginner info) GHCi command In-Reply-To: <045.69c25027f6e9192e0896957840c11b0e@haskell.org> References: <045.69c25027f6e9192e0896957840c11b0e@haskell.org> Message-ID: <060.b722b1d5a8706910ed1611425926660d@haskell.org> #10972: Add a :binfo (beginner info) GHCi command -------------------------------------+------------------------------------- Reporter: kanetw | Owner: kanetw Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kanetw): * owner: => kanetw -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 04:18:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 04:18:21 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.ed3e4a565065f215a32c3ad77b13b6c1@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1259 Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): Thanks, that makes sense. After adding the `cheapBuild` patch (only for string literals) I'm finally seeing a nice win on binary sizes. Unfortunately it comes at the cost of runtime performance, which seems like the wrong tradeoff; I'd rather have larger binaries if they run faster. Here's a selection of the more interesting summary results from nofib. I haven't had a chance to investigate where the performance loss is coming from. {{{ NoFib Results -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- atom -1.0% 0.0% +0.9% +1.6% 0.0% binary-trees -0.9% -0.0% +9.4% +9.2% 0.0% bspt -1.0% -0.3% 0.004 0.013 -33.3% cacheprof -1.9% +2.0% -1.3% -1.8% +0.9% circsim -1.0% +0.0% +4.9% +5.1% 0.0% constraints -1.0% 0.0% +0.9% +1.1% 0.0% cryptarithm1 -1.0% 0.0% +6.5% +7.7% 0.0% cse -1.0% +1.4% 0.000 0.008 0.0% fannkuch-redux -1.0% 0.0% +3.0% +3.1% 0.0% fibheaps +12.2% -0.0% 0.017 0.025 0.0% fish -1.0% +3.1% 0.006 0.014 0.0% hidden -1.0% +0.0% +1.5% +1.7% 0.0% integer -1.0% 0.0% +1.7% +2.0% 0.0% k-nucleotide -0.9% -0.0% +2.7% +2.9% 0.0% lcss -1.0% 0.0% -0.9% -2.1% 0.0% power -0.9% +0.0% -4.1% -3.7% 0.0% scs -0.7% +0.1% +1.3% +0.8% 0.0% -------------------------------------------------------------------------------- Min -1.9% -2.0% -4.1% -3.7% -33.3% Max +12.2% +3.5% +9.4% +9.2% +0.9% Geometric Mean -0.9% +0.1% +1.4% +1.4% -0.4% }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 04:23:36 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 04:23:36 -0000 Subject: [GHC] #2031: relocation overflow In-Reply-To: <045.02b5c8981d759aa3391df46bf05998bf@haskell.org> References: <045.02b5c8981d759aa3391df46bf05998bf@haskell.org> Message-ID: <060.6fe98189f12f06e06c473a4ffc7556eb@haskell.org> #2031: relocation overflow ---------------------------------+------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------- Comment (by erikd): Is there still any interest in OS X on PowerPC? If so, what version of GHC are you using? Have you tried compiling GHC from the git 7.10 branch? There have been two fixes for powerpc (testing on Linux only) in the last year or so that work around these relocation issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 04:28:44 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 04:28:44 -0000 Subject: [GHC] #2031: relocation overflow In-Reply-To: <045.02b5c8981d759aa3391df46bf05998bf@haskell.org> References: <045.02b5c8981d759aa3391df46bf05998bf@haskell.org> Message-ID: <060.36bff9090a613a6f22ffe98b73d59fbe@haskell.org> #2031: relocation overflow ---------------------------------+------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 04:32:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 04:32:04 -0000 Subject: [GHC] #10882: Fix target triple for Arm In-Reply-To: <044.1d80e9fba68d0b423d46d5881d8a4187@haskell.org> References: <044.1d80e9fba68d0b423d46d5881d8a4187@haskell.org> Message-ID: <059.07f663520ab262b8295d2a4b4edd188b@haskell.org> #10882: Fix target triple for Arm ---------------------------------+------------------------------ Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7608 | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Changes (by erikd): * status: new => closed * resolution: => fixed Comment: This was fixed as part of #10375 with commit [changeset:"933adc0f31164cb651d11ecfcfe612ac429f714f/ghc" 933adc0f/ghc]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 05:16:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 05:16:11 -0000 Subject: [GHC] #10976: Applicative Comprehensions Message-ID: <046.b8fb42a1a67c05a5fd3b2ee681f1abcf@haskell.org> #10976: Applicative Comprehensions -------------------------------------+------------------------------------- Reporter: davidar | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: 8914 | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As discussed on `ghc-devs`, when both the `MonadComprehensions` and `ApplicativeDo` language extensions are enabled, it should be possible to use comprehension-notation (in addition to do-notation) for `Applicative`s. This would allow, for example, an expression like {{{#!hs (\x y -> x + 2*y) <$> ZipList [1..10] <*> ZipList [10,20..100] }}} to also be written as {{{#!hs [ x + 2*y | x <- ZipList [1..10], y <- ZipList [10,20..100] ] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 05:53:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 05:53:34 -0000 Subject: [GHC] #10977: Arm: Undeclared indentifier when build un-registerised Message-ID: <044.6f776c6ca9f62f7cf566b935a2800cb2@haskell.org> #10977: Arm: Undeclared indentifier when build un-registerised ----------------------------------+---------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: rts linker | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------+---------------------------------------- I have a Jenkins job which builds un-registerised on armhf and just got this: {{{ rts/Linker.c:6209:21: error: error: ?target_shndx? undeclared (first use in this function) if (oc->sections[target_shndx].kind == SECTIONKIND_OTHER) { ^ rts/Linker.c:6209:21: error: note: each undeclared identifier is reported only once for each function it appears in `gcc' failed in phase `C Compiler'. (Exit code: 1) }}} Seems this is a result of 04e8366608 and the fix is pretty obvious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 06:42:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 06:42:26 -0000 Subject: [GHC] #10977: Arm: Undeclared indentifier when build un-registerised In-Reply-To: <044.6f776c6ca9f62f7cf566b935a2800cb2@haskell.org> References: <044.6f776c6ca9f62f7cf566b935a2800cb2@haskell.org> Message-ID: <059.9329b92e4b84c2dfc32ee4e29b1e82ec@haskell.org> #10977: Arm: Undeclared indentifier when build un-registerised ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: rts linker Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+---------------------------------- Comment (by erikd): This problem is really easy to fix by pulling: {{{#!C int target_shndx = shdr[shnum].sh_info; }}} out of the `#ifdef`, but that just fixes the most obvious and immediate problem. The real problem is the heavy usage of `#ifdef` in this file. For instance, I cannot figure out why in this line {{{ #if defined(DEBUG) || defined(sparc_HOST_ARCH) || defined(ia64_HOST_ARCH) || \ defined(powerpc_HOST_ARCH) || defined(x86_64_HOST_ARCH) }}} Sparc, Ia64, PowerPC and x86_64 are all included, but i386, Arm and PowerPC64 are not. Furthermore, when someone is working on a new architecture like AArch64, how are they supposed to know whether it should be part of this magical set or not? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 07:12:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 07:12:33 -0000 Subject: [GHC] #10977: Arm: Undeclared indentifier when compiling rts/Linker.c (was: Arm: Undeclared indentifier when build un-registerised) In-Reply-To: <044.6f776c6ca9f62f7cf566b935a2800cb2@haskell.org> References: <044.6f776c6ca9f62f7cf566b935a2800cb2@haskell.org> Message-ID: <059.1d678486bcca9d1ea1cf6c15e1ec3981@haskell.org> #10977: Arm: Undeclared indentifier when compiling rts/Linker.c ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: rts linker Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+---------------------------------- Description changed by erikd: Old description: > I have a Jenkins job which builds un-registerised on armhf and just got > this: > > {{{ > rts/Linker.c:6209:21: error: > error: ?target_shndx? undeclared (first use in this function) > if (oc->sections[target_shndx].kind == SECTIONKIND_OTHER) { > ^ > > rts/Linker.c:6209:21: error: > note: each undeclared identifier is reported only once for each > function it appears in > `gcc' failed in phase `C Compiler'. (Exit code: 1) > }}} > > Seems this is a result of 04e8366608 and the fix is pretty obvious. New description: I have a Jenkins job which builds GHC on armhf and just got this: {{{ rts/Linker.c:6209:21: error: error: ?target_shndx? undeclared (first use in this function) if (oc->sections[target_shndx].kind == SECTIONKIND_OTHER) { ^ rts/Linker.c:6209:21: error: note: each undeclared identifier is reported only once for each function it appears in `gcc' failed in phase `C Compiler'. (Exit code: 1) }}} Seems this is a result of 04e8366608 and the fix is pretty obvious. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 07:15:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 07:15:46 -0000 Subject: [GHC] #10977: Arm: Undeclared indentifier when compiling rts/Linker.c In-Reply-To: <044.6f776c6ca9f62f7cf566b935a2800cb2@haskell.org> References: <044.6f776c6ca9f62f7cf566b935a2800cb2@haskell.org> Message-ID: <059.e0246b1bf62ccdb949f17a88fe26b615@haskell.org> #10977: Arm: Undeclared indentifier when compiling rts/Linker.c ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: rts linker Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1330 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by erikd): * differential: => Phab:D1330 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 07:56:37 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 07:56:37 -0000 Subject: [GHC] #10966: dirtiness checking isn't keeping track of which source file contained Main In-Reply-To: <044.5fcdeb9071ae79d9f9b6bcbc72d714db@haskell.org> References: <044.5fcdeb9071ae79d9f9b6bcbc72d714db@haskell.org> Message-ID: <059.abc89754327462725a69d8b301e6eb7d@haskell.org> #10966: dirtiness checking isn't keeping track of which source file contained Main -------------------------------------+------------------------------------- Reporter: gueux | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): In `compiler/main/DriverPipeline.hs`: {{{ linkingNeeded :: DynFlags -> Bool -> [Linkable] -> [UnitId] -> IO Bool linkingNeeded dflags staticLink linkables pkg_deps = do -- if the modification time on the executable is later than the -- modification times on all of the objects and libraries, then omit -- linking (unless the -fforce-recomp flag was given). ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 08:04:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 08:04:30 -0000 Subject: [GHC] #10871: Implement "fat" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.883d645b8a2aea86024c9f0cf101b8d0@haskell.org> #10871: Implement "fat" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: 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): Yes ok, I agree that you could do this and retain the property that cabal- install is deterministic. However, since you also need to support building from source (because the user could just delete the package database and get the same results) isn't this scheme just a very elaborate way to avoid re-typechecking things in some cases? That is, it doesn't add any new functionality, it just saves repeated work. Does this feature pay its way? It's still not clear to me. It feels like something we would have to consider in lots of places, like `hs-boot` files, a kind of tax on people who want to write build systems and tools that work with packages. I wouldn't be surprised if there were tricky technical problems with implementing it fully too. What about core-to-core compiler plugins? What is the equivalent of `ghc -M` for fat interface files? This would mean that we couldn't have C code in a package that depends on something provided by a hole too. Maybe you don't want to support that use case, but given that without fat interfaces it would "just work", it seems a shame to lose it. Essentially I suppose I worry about losing the simple compilation model that we currently have in the name of saving some time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 08:12:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 08:12:33 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.72912238be925d499bd23244bf424fb4@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1259 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): * Investigate carefully before trusting the nofib runtimes. They can wobble around a lot; you really need criterion and nofib doesn't use that. eg It's very unusual to see a genuine 9% increase in runtime with zero change in allocation on a program that is not spending a lot of time in non-allocating numeric loops. * Why is allocation going up? That's unexpected. * The fibheaps binary size is also a surprise. 12% is a lot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 08:24:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 08:24:23 -0000 Subject: [GHC] #10871: Implement "fat" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.a48f9f872e70c15260b281e54f8df933@haskell.org> #10871: Implement "fat" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: 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): Edward can correct me but I think it's about more than time/efficiency. To start again from source you need to have all your import paths, CPP settings, etc etc recorded so that you can replay them. You need to copy all the source files, including any C bits, into the installation tree. There's a LOT of front-end stuff to worry about. But this way all that is gone. We simply have Core; and any C bits are compiled to .o files. Nice! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 08:44:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 08:44:46 -0000 Subject: [GHC] #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name In-Reply-To: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> References: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> Message-ID: <057.a0dbd915d916d2671f34dc72d5ae5abc@haskell.org> #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name -------------------------------------+------------------------------------- Reporter: ony | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | driver/recomp011 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1326 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * differential: => Phab:D1326 * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 08:45:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 08:45:00 -0000 Subject: [GHC] #10977: Arm: Undeclared indentifier when compiling rts/Linker.c In-Reply-To: <044.6f776c6ca9f62f7cf566b935a2800cb2@haskell.org> References: <044.6f776c6ca9f62f7cf566b935a2800cb2@haskell.org> Message-ID: <059.e88e8f8d7a1c564147791ddbd708ad8e@haskell.org> #10977: Arm: Undeclared indentifier when compiling rts/Linker.c ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: rts linker Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1330 Wiki Page: | ----------------------------------------+---------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"4d6844a54f1fc72b3ba31f1b6e09991add816875/ghc" 4d6844a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4d6844a54f1fc72b3ba31f1b6e09991add816875" rts/Linker.c : Fix armhf build (#10977) Test Plan: Validate on x86_64, PowerPC and Arm Reviewers: simonmar, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1330 GHC Trac Issues: #10977 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 09:09:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 09:09:08 -0000 Subject: [GHC] #10977: Arm: Undeclared indentifier when compiling rts/Linker.c In-Reply-To: <044.6f776c6ca9f62f7cf566b935a2800cb2@haskell.org> References: <044.6f776c6ca9f62f7cf566b935a2800cb2@haskell.org> Message-ID: <059.0e9628658d85cedef05c011815d24cad@haskell.org> #10977: Arm: Undeclared indentifier when compiling rts/Linker.c ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: rts linker Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1330 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by erikd): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 09:27:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 09:27:57 -0000 Subject: [GHC] #9297: Packages linked against certain Windows .dll files give warnings at runtime In-Reply-To: <050.15e3ebd6026e8054e922a0058e2d13ac@haskell.org> References: <050.15e3ebd6026e8054e922a0058e2d13ac@haskell.org> Message-ID: <065.f16322c5e0f17c5dba2d7418cf135569@haskell.org> #9297: Packages linked against certain Windows .dll files give warnings at runtime -----------------------------------+-------------------------------------- Reporter: RyanGlScott | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2283, #9218 | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Changes (by lukexi): * priority: normal => high * milestone: => 7.10.3 Comment: Austin turned this into a DEBUG message here: https://github.com/ghc/ghc/commit/54b7dc5537f8b871e655752bace1ad6f5e6fe89a This is definitely a super important patch for 7.10.3 as it currently makes it nearly impossible to see errors and generally makes using GHC extremely painful. I was going to paste an example from my daily life but it felt too mean to pass on, as there were over *250 lines* of these warnings : ). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 11:07:20 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 11:07:20 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.c4ddd9ad495f34718efa9398d67a2401@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1259 Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): Ok, will do. The fibheaps increase is also interesting, yes. There's a bit more to it, actually. I had to add `-package array` to the fibheaps makefile because I was getting a linker error about undefined symbols from Data.Array.Base. This is not too surprising since the point of this whole thing is to prevent strings and callstacks from being inlined across modules. In this particular case, the undefined symbol was a callstack used in an error call in Data.Array.Base. But it does force us to link against array, which we weren't doing before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 11:57:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 11:57:21 -0000 Subject: [GHC] #10871: Implement "fat" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.f8c7bc58783589201b667c288a8b52c4@haskell.org> #10871: Implement "fat" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: 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 completely agree that we shouldn't save source files and try to replay compilation from there - indeed I'm suggesting that we shouldn't record/replay anything at all, and just start from the cabal source packages each time we need to compile or typecheck. Maybe a simple example will help focus this discussion. Imagine we have packages A and B, where A has a B-shaped hole. We can do {{{ cabal install A }}} which just typechecks A, and we can do {{{ cabal install A B }}} which compiles A and B. Now, "cabal install A B" must work and produce the same results regardless of whether we previously did "cabal install A", because cabal is just a function from source packages to compiled packages. So the only thing we can do in response to "cabal install A" is to cache something that might be useful later, which is what the fat interface files are: they let us avoid some of the work that we will need to do in a future "cabal install A B" for any B. Since we have to support "cabal install A B" without a previous "cabal install A", there's no new functionality in saving fat interfaces. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 13:50:42 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 13:50:42 -0000 Subject: [GHC] #10971: ExtendedDefaultRules defaults to [] for Foldable/Traversable In-Reply-To: <045.2898b5f70867473328360d4f8d9156ac@haskell.org> References: <045.2898b5f70867473328360d4f8d9156ac@haskell.org> Message-ID: <060.a9cb0b6e983b3042b6d977d29f11d86b@haskell.org> #10971: ExtendedDefaultRules defaults to [] for Foldable/Traversable -------------------------------------+------------------------------------- Reporter: kanetw | Owner: kanetw Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10963 | Differential Rev(s): phab:D1329 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I find it a little counterintuitive to have one defaulting list have types of several different kinds in it. For example, `default (), []` is accepted, and has the exact same meaning as `default [], ()`. I'd much prefer separating these out. But I won't make a big deal of it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 14:40:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 14:40:07 -0000 Subject: [GHC] #10971: ExtendedDefaultRules defaults to [] for Foldable/Traversable In-Reply-To: <045.2898b5f70867473328360d4f8d9156ac@haskell.org> References: <045.2898b5f70867473328360d4f8d9156ac@haskell.org> Message-ID: <060.eae4f86b44cbfffb239d4be53431488c@haskell.org> #10971: ExtendedDefaultRules defaults to [] for Foldable/Traversable -------------------------------------+------------------------------------- Reporter: kanetw | Owner: kanetw Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10963 | Differential Rev(s): phab:D1329 Wiki Page: | -------------------------------------+------------------------------------- Comment (by kanetw): The reason for having one list is because if we ever implement something like #8171 it'd be much more effort to make it polykinded when using multiple defaulting lists. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 14:45:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 14:45:34 -0000 Subject: [GHC] #10978: Anonymous type instances Message-ID: <055.a75284347356e36c699df8487033f1c9@haskell.org> #10978: Anonymous type instances -------------------------------------+------------------------------------- Reporter: | Owner: benjamin.hodgson | Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I find that commonly I write a `type family` (because it doesn't ''need'' to be a `data family`, and `type` families are more flexible), but I find myself writing `data` types for some of the instances anyway. Presently you're forced to use type synonyms for all the instances of a `type family`, even if you don't intend to refer to the type by any name other than that of the type family. I find this tiresome: {{{#!hs type family F a type instance F Char = Int newtype FBool = FBool Int type instance F Bool = FBool data FInt = A | B | ... type instance F Int = FInt }}} '''I want to write `data instance`s and `newtype instance`s for `type` families'''. These proposed constructs would introduce a new type without a name of its own (the only way to refer to it would be through the `type family`), just like the current design of `data` families. The above code would be roughly equivalent to: {{{#!hs type family F a type instance F Char = Int -- already legal newtype instance F Bool = FBool Int data instance F Int = A | B | ... }}} I call this idea ''anonymous type instances'' but I'm open to suggestions for a snappier name. Going the other way (writing a `type instance` for a `data family`) would remain illegal under this proposal. {{{#!hs data family G a type instance G Char = Int -- still illegal }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 14:46:13 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 14:46:13 -0000 Subject: [GHC] #10978: Anonymous type instances In-Reply-To: <055.a75284347356e36c699df8487033f1c9@haskell.org> References: <055.a75284347356e36c699df8487033f1c9@haskell.org> Message-ID: <070.6f9c21022221ffeedcf1b88135430c47@haskell.org> #10978: Anonymous type instances -------------------------------------+------------------------------------- Reporter: benjamin.hodgson | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 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 benjamin.hodgson): * version: 7.10.2 => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 14:49:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 14:49:18 -0000 Subject: [GHC] #10971: ExtendedDefaultRules defaults to [] for Foldable/Traversable In-Reply-To: <045.2898b5f70867473328360d4f8d9156ac@haskell.org> References: <045.2898b5f70867473328360d4f8d9156ac@haskell.org> Message-ID: <060.37305ccd510f7117d7bd36cb266a9ced@haskell.org> #10971: ExtendedDefaultRules defaults to [] for Foldable/Traversable -------------------------------------+------------------------------------- Reporter: kanetw | Owner: kanetw Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10963 | Differential Rev(s): phab:D1329 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I really don't want two lists! I think it's ok as-is; but it might help to add a bit more explanatory text in the user manual. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 14:50:37 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 14:50:37 -0000 Subject: [GHC] #10971: ExtendedDefaultRules defaults to [] for Foldable/Traversable In-Reply-To: <045.2898b5f70867473328360d4f8d9156ac@haskell.org> References: <045.2898b5f70867473328360d4f8d9156ac@haskell.org> Message-ID: <060.be11ecd36a02483744c1c8ec3ac3eac0@haskell.org> #10971: ExtendedDefaultRules defaults to [] for Foldable/Traversable -------------------------------------+------------------------------------- Reporter: kanetw | Owner: kanetw Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10963 | Differential Rev(s): phab:D1329 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Also, this implementation would seem to accept `default Either`, which is utterly meaningless, as `Either` has a non-defaultable kind. This is also utterly harmless, but it makes me suspicious of the design. It would not be utterly meaningless if we added some new type class of kind `(* -> * -> *) -> Constraint`, and wanted defaulting to work on it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 14:57:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 14:57:28 -0000 Subject: [GHC] #10978: Anonymous type instances In-Reply-To: <055.a75284347356e36c699df8487033f1c9@haskell.org> References: <055.a75284347356e36c699df8487033f1c9@haskell.org> Message-ID: <070.65bf37b3e6b89605d165096129010931@haskell.org> #10978: Anonymous type instances -------------------------------------+------------------------------------- Reporter: benjamin.hodgson | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I don't see any structural problems with this proposal, but I think it doesn't pay its way. It would be yet another wrinkle to already-quite- complex type family story. And, I think more problematically, this approach would prohibit you to write class instances for these new datatypes. Because type families are not injective and generative, you cannot specify a type family in a class instance head. But with these "anonymous type instances", there would be no other way to name the datatype, so you've effectively made datatypes for which no instances can exist. (Except maybe by `deriving`. But you'd even be prohibited from standalone-deriving.) So I'm skeptical, even though I do think the underlying idea is sound. If you really want this, find a loud chorus of people who think likewise. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 14:59:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 14:59:24 -0000 Subject: [GHC] #10971: ExtendedDefaultRules defaults to [] for Foldable/Traversable In-Reply-To: <045.2898b5f70867473328360d4f8d9156ac@haskell.org> References: <045.2898b5f70867473328360d4f8d9156ac@haskell.org> Message-ID: <060.07de068d8ddaad69dc6c4e991641520d@haskell.org> #10971: ExtendedDefaultRules defaults to [] for Foldable/Traversable -------------------------------------+------------------------------------- Reporter: kanetw | Owner: kanetw Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10963 | Differential Rev(s): phab:D1329 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:6 simonpj]: > > Also, this implementation would seem to accept `default Either`, which is utterly meaningless, as `Either` has a non-defaultable kind. This is also utterly harmless, but it makes me suspicious of the design. > > It would not be utterly meaningless if we added some new type class of kind `(* -> * -> *) -> Constraint`, and wanted defaulting to work on it. > > Simon That's true. But we have no such classes with defaulting yet, and it would take a change to the compiler to make it so. But, I've heard a loud enough chorus of voices asking for just one list (including some on IRC). And I think KaneTW's argument in comment:4 is convincing. I stand down. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 15:28:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 15:28:09 -0000 Subject: [GHC] #10978: Anonymous type instances In-Reply-To: <055.a75284347356e36c699df8487033f1c9@haskell.org> References: <055.a75284347356e36c699df8487033f1c9@haskell.org> Message-ID: <070.935abd03cbd34475c7fc6ec70578de15@haskell.org> #10978: Anonymous type instances -------------------------------------+------------------------------------- Reporter: benjamin.hodgson | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 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 nomeata): > Because type families are not injective and generative, you cannot specify a type family in a class instance head. Would it be possible to allow type families in instance heads if they reduce to something that is allowed, akin to `TypeSynonymInstances`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 15:36:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 15:36:48 -0000 Subject: [GHC] #10979: Phab linter trips on ReStructuredText formatting Message-ID: <048.cf2d4e0a4200f704b93b86b6983cd451@haskell.org> #10979: Phab linter trips on ReStructuredText formatting -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I made changes to the User's Guide and now Phab linter complains: {{{ >>> Lint for docs/users_guide/glasgow_exts.rst: Error (MERGECONFLICT1) Unresolved merge conflict This syntax indicates there is an unresolved merge conflict. 10555 .. _pragmas: 10556 10557 Pragmas >>> 10558 ======= 10559 10560 .. index:: 10561 single: pragma LINT ERRORS Lint raised errors! Lint issued unresolved errors! Provide explanation to continue or press Enter to abort. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 15:39:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 15:39:35 -0000 Subject: [GHC] #910: --make should have a -j flag for parallel building In-Reply-To: <044.71389d84cf1d08cc9be1b6b2f82c78b7@haskell.org> References: <044.71389d84cf1d08cc9be1b6b2f82c78b7@haskell.org> Message-ID: <059.76429007ad0203056393d14d4c754b79@haskell.org> #910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: closed Priority: normal | Milestone: ? Component: Compiler | Version: 6.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: 8184, 8235 | Blocking: Related Tickets: #9221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rrnewton): I want to raise one more issue on this topic. Nowadays most people implicitly call ghc under layers of tooling (stack, cabal, ghc-mod, haskell-mode, etc). For example, with stack, at this particular moment in time I can't find a place to stick `-j3` such that all my builds on a machine will see it. This question of internal parallelism is an internal implementation issue, and shouldn't change semantics. Thus I think it would be safe for it to be optionally controlled by an environment variable. If I could just set "GHC_MAKE_CORES=3" on a given system, then I could get the desired behavior irrespective of what tools I'm using on top of GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 16:07:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 16:07:15 -0000 Subject: [GHC] #10978: Anonymous type instances In-Reply-To: <055.a75284347356e36c699df8487033f1c9@haskell.org> References: <055.a75284347356e36c699df8487033f1c9@haskell.org> Message-ID: <070.edb3d5b125e8b4db8cd7737f4e960e2c@haskell.org> #10978: Anonymous type instances -------------------------------------+------------------------------------- Reporter: benjamin.hodgson | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:3 nomeata]: > > Because type families are not injective and generative, you cannot specify a type family in a class instance head. > > Would it be possible to allow type families in instance heads if they reduce to something that is allowed, akin to `TypeSynonymInstances`? This has been suggested before but was discarded as a bad idea. There's some useful conversation on the ticket... but I can't find the ticket! Short story: this would be akin to allowing term-level function definitions like `foo (not True) = 5`. If we reduce `not True`, we'll get `False`, and this definition is perfectly sound. But it's terrible, nonetheless. If you could find the ticket, I'd be grateful. But I really did try. :( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 16:56:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 16:56:31 -0000 Subject: [GHC] #910: --make should have a -j flag for parallel building In-Reply-To: <044.71389d84cf1d08cc9be1b6b2f82c78b7@haskell.org> References: <044.71389d84cf1d08cc9be1b6b2f82c78b7@haskell.org> Message-ID: <059.a30e66ac32d1f3e5a86695ecb6f92a6d@haskell.org> #910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: closed Priority: normal | Milestone: ? Component: Compiler | Version: 6.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: 8184, 8235 | Blocking: Related Tickets: #9221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): @rrnewton: That may or may not be a good idea - since tools like stack already do a `-j` on the package level, it seems that the best results can be achieved if such tools are aware of GHC's `-j` and use it correctly (e.g. you'd probably not want full `-j` for both stack and GHC as that would give you N*N threads and a lot of overhead) - so it may be worth more pushing for these tools to use GHC's `-j`. Also, if there was a `GHC_MAKE_CORES` env var, and `-j` was also given, which one would take precedence? To answer one of your questions directly, most of these tools accept a `--ghc-options` flag, e.g. you can do `stack build --ghc-options="-j4"`. I think another reason why not all tools use `ghc -j` is because of #9221. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 18:02:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 18:02:53 -0000 Subject: [GHC] #10871: Implement "fat" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.1229a86072c7d9cbc3520371167ea646@haskell.org> #10871: Implement "fat" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Aha! SM, your latest comment pinpointed a misunderstanding. You said that "cabal install A B" must work whether or not "cabal install A" was done previously, thus fat interface files are not necessary. But in fact, even in the case of "cabal install A B", we use fat interfaces to compile an instantiated version of A: you will have to compile to a fat interface first, and THEN finish instantiating and finishing the compilation. Why is it set up this way? There were a confluence of reasons that pushed us in this direction: 1. We want GHC(i) to be able to compile Backpack code directly, without requiring Cabal in the loop. 2. Conversely, we don't want to bake Backpack support into cabal-install; if we do, then alternate package managers like Stack also have to port their own support. (A cabal-install which knows, in "cabal install A B", that A is instantiated with B, knows too much about Backpack for its own good!) 3. We always need to typecheck A by itself *anyway*, because it may be ill-typed in a way that you won't discover when you instantiate it. The canonical example is: {{{ unit A where signature A where data T = T signature B where data T module M where import qualified A import qualified B x = A.T :: B.T }}} A shouldn't type-check, because there is no reason to believe A.T and B.T are the same type. But if B implements A and B with the same T, it is actually possible to compile A instantiated with B. OK, let me answer some of the other questions more directly: > It feels like something we would have to consider in lots of places, like hs-boot files, a kind of tax on people who want to write build systems and tools that work with packages. I agree, it does make things more complicated. But you never have to interact with fat interfaces unless you want to build a Backpack package: they all go away once you instantiate things. So I think the complexity here is somewhat opt-in. It's the same deal with some sort of external core format: you don't have to deal with it unless you want to generate external core or compile it. > I wouldn't be surprised if there were tricky technical problems with implementing it fully too. What about core-to-core compiler plugins? What is the equivalent of ghc -M for fat interface files? Core-to-core plugins run when compiling from hi-fat to hi; that should just work out of the box. As for ghc -M, fat interface files are "essentially" external core input files, i.e. they come with full information about their dependency structure. So you could just write ghc -M which would tell you what order to build hi-fat files in the same way you can do it for hs. (I have not implemented ghc -M, but I have implemented --make's analysis to work on fat interface fiels.) > This would mean that we couldn't have C code in a package that depends on something provided by a hole too. Maybe you don't want to support that use case, but given that without fat interfaces it would "just work", it seems a shame to lose it. We are giving this up. But I am not losing too much sleep over it; the preprocessor for the C code would already have to know how to mangle the Haskell symbols to point to the right location. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 19:11:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 19:11:33 -0000 Subject: [GHC] #10945: Typed Template Haskell splices broken in HEAD (7.11) In-Reply-To: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> References: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> Message-ID: <063.7c43908d92dd5ba41d16c3386b999a6b@haskell.org> #10945: Typed Template Haskell splices broken in HEAD (7.11) -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10945 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Jan Stolarek ): In [changeset:"75492e7467ff962f2f2e29e5c8b2c588c94ae8a7/ghc" 75492e7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="75492e7467ff962f2f2e29e5c8b2c588c94ae8a7" Add typed holes support in Template Haskell. Fixes #10267. Typed holes in typed Template Haskell currently don't work. See #10945 and #10946. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 19:11:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 19:11:33 -0000 Subject: [GHC] #10267: Add support for typed holes in Template Haskell In-Reply-To: <048.c1c64a1e465638edb9cc6eb9b5affa9b@haskell.org> References: <048.c1c64a1e465638edb9cc6eb9b5affa9b@haskell.org> Message-ID: <063.84ffd92d0e320bf878672a758d13b89b@haskell.org> #10267: Add support for typed holes in Template Haskell -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10945, #10946 | Differential Rev(s): Phab:D835 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Jan Stolarek ): In [changeset:"75492e7467ff962f2f2e29e5c8b2c588c94ae8a7/ghc" 75492e7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="75492e7467ff962f2f2e29e5c8b2c588c94ae8a7" Add typed holes support in Template Haskell. Fixes #10267. Typed holes in typed Template Haskell currently don't work. See #10945 and #10946. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 19:11:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 19:11:33 -0000 Subject: [GHC] #10946: Typed hole inside typed Template Haskell bracket causes panic In-Reply-To: <048.bb931422119631f05ab09abe14bd4c46@haskell.org> References: <048.bb931422119631f05ab09abe14bd4c46@haskell.org> Message-ID: <063.7dfee80a0a83782beec32df0f847c757@haskell.org> #10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T10946 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Jan Stolarek ): In [changeset:"75492e7467ff962f2f2e29e5c8b2c588c94ae8a7/ghc" 75492e7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="75492e7467ff962f2f2e29e5c8b2c588c94ae8a7" Add typed holes support in Template Haskell. Fixes #10267. Typed holes in typed Template Haskell currently don't work. See #10945 and #10946. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 19:13:20 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 19:13:20 -0000 Subject: [GHC] #10267: Add support for typed holes in Template Haskell In-Reply-To: <048.c1c64a1e465638edb9cc6eb9b5affa9b@haskell.org> References: <048.c1c64a1e465638edb9cc6eb9b5affa9b@haskell.org> Message-ID: <063.4e286510cd22b78e3f0dc0e2a606885e@haskell.org> #10267: Add support for typed holes in Template Haskell -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10945, #10946 | Differential Rev(s): Phab:D835 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 19:13:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 19:13:46 -0000 Subject: [GHC] #10267: Add support for typed holes in Template Haskell In-Reply-To: <048.c1c64a1e465638edb9cc6eb9b5affa9b@haskell.org> References: <048.c1c64a1e465638edb9cc6eb9b5affa9b@haskell.org> Message-ID: <063.8f2ad29142904fa7542023572a7e4989@haskell.org> #10267: Add support for typed holes in Template Haskell -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10267 Blocked By: | Blocking: Related Tickets: #10945, #10946 | Differential Rev(s): Phab:D835 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * testcase: => th/T10267 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 19:20:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 19:20:12 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDkxMTogQWxsb3cgbGVmdCDiiKggKCsrKykg?= =?utf-8?q?as_minimal_definition_of_ArrowChoice_instance?= In-Reply-To: <052.96ba61f09e40ccdfa2181da25e7d4d5b@haskell.org> References: <052.96ba61f09e40ccdfa2181da25e7d4d5b@haskell.org> Message-ID: <067.c6dc2893c3447fa938a7b17fe3d92784@haskell.org> #10911: Allow left ? (+++) as minimal definition of ArrowChoice instance -------------------------------------+------------------------------------- Reporter: mfdyck.google | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Sounds good to me. We just accepted a similar patch to the main `Arrow` type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 19:23:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 19:23:25 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDkxMTogQWxsb3cgbGVmdCDiiKggKCsrKykg?= =?utf-8?q?as_minimal_definition_of_ArrowChoice_instance?= In-Reply-To: <052.96ba61f09e40ccdfa2181da25e7d4d5b@haskell.org> References: <052.96ba61f09e40ccdfa2181da25e7d4d5b@haskell.org> Message-ID: <067.0bd04aabe4036f88dfe596d65ecfe3a5@haskell.org> #10911: Allow left ? (+++) as minimal definition of ArrowChoice instance -------------------------------------+------------------------------------- Reporter: mfdyck.google | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): The MINIMAL pragma would also be affected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 19:25:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 19:25:32 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDkxMTogQWxsb3cgbGVmdCDiiKggKCsrKykg?= =?utf-8?q?as_minimal_definition_of_ArrowChoice_instance?= In-Reply-To: <052.96ba61f09e40ccdfa2181da25e7d4d5b@haskell.org> References: <052.96ba61f09e40ccdfa2181da25e7d4d5b@haskell.org> Message-ID: <067.6dcecdd8ca21f4a1b95f81f615f0baba@haskell.org> #10911: Allow left ? (+++) as minimal definition of ArrowChoice instance -------------------------------------+------------------------------------- Reporter: mfdyck.google | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"6a8ca65032c6b3ed61b5378765e70120083cf5da/ghc" 6a8ca650/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6a8ca65032c6b3ed61b5378765e70120083cf5da" Allow left ? (+++) as minimal definition of ArrowChoice instance See #10911. Reviewers: ekmett Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 19:25:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 19:25:58 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDkxMTogQWxsb3cgbGVmdCDiiKggKCsrKykg?= =?utf-8?q?as_minimal_definition_of_ArrowChoice_instance?= In-Reply-To: <052.96ba61f09e40ccdfa2181da25e7d4d5b@haskell.org> References: <052.96ba61f09e40ccdfa2181da25e7d4d5b@haskell.org> Message-ID: <067.1b3c32fe6b2574500d18bb60623bd34b@haskell.org> #10911: Allow left ? (+++) as minimal definition of ArrowChoice instance -------------------------------------+------------------------------------- Reporter: mfdyck.google | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.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 thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 19:46:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 19:46:21 -0000 Subject: [GHC] #10871: Implement "fat" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.536e8d131db69c7ea53c97ac6f8d987f@haskell.org> #10871: Implement "fat" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: 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 was worried you were going to say that :) I'm missing some context here, e.g. I don't know what your plans are with respect to using backpack code with regular GHC(i), and how cabal-install can be ignorant to whether a package contains backpack code. Hence I don't understand how (1) and (2) force you to save fat interface files. I understand (3), but it still doesn't seem to force you to save a fat interface file. Why not typecheck first and then compile again from source? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 20:06:47 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 20:06:47 -0000 Subject: [GHC] #10973: Building git HEAD with a singe make job fails due to dependency problem In-Reply-To: <044.ce71bd5536233be44928eb09733a9711@haskell.org> References: <044.ce71bd5536233be44928eb09733a9711@haskell.org> Message-ID: <059.8ac5b56e7f786b7f67b437dc1fa7ba63@haskell.org> #10973: Building git HEAD with a singe make job fails due to dependency problem -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 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:D1333 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D1333 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 21:15:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 21:15:15 -0000 Subject: [GHC] #910: --make should have a -j flag for parallel building In-Reply-To: <044.71389d84cf1d08cc9be1b6b2f82c78b7@haskell.org> References: <044.71389d84cf1d08cc9be1b6b2f82c78b7@haskell.org> Message-ID: <059.580e669bdeee684a32386cf521c8ae2b@haskell.org> #910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: closed Priority: normal | Milestone: ? Component: Compiler | Version: 6.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: 8184, 8235 | Blocking: Related Tickets: #9221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rrnewton): For me, typical stack builds spend a huge amount of time bottlenecked on just one or two ghc compiles. Yes, we could push towards stack and other tools dynamically provisioning cores to GHC instances. But, in the short term GHC doesn't actually get decent parallel scaling anyway (#9221) so I really just want `-j2` or `-j3`. And that limited level of oversubscription I'm not very worried about (the overall builds spend so little their time with decent parallel utilization anyway). Do we have a policy for priorities of env vars versus flags in general? I think command line flags should take precedence. Then any smart tools that know how to manage "ghc -j" can override any system wide default. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 21:36:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 21:36:24 -0000 Subject: [GHC] #10871: Implement "fat" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.daaad7ab7e39adae0dc9f50c5197e199@haskell.org> #10871: Implement "fat" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Let's think about it from a user perspective. Right now, if I want to compile a simple Haskell file, I don't need to futz around with Cabal: I can just ask GHC to build it for me `ghc --make A.hs`. So we want a similar experience with Backpack: if someone writes a simple Backpack file, they should be able to build it with `ghc --backpack p.bkp`, without futzing around with Cabal. This is MUCH more important for Backpack programming "in the small" (ala ML functors and C++ templates) rather than Backpack programming "in the large" (ala replacing package dependencies). I think it's important that we get a story that works well for both cases; even though the Backpack design is highly oriented towards large-scale modularity, it is much easier to get users using the small-scale features first. (Plus, there's interesting stuff to be done with alternate syntax building on Backpack but better suited for small-scale modularity.) But we can't ask them to use Cabal for that! Re (2), how can you let cabal-install work without knowing about Backpack? If it doesn't know about Backpack units, then it can only operate as it does now: building a graph of packages (packages that use Backpack are still obligated to state, in a build-depends, what external packages they use). So when we say "cabal install A B", we mean, "install package A" and "install package B". What does it mean to install an indefinite package? Typecheck it and install the fat interface files (so we can typecheck against it). What does it mean to install a package which instantiates an indefinite package? Compile it, and also compile anything that it instantiates. With fat interfaces, GHC can manage compiling the instantiated units, since it can just resume that compilation! How about installing the resutls? If Backpack were generative, every package which instantiates indefinite units would just get their own private copy of any other units it instantiated, and together they would constitute the package you would install. Fat interface files work perfectly for this case. But since Backpack is applicative, we also want identical instantiated units to be shared. Here is where you might object, since I am cheating here, but what seems easiest is to have GHC and Cabal (but not cabal-install) conspire to deduplicate instantiated units "behind the scenes". You might say that this will work really poorly for traditional distribution package managers. If C and D both instantiate A(B), where do the "install files" for A(B) live? The only reasonable place to put them in a distro is in their own package, implying that a distro packages you'd create for packages that use Backpack would have to know about how everything is instantiated. But traditional distribution package managers (e.g. deb, rpm) already can't deal with having both foo-0.1 and foo-0.2 installed at the same time. So it's no surprise that they'll have some trouble dealing with Backpack, which subsumes this mode of use. And if you do have a distro that can deal with it (e.g. Nix), you can either bundle private copies of the instantiated copies (and rely on GHC's linker to deduplicate them later, following on how C++ compilers handle this), or you can do as you suggest and run enough of Backpack to figure out how things are instantiated, and then make a build task for each instantiated unit. I think you are right that we will want to build this eventually; but I don't want it to be the default, and I want something simpler for casual use. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 22:18:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 22:18:00 -0000 Subject: [GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth Message-ID: <045.4946614216cb9413670db0e02815dfbc@haskell.org> #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The problem observed on GHC's code base when explored why exactly some object files are so huge. Let's look at the stats of text code section sizes on today's HEAD (skipping GHCi libraries and stage1 binaries): {{{ ~/dev/git/ghc $ size `find -name *.o -type f | grep -v stage1 | grep -v HS` | sort -k1 -n -r | head -n20 text data bss dec hex filename 1791068 145448 0 1936516 1d8c84 ./compiler/stage2/build/DynFlags.o 1558637 77464 0 1636101 18f705 ./compiler/stage2/build/PprC.o 1397966 23272 0 1421238 15afb6 ./compiler/stage2/build/PlatformConstants.o 1332048 373344 0 1705392 1a05b0 ./libraries/Cabal/Cabal/dist- boot/build/Distribution/PackageDescription.o 1331238 373352 0 1704590 1a028e ./bootstrapping/Distribution/PackageDescription.o 1271578 246240 0 1517818 1728fa ./libraries/template-haskell/dist- boot/build/Language/Haskell/TH/Syntax.o 1229696 311616 0 1541312 1784c0 ./libraries/Cabal/Cabal/dist- install/build/Distribution/PackageDescription.o 1215082 224288 0 1439370 15f68a ./libraries/template-haskell/dist- install/build/Language/Haskell/TH/Syntax.o 1071746 242664 0 1314410 140e6a ./compiler/stage2/build/HsExpr.o 1015090 40904 0 1055994 101cfa ./compiler/stage2/build/Llvm/PpLlvm.o 970203 124944 0 1095147 10b5eb ./compiler/stage2/build/Parser.o 849693 79760 0 929453 e2ead ./compiler/stage2/build/HsDecls.o 833327 35440 0 868767 d419f ./compiler/stage2/build/X86/CodeGen.o 819959 127192 0 947151 e73cf ./libraries/Cabal/Cabal/dist- boot/build/Distribution/Simple/Setup.o 819685 125120 0 944805 e6aa5 ./bootstrapping/Distribution/Simple/Setup.o 816927 124520 0 941447 e5d87 ./libraries/Cabal/Cabal/dist- install/build/Distribution/Simple/Setup.o 785398 41536 0 826934 c9e36 ./compiler/stage2/build/CoreLint.o 772550 42040 0 814590 c6dfe ./compiler/stage2/build/DriverPipeline.o 766461 36280 0 802741 c3fb5 ./compiler/stage2/build/HscMain.o 735605 23408 0 759013 b94e5 ./libraries/containers/dist- install/build/Data/Sequence.o }}} '''PlatformConstants.o''' is a very clear example of this problem. Trimmed down example of this file is: {{{#!hs module M (D) where data D = D { a0 , a01 , a02 , a03 , a04 , a05 , a06 , a07 , a08 , a09 , a10 , a11 , a12 , a13 , a14 , a15 , a16 , a17 , a18 , a19 , a20 , a21 , a22 , a23 , a24 , a25 , a26 , a27 , a28 , a29 , a30 , a31 , a32 , a33 , a34 , a35 , a36 , a37 , a38 , a39 , a40 , a41 , a42 , a43 , a44 , a45 , a46 , a47 , a48 , a49 , a50 , a51 , a52 , a53 , a54 , a55 , a56 , a57 , a58 , a59 , a60 , a61 , a62 , a63 , a64 , a65 , a66 , a67 , a68 , a69 , a70 , a71 , a72 , a73 , a74 , a75 , a76 , a77 , a78 , a79 , a80 , a81 , a82 , a83 , a84 , a85 , a86 , a87 , a88 , a89 , a90 , a91 , a92 , a93 , a94 , a95 , a96 , a97 , a98 , a99 :: Int } deriving Read }}} Results in 800KB file: {{{ $ ghc-stage2 -c -O1 -fforce-recomp M.hs -o M.o $ size M.o text data bss dec hex filename 847039 16080 0 863119 d2b8f M.o }}} The size growth is quadratic: {{{ # fields code-size 1 6263 21 61767 41 173623 61 347503 81 583367 101 881231 121 1241087 141 1662959 161 2146815 181 2692679 201 3300543 221 3970407 241 4702263 261 5496135 281 6351991 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 22:18:40 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 22:18:40 -0000 Subject: [GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth In-Reply-To: <045.4946614216cb9413670db0e02815dfbc@haskell.org> References: <045.4946614216cb9413670db0e02815dfbc@haskell.org> Message-ID: <060.d57218a33337b07dfe10f6301de669ff@haskell.org> #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * Attachment "mk_data.bash" added. script to build temp files and stats -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 22:19:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 22:19:08 -0000 Subject: [GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth In-Reply-To: <045.4946614216cb9413670db0e02815dfbc@haskell.org> References: <045.4946614216cb9413670db0e02815dfbc@haskell.org> Message-ID: <060.fbab007a5cbaa40d5e59f43140955dea@haskell.org> #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * Attachment "size-growth.log.png" added. graph for 1 to 281 field in a simple datatype. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 22:33:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 22:33:05 -0000 Subject: [GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth In-Reply-To: <045.4946614216cb9413670db0e02815dfbc@haskell.org> References: <045.4946614216cb9413670db0e02815dfbc@haskell.org> Message-ID: <060.fbbe5c351af218d24b32dfab54cffee5@haskell.org> #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): Derived instance looks reasonably well (i've picked a data type with 282 fields): {{{#!hs {- $ ghc -O1 -fforce-recomp -ddump-deriv M.hs [1 of 1] Compiling M ( M.hs, M.o ) ==================== Derived instances ==================== Derived instances: -} instance GHC.Read.Read M.D where GHC.Read.readPrec = GHC.Read.parens (Text.ParserCombinators.ReadPrec.prec 11 (do { GHC.Read.expectP (Text.Read.Lex.Ident "D"); GHC.Read.expectP (Text.Read.Lex.Punc "{"); GHC.Read.expectP (Text.Read.Lex.Ident "a0"); GHC.Read.expectP (Text.Read.Lex.Punc "="); a1_a1ns <- Text.ParserCombinators.ReadPrec.reset GHC.Read.readPrec; GHC.Read.expectP (Text.Read.Lex.Punc ","); GHC.Read.expectP (Text.Read.Lex.Ident "a1"); GHC.Read.expectP (Text.Read.Lex.Punc "="); a2_a1nt <- Text.ParserCombinators.ReadPrec.reset GHC.Read.readPrec; GHC.Read.expectP (Text.Read.Lex.Punc ","); GHC.Read.expectP (Text.Read.Lex.Ident "a2"); GHC.Read.expectP (Text.Read.Lex.Punc "="); a3_a1nu <- Text.ParserCombinators.ReadPrec.reset GHC.Read.readPrec; -- ... GHC.Read.expectP (Text.Read.Lex.Punc ","); GHC.Read.expectP (Text.Read.Lex.Ident "a280"); GHC.Read.expectP (Text.Read.Lex.Punc "="); a281_a1rY <- Text.ParserCombinators.ReadPrec.reset GHC.Read.readPrec; GHC.Read.expectP (Text.Read.Lex.Punc ","); GHC.Read.expectP (Text.Read.Lex.Ident "a281"); GHC.Read.expectP (Text.Read.Lex.Punc "="); a282_a1rZ <- Text.ParserCombinators.ReadPrec.reset GHC.Read.readPrec; GHC.Read.expectP (Text.Read.Lex.Punc "}"); GHC.Base.return (M.D a1_a1ns a2_a1nt a3_a1nu a4_a1nv a5_a1nw -- ... a280_a1rX a281_a1rY a282_a1rZ) })) GHC.Read.readList = GHC.Read.readListDefault GHC.Read.readListPrec = GHC.Read.readListPrecDefault }}} Generated assembly is full of stack rearrangements which seems to be a main source of code inflation and compilation slowdown. Some thoughts: - Could GHC do a CSE for code sequences of '''expetP (Punc ); expetP (Ident ); expetP (Punc );'''? - If all fields were strict could GHC optimise stack layout better? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 16 22:34:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Oct 2015 22:34:10 -0000 Subject: [GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth In-Reply-To: <045.4946614216cb9413670db0e02815dfbc@haskell.org> References: <045.4946614216cb9413670db0e02815dfbc@haskell.org> Message-ID: <060.53e1a1f1fa81319e5e3018b049877c3e@haskell.org> #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: simonmar, simonpj, ezyang (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 17 03:27:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Oct 2015 03:27:56 -0000 Subject: [GHC] #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name In-Reply-To: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> References: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> Message-ID: <057.e36d252e917ac5cb99c4bec437c31789@haskell.org> #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name -------------------------------------+------------------------------------- Reporter: ony | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | driver/recomp011 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1326 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ony): Replying to [comment:2 thomie]: As I understand I'll cherry-pick this change to branch `ghc-7.10` it will go into GHC 7.10.3 (or whatever will come out after change will be accepted). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 17 04:02:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Oct 2015 04:02:57 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.4cd5fcd6db5c9239b0c486dddea60372@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rrnewton): If blackholing *is* the culprit then I wonder how localized the strictification will need to be... Ezyang's multi-process suggestion seems appealing. But if it's a `forkProcess` approach, is it possible to load most of the relevant state into memory before forking a child process per module? That could avoid or reduce communication through files or shared pages. The granularity of per-module compiles is big, so maybe processes would be ok. Also, there's the nice side effect that the GCs of child processes are disentangled, removing that particular scaling bottleneck. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 17 07:14:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Oct 2015 07:14:48 -0000 Subject: [GHC] #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name In-Reply-To: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> References: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> Message-ID: <057.76968504f0207ed3d0158ea91499cf43@haskell.org> #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name -------------------------------------+------------------------------------- Reporter: ony | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | driver/recomp011 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1326 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * milestone: 8.0.1 => 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 17 08:29:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Oct 2015 08:29:35 -0000 Subject: [GHC] #10981: Not detecting clang correctly Message-ID: <044.a21ee178126ef9f166fcb27933cfa81b@haskell.org> #10981: Not detecting clang correctly -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 have Jenkins build job that builds GHC from Git using Clang as the C compiler. Recently a Debian update changed clang's `-v1 output to: {{{ Debian clang version 3.5.2-2 (tags/RELEASE_352/final) (based on LLVM 3.5.2) Target: x86_64-pc-linux-gnu Thread model: posix }}} which is no longer being detected by `compiler/main/SysTools.hs` as `Clang`. Working around this is trivially easy. Patch in progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 17 08:32:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Oct 2015 08:32:16 -0000 Subject: [GHC] #10914: Bad symbol resolution on Darwin when using DYLD_FORCE_FLAT_NAMESPACE=1 In-Reply-To: <047.9268eb7f03934b85eb39681f4890afc7@haskell.org> References: <047.9268eb7f03934b85eb39681f4890afc7@haskell.org> Message-ID: <062.29db1607e949e34d636932ab5dfa3f00@haskell.org> #10914: Bad symbol resolution on Darwin when using DYLD_FORCE_FLAT_NAMESPACE=1 -------------------------------------+------------------------------------- Reporter: jacereda | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Runtime System | Version: 7.10.2 (Linker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => new Comment: Moving out of review queue, see comment:3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 17 08:34:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Oct 2015 08:34:23 -0000 Subject: [GHC] #8238: Implement unloading of shared libraries In-Reply-To: <047.e2bbc066d014f0f597cdb8b788581350@haskell.org> References: <047.e2bbc066d014f0f597cdb8b788581350@haskell.org> Message-ID: <062.31d87b7747fcb015dc1a10ac5e072b0d@haskell.org> #8238: Implement unloading of shared libraries -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.7 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 8039 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => new Comment: Moving out of review queue. The patch mentioned in comment:2 is unfinished. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 17 08:36:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Oct 2015 08:36:32 -0000 Subject: [GHC] #10981: Not detecting clang correctly In-Reply-To: <044.a21ee178126ef9f166fcb27933cfa81b@haskell.org> References: <044.a21ee178126ef9f166fcb27933cfa81b@haskell.org> Message-ID: <059.15caa914203c5033f75db1aff1b3043e@haskell.org> #10981: Not detecting clang correctly -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1336 Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * differential: => Phab:D1336 Old description: > I have Jenkins build job that builds GHC from Git using Clang as the C > compiler. > > Recently a Debian update changed clang's `-v1 output to: > > {{{ > Debian clang version 3.5.2-2 (tags/RELEASE_352/final) (based on LLVM > 3.5.2) > Target: x86_64-pc-linux-gnu > Thread model: posix > }}} > > which is no longer being detected by `compiler/main/SysTools.hs` as > `Clang`. > > Working around this is trivially easy. Patch in progress. New description: I have Jenkins build job that builds GHC from Git using Clang as the C compiler. Recently a Debian update changed clang's `-v` output to: {{{ Debian clang version 3.5.2-2 (tags/RELEASE_352/final) (based on LLVM 3.5.2) Target: x86_64-pc-linux-gnu Thread model: posix }}} which is no longer being detected by `compiler/main/SysTools.hs` as `Clang`. Working around this is trivially easy. Patch in progress. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 17 09:18:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Oct 2015 09:18:51 -0000 Subject: [GHC] #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression In-Reply-To: <045.67153471687796395f900337ba5220e7@haskell.org> References: <045.67153471687796395f900337ba5220e7@haskell.org> Message-ID: <060.0f1b33457c960d5d0a1b0cd06018b0d1@haskell.org> #10796: Illegal data constructor name: `fromList' ... When splicing a TH expression -------------------------------------+------------------------------------- Reporter: erisco | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.8.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:D1313 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"3340fe01bc6842c2cad53271541dce6699512ce0/ghc" 3340fe01/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3340fe01bc6842c2cad53271541dce6699512ce0" Build system: fix `make -j1` (#10973) There are multiple hacks all over the build system to account for the fact that the ghc package uses different build subdirectories (stage1/stage2) than the other packages (dist/dist-install). One such hack filtered on 'ghc%', with the intention of filtering the ghc package only. After renaming bin-package-db to ghc-boot (d2f9972a35ce05ceb8a78893e433ef1df06f73ef, Phab:D1313, #10796), ghc-boot also got caught in the hack, which broke the build when running without parallelism. This patch replaces the before mentioned hack by a different one, such that filtering on 'ghc%' is no longer necessary. See Note [inconsistent distdirs]. Reviewed by: austin Differential Revision: https://phabricator.haskell.org/D1333 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 17 09:18:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Oct 2015 09:18:51 -0000 Subject: [GHC] #10973: Building git HEAD with a singe make job fails due to dependency problem In-Reply-To: <044.ce71bd5536233be44928eb09733a9711@haskell.org> References: <044.ce71bd5536233be44928eb09733a9711@haskell.org> Message-ID: <059.2023795129b3ee585fb6ce8a335778b4@haskell.org> #10973: Building git HEAD with a singe make job fails due to dependency problem -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 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:D1333 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"3340fe01bc6842c2cad53271541dce6699512ce0/ghc" 3340fe01/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3340fe01bc6842c2cad53271541dce6699512ce0" Build system: fix `make -j1` (#10973) There are multiple hacks all over the build system to account for the fact that the ghc package uses different build subdirectories (stage1/stage2) than the other packages (dist/dist-install). One such hack filtered on 'ghc%', with the intention of filtering the ghc package only. After renaming bin-package-db to ghc-boot (d2f9972a35ce05ceb8a78893e433ef1df06f73ef, Phab:D1313, #10796), ghc-boot also got caught in the hack, which broke the build when running without parallelism. This patch replaces the before mentioned hack by a different one, such that filtering on 'ghc%' is no longer necessary. See Note [inconsistent distdirs]. Reviewed by: austin Differential Revision: https://phabricator.haskell.org/D1333 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 17 09:19:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Oct 2015 09:19:32 -0000 Subject: [GHC] #10973: Building git HEAD with a singe make job fails due to dependency problem In-Reply-To: <044.ce71bd5536233be44928eb09733a9711@haskell.org> References: <044.ce71bd5536233be44928eb09733a9711@haskell.org> Message-ID: <059.725bdeb49efc5f5642cbc6345a39a9ad@haskell.org> #10973: Building git HEAD with a singe make job fails due to dependency problem -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 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:D1333 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed Comment: Should be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 17 10:20:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Oct 2015 10:20:33 -0000 Subject: [GHC] #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs In-Reply-To: <046.1a97d00bdb899516ed37dc451d128951@haskell.org> References: <046.1a97d00bdb899516ed37dc451d128951@haskell.org> Message-ID: <061.4e9688df577f89e909b68c6831e4f321@haskell.org> #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs -------------------------------------+------------------------------------- Reporter: mcandre | Owner: lukyanov Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: driver/T9360a | driver/T9360b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1337 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * testcase: => driver/T9360a driver/T9360b * differential: => Phab:D1337 * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 17 13:04:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Oct 2015 13:04:45 -0000 Subject: [GHC] #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name In-Reply-To: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> References: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> Message-ID: <057.3499a9857b87d398f05bcb0fab84f101@haskell.org> #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name -------------------------------------+------------------------------------- Reporter: ony | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | driver/recomp011 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1326 Wiki Page: | Phab:D1335 -------------------------------------+------------------------------------- Changes (by ony): * differential: Phab:D1326 => Phab:D1326 Phab:D1335 Comment: Adapted change https://phabricator.haskell.org/D1335 for `ghc-7.10` branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 17 14:49:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Oct 2015 14:49:03 -0000 Subject: [GHC] #10773: Add Control.Monad.IO.Class from transformers to base In-Reply-To: <050.fa78270471b5c8a35c327e5b8e6838d1@haskell.org> References: <050.fa78270471b5c8a35c327e5b8e6838d1@haskell.org> Message-ID: <065.9708dc41e774978046f89a3c7cc077bc@haskell.org> #10773: Add Control.Monad.IO.Class from transformers to base -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1147 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fff02548d237655dea39f108364d7ebe6d0e122d/ghc" fff02548/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fff02548d237655dea39f108364d7ebe6d0e122d" Move Control.Monad.IO.Class to base from transformers See Trac #10773 Remove Control.Monad.IO.Class from `transformers`. Updates `transformers` submodule. See Trac #10773 Test Plan: ./validate Reviewers: ekmett, hvr, bgamari, austin Reviewed By: hvr, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1147 GHC Trac Issues: #10773 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 17 14:49:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Oct 2015 14:49:03 -0000 Subject: [GHC] #10656: Ability to get stack traces from Haskell code In-Reply-To: <046.afad267b86c2cf45e3280bfe1e22e59b@haskell.org> References: <046.afad267b86c2cf45e3280bfe1e22e59b@haskell.org> Message-ID: <061.a0efce6d56d0be6a6e2e78c456dc6fc6@haskell.org> #10656: Ability to get stack traces from Haskell code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Tarrasch Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3693 | Differential Rev(s): Phab:D963 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a6a3dabc9e6b1cfc2f4047d2d09efe634affb120/ghc" a6a3dabc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a6a3dabc9e6b1cfc2f4047d2d09efe634affb120" Libdw: Add libdw-based stack unwinding This adds basic support to the RTS for DWARF-assisted unwinding of the Haskell and C stack via libdw. This only adds the infrastructure; consumers of this functionality will be introduced in future diffs. Currently we are carrying the initial register collection code in Libdw.c but this will eventually make its way upstream to libdw. Test Plan: See future patches Reviewers: Tarrasch, scpmw, austin, simonmar Reviewed By: austin, simonmar Subscribers: simonmar, thomie, erikd Differential Revision: https://phabricator.haskell.org/D1196 GHC Trac Issues: #10656 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 17 16:45:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Oct 2015 16:45:35 -0000 Subject: [GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth In-Reply-To: <045.4946614216cb9413670db0e02815dfbc@haskell.org> References: <045.4946614216cb9413670db0e02815dfbc@haskell.org> Message-ID: <060.f6bceae641a30080b1305b74505ba2a9@haskell.org> #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): I've tried to manually move out repeated pieces {{{#!hs GHC.Read.expectP (Text.Read.Lex.Punc ","); GHC.Read.expectP (Text.Read.Lex.Ident "a2"); GHC.Read.expectP (Text.Read.Lex.Punc "="); a3_a1nu <- Text.ParserCombinators.ReadPrec.reset GHC.Read.readPrec; }}} to a separate binding parameterised by Ident and it seems to be enough to make code growth linear with added fields. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 17 17:27:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Oct 2015 17:27:51 -0000 Subject: [GHC] #10982: Warn about unused pattern variables in type families Message-ID: <048.414cea110a08b8e94adb14433ca6c307@haskell.org> #10982: Warn about unused pattern variables in type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- Now that we have wildcards in type families (#3699) I want to be warned about unused pattern variables in the same way I am warned about them at the term level. For example this should cause a warning that `b` is not used: {{{#!hs type family F a b type instance F a b = a }}} Prefixing unused variable with an underscore should suppress the warning: {{{#!hs type family F a b type instance F a _b = a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 17 18:31:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Oct 2015 18:31:17 -0000 Subject: [GHC] #10972: Add a :binfo (beginner info) GHCi command In-Reply-To: <045.69c25027f6e9192e0896957840c11b0e@haskell.org> References: <045.69c25027f6e9192e0896957840c11b0e@haskell.org> Message-ID: <060.4fbdd0b2d3dc5e05dfa881cc12251bae@haskell.org> #10972: Add a :binfo (beginner info) GHCi command -------------------------------------+------------------------------------- Reporter: kanetw | Owner: kanetw Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kanetw): What kind of specializations should be displayed? Displaying every possible specialization is impractical even if we restrict to unary typeclasses (consider `Num`). I think specializing for types with special notation like `[]` or `(->)` would be most useful: {{{#!hs > :binfo find find :: Foldable t => (a -> Bool) -> t a -> Maybe a Specializations: t ~ [] -> find :: (a -> Bool) -> [a] -> Maybe a > :binfo first first :: Arrow a => a b c -> a (b, d) (c, d) Specializiations: a ~ (->) -> first :: (b -> c) -> (b, d) -> (c, d) }}} Having something like `find :: (a -> Bool) -> Set a -> Maybe a` doesn't really help a lot in my opinion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 18 14:25:47 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Oct 2015 14:25:47 -0000 Subject: [GHC] #10983: Installing GHC with Centos 7 Message-ID: <053.3631cbb1688bb70508cc1759e414e22e@haskell.org> #10983: Installing GHC with Centos 7 -------------------------------------+------------------------------------- Reporter: | Owner: scott_wilson46 | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, I've spent about half an hour of fruitless searching to try and get round this issue. It seems that there is no libgmp.so.3 on Centos 7 so I can't get GHC installed via any of the methods suggested. I even tried building gmp from source but this only gave me a static library for libgmp (libgmp.la), so am pretty frustrated really. Any ideas on how to get past this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 18 14:30:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Oct 2015 14:30:38 -0000 Subject: [GHC] #10955: GHC on windows does not resolve DLL dependencies In-Reply-To: <044.d1371f1a3dafc9d7220a00358a56f239@haskell.org> References: <044.d1371f1a3dafc9d7220a00358a56f239@haskell.org> Message-ID: <059.7a27d8e4bf1d801669e0993bcd8b3076@haskell.org> #10955: GHC on windows does not resolve DLL dependencies -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1340 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D1340 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 18 14:47:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Oct 2015 14:47:34 -0000 Subject: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> References: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> Message-ID: <060.8df904be9de799bee9a78efa93b88706@haskell.org> #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------+----------------------------- Reporter: jeffz1 | Owner: Phyx- Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Rev(s): Wiki Page: | ---------------------------------+----------------------------- Changes (by Phyx-): * owner: => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 18 15:11:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Oct 2015 15:11:03 -0000 Subject: [GHC] #10984: the ghc-7.8.4 source distribution contents (README, etc.) Message-ID: <048.ca5997b56646bcd8525b32248f39d0ec@haskell.org> #10984: the ghc-7.8.4 source distribution contents (README, etc.) -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 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: -------------------------------------+------------------------------------- ghc-7.8.4-src.tar.xz from https://www.haskell.org/ghc/download_ghc_7_8_4 does not include a README or INSTALL file. Its ANNOUNCE file talks of ghc-7.8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 18 17:18:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Oct 2015 17:18:16 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.bfdd099c05920a0e14ddd51c0c08b517@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1284 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): Replying to [comment:21 bergmark]: > I would like to see the partial functions removed as well. toList is total, which makes fromList the most natural name for converting to a NonEmpty, but nope it's partial! Use nonEmpty instead. There's also a partial IsList instance, I really don't want literals to be able to crash at runtime. In the non-empty package I fall back to infix operators for non-empty list construction. E.g. constructing a list with at least two elements looks like this: {{{0 !: 1 !: 2 : 3 : 4 : []}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 18 18:55:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Oct 2015 18:55:05 -0000 Subject: [GHC] #10985: When a "non-exhaustive pattern"-error occurs, output the arguments (if possible) Message-ID: <051.d679e661282bd34a5ded13247e74b71c@haskell.org> #10985: When a "non-exhaustive pattern"-error occurs, output the arguments (if possible) -------------------------------------+------------------------------------- Reporter: Watercrystal | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 (Debugging) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10972 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For Haskell-beginners like me, "non-exhaustive pattern"-errors occur rather often and they can take some time to fix. While it is obvious that one has made a critical mistake when writing a function, I don't think adding some debugging help would certainly not be bad. I know that this feature only really makes sense when working with types that are instances of `Show`, but then again beginners find themselves working with these types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 00:35:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 00:35:39 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp Message-ID: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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 creates large numbers of temporary files in /tmp. These would normally get cleaned up when the machine is rebooted, but for things like Jenkins build machines that don't get rebooted often they buld up pretty quickly. The /tmp on my Jenkins build machine currently has over 200k files and directories, but only about 40 of them are non-GHC related files. Under normal operation, GHC should delete all temporary files it creates. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 00:40:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 00:40:32 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.c1478e0930bc3fc2f586551056dff9cb@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * owner: => erikd Comment: My initial idea was a create a wrapper function for the creation of temp files and directories and then in the wrapper, add them to a list in an IORef. Just before GHC exits, it would read the list from the IORef and delete them. Happy to listen to any better suggestions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 00:43:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 00:43:51 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.fa0d75cb331b6a5bbaf2cd29dbe3a754@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by erikd: Old description: > GHC creates large numbers of temporary files in /tmp. These would > normally get cleaned up when the machine is rebooted, but for things like > Jenkins build machines that don't get rebooted often they buld up pretty > quickly. The /tmp on my Jenkins build machine currently has over 200k > files and directories, but only about 40 of them are non-GHC related > files. > > Under normal operation, GHC should delete all temporary files it creates. New description: GHC creates large numbers of temporary files in /tmp. These would normally get cleaned up when the machine is rebooted, but for things like Jenkins build machines that don't get rebooted often they accumulate pretty quickly. The /tmp on my Jenkins build machine currently has over 200k files and directories, but only about 40 of them are non-GHC related files. Under normal operation, GHC should delete all temporary files it creates. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 01:00:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 01:00:46 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.3adbf0844416e0960f07e54dd31dc10e@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.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:D910, | Phab:D1073, Phab:D1133, Phab:D1192, Wiki Page: | Phab:D1268 -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 01:05:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 01:05:23 -0000 Subject: [GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth In-Reply-To: <045.4946614216cb9413670db0e02815dfbc@haskell.org> References: <045.4946614216cb9413670db0e02815dfbc@haskell.org> Message-ID: <060.10edba13c566e33d76b4f464fc7de01a@haskell.org> #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * cc: mpickering (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 01:46:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 01:46:34 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.c10ef2547cc8b4d38185c0fb38010947@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): ghc does normally clean up its temporary directory. It would be good to understand under what circumstances it does not. (Maybe only when it panics?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 01:51:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 01:51:29 -0000 Subject: [GHC] #10987: -i option requires named module Message-ID: <047.1e49d068fee786f184a634b0d96d3438@haskell.org> #10987: -i option requires named module -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have the following layout: {{{ ./Foo.hs ./test/Bar.hs }}} both empty files. I can run ghci successfully as follows: {{{ >ghci Foo >ghci test/Bar >ghci -itest Foo }}} but {{{ >ghci -itest Bar File name does not match module name: Saw: ?Main? Expected: ?Bar? }}} The same problem occurs when `ghci` is replaced with `ghc`. Basically, ghc/ghci is forcing modules found via -i to have a named module in them. My understanding is that `ghci -itest Bar` is equivalent to `ghci test/Bar`, so the behavior should be the same as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 02:27:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 02:27:56 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.02ce93482779d70d3fb55b69364892b2@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by mgsloan): * cc: mgsloan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 02:33:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 02:33:38 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.0686aa524ef7afad090d92ea6d38fb62@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1342 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D1342 Comment: I started working on this https://phabricator.haskell.org/D1342. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 02:46:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 02:46:10 -0000 Subject: [GHC] #10985: When a "non-exhaustive pattern"-error occurs, output the arguments (if possible) In-Reply-To: <051.d679e661282bd34a5ded13247e74b71c@haskell.org> References: <051.d679e661282bd34a5ded13247e74b71c@haskell.org> Message-ID: <066.a7cadd3fd8d4c5027b08483356d61c26@haskell.org> #10985: When a "non-exhaustive pattern"-error occurs, output the arguments (if possible) -------------------------------------+------------------------------------- Reporter: Watercrystal | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 (Debugging) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10972 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I like this idea. In certain easy cases (pattern-matching against a monomorphic type that has an obvious `Show` instance) this would be quite easy to add, I think. Harder cases would be, well, harder. But perhaps the easy case is enough. Note that it would be hard to do a check to see if a type variable is instantiated to a type that has a `Show` instance. Or, instead of using `Show`, we could use whatever GHCi's `:force` command uses to print a value. (This doesn't require a `Show` instance.) It's even conceivable to use a `Show` instance if one is obviously available and fallback to the `:force` thing otherwise. Any volunteers to concretely specify this behavior and implement? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 03:42:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 03:42:07 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.70879975b0b336252eae8d4915a0156e@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): > ghc does normally clean up its temporary directory. On my machines its leaving behind two kins of things: * An normally empty /tmp/ghcNNN_M directory where NNN looks like a process id and M looks like it may be a thread number (0 is most common, followed by 1, 2, 3 etc). When these directories are not empty, they contain things like ghc_ZZ.s, ghc_ZZ.o etc. * A /tmp/ccXXXXXX file which contain what looks like command line options for GCC, one per line. This is probably a result of commit 296bc70b5ff6c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 08:37:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 08:37:55 -0000 Subject: [GHC] #10871: Implement "fat" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.5271546667a046150777a0b6b8a86df4@haskell.org> #10871: Implement "fat" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: 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): First, I absolutely agree that we should be able to use Backpack without Cabal, indeed it must be so since Cabal is just a layer on top of GHC. The original intuition with Backpack was that building fully instantiated packages can work exactly as it does now - we build everything from the leaves up to the root in dependency order, no extra mechanisms are needed. Furthermore, when dealing with indefinite packages, we can generate interface files but not code. I'm still not seeing anything in this that requires fat interface files. Let me re-answer your questions: What does it mean to install an indefinite package? We install just the interface files, so that we can typecheck against it. What does it mean to install a package that instantiates an indefinite package? Just built and install it! Then we have to build the package that it instantiates, which is exactly how cabal-install works now. I think your story is more complicated. You said "GHC can manage compiling the instantiated units, since it can just resume that compilation!" but that's blurring the boundary between Cabal and GHC, since suddenly GHC has to go and compile *and install* things. I can imagine this getting really messy. Better to have Cabal manage building and installing things at the package level, like it does now. GHC will need to know when it is just typechecking something vs. compiling it against definite dependencies. Hence, Cabal will also need a new command (or something) to do this - it's a new mode of operation, and the user needs to be in control, so there's no escaping this being visible at the Cabal level, I believe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 08:50:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 08:50:46 -0000 Subject: [GHC] #10871: Implement "fat" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.ecbff30265c05becc1d0877213a02d5f@haskell.org> #10871: Implement "fat" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: 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 me re-answer your questions: What does it mean to install an indefinite package? We install just the interface files, so that we can typecheck against it We need more than that. We need to compile the indefinite package to code when we fill its holes. So we need access to its source code in some form. One way to do that is to keep the original Haskell source code (pre-cpp, pre-everything) and typecheck it from scratch, being (a) careful to keep a copy of the source code and (b) ever so careful to replay exactly the front-end compiler flags that were used the first time round. We could do this. But it's just easier to snapshot the Core bindings that we already have in our hand. With unfoldings in interface files we already do this; it's mainly a question of keeping all unfoldings, not just some. It's not an efficiency issue. If it's easier to compile again from source (remembering all the C bits etc) then let's do that. To me it looks harder. And that's the core issue to debate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 09:06:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 09:06:33 -0000 Subject: [GHC] #1853: hpc mix files for Main modules overwrite each other In-Reply-To: <044.9b946ad54a9a35d3915c7a74c107b816@haskell.org> References: <044.9b946ad54a9a35d3915c7a74c107b816@haskell.org> Message-ID: <059.052fff14f5ef33f41b0e6b7f0d342b35@haskell.org> #1853: hpc mix files for Main modules overwrite each other ----------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Code Coverage | Version: 6.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by mgsloan): Hi, thanks for the response Andy! Handily, I already had a minimal repro for this from back when I initially started working on coverage support in stack: https://github.com/mgsloan /multi-test-suite In particular: {{{ mgsloan at computer:~/fpco/multi-test-suite$ cabal test --ghc-options -fhpc # ...mgsloan at computer:~/fpco/multi-test-suite$ hpc report multi-test- suite-test.tix hpc: can not find Main in ["./.hpc"] mgsloan at computer:~/fpco/multi-test-suite$ hpc report multi-test-suite- test-2.tix 50% expressions used (1/2) 100% boolean coverage (0/0) 100% guards (0/0) 100% 'if' conditions (0/0) 100% qualifiers (0/0) 100% alternatives used (0/0) 100% local declarations used (0/0) 100% top-level declarations used (1/1) }}} This issue will also affect cabal files that have other stanzas like executables and benchmarks. I added a folder called sub-package to multi- test-repo, actually debug / test out a different stack coverage related issue. The only reasonable way I can think of to fix this is to add a flag to GHC, which takes the name to use for the mix file folder. This won't directly fix the problem with current Cabal, but it would allow future version of Cabal to pass the info so that this issue is resolved. I'm not sure what to call the flag - it doesn't necessarily need to be specific to HPC - since there might be other places in GHC that benefit from knowing the cabal component. So, I'm thinking either `-component- name`, or `-hpc-component-name`. I took a look at Cabal's current invocations of GHC to see if there is any way for GHC to know that it's building a particular executable component. Unfortunately, I don't see any arguments that would make a good source for this info: {{{ /usr/local/bin/ghc --make -no-link -fbuilding-cabal-package -O -j8 -static -outputdir dist/build/multi-test-suite-test/multi-test-suite-test-tmp -odir dist/build/multi-test-suite-test/multi-test-suite-test-tmp -hidir dist/build/multi-test-suite-test/multi-test-suite-test-tmp -stubdir dist/build/multi-test-suite-test/multi-test-suite-test-tmp -i -idist/build /multi-test-suite-test/multi-test-suite-test-tmp -itest -idist/build/autogen -Idist/build/autogen -Idist/build/multi-test-suite- test/multi-test-suite-test-tmp -optP-include -optPdist/build/autogen/cabal_macros.h -hide-all-packages -package-db dist/package.conf.inplace -package-id base-4.8.1.0-4f7206fd964c629946bb89db72c80011 -package-id multi-test- suite-0.1.0.0-inplace -XHaskell2010 test/Spec.hs -threaded -rtsopts '-with-rtsopts=-N' -fhpc }}} (Sorry, the naming isn't all that clear, `multi-test-suite-test` is the name of the component) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 09:29:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 09:29:42 -0000 Subject: [GHC] #10951: HPC program has poor error reporting / strange CLI in general In-Reply-To: <046.0eb67759af4f01648e433f1249d67ab5@haskell.org> References: <046.0eb67759af4f01648e433f1249d67ab5@haskell.org> Message-ID: <061.d025614f96cf6e3ce1592c44f77e6fb4@haskell.org> #10951: HPC program has poor error reporting / strange CLI in general -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Code Coverage | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mgsloan): 1. Cool :D 2. Good point. Maybe the solution to #1 can just notice if there's more than one positional argument and explain to the user what their meaning is. 3. Now I'm thinking it likely makes sense to take a conservative approach with these changes. How about just letting `hpc combine` take more than two tix files? 4. Yeah, I don't think this is needed anymore after thomie's changes 5. Cool, sounds good! I hope to get around to these code changes soonish, but no promises - it might languish on the backburner for a little while. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 09:48:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 09:48:12 -0000 Subject: [GHC] #10871: Implement "fat" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.a57c0ceaf0d76c29d28aa562d3c037d1@haskell.org> #10871: Implement "fat" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: 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): > We need more than that. We need to compile the indefinite package to code when we fill its holes. So we need access to its source code in some form. > One way to do that is to keep the original Haskell source code (pre-cpp, pre-everything) and typecheck it from scratch, being (a) careful to keep a copy of the source code and (b) ever so careful to replay exactly the front-end compiler flags that were used the first time round. We could do this. But it's just easier to snapshot the Core bindings that we already have in our hand. With unfoldings in interface files we already do this; it's mainly a question of keeping all unfoldings, not just some. So that's exactly what I think we should ''not'' do, we don't need to record and replay anything at all because when we instantiate the package it's a completely separate compilation. So just to be clear, the plan for building package A & B where A has a B-shaped hole would be: 1. typecheck A alone, install (thin) interface files 2. build B from source, install code + interface files 3. build A from source against B, install code + interface files And any of these steps can be omitted if we've already done it before and cached the results in the package database, which we can discover by looking up the package key. Isn't this much simpler than saving fat interface files? What am I missing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 09:50:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 09:50:42 -0000 Subject: [GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth In-Reply-To: <045.4946614216cb9413670db0e02815dfbc@haskell.org> References: <045.4946614216cb9413670db0e02815dfbc@haskell.org> Message-ID: <060.4e5cc641c48bc7c42636cc3776694468@haskell.org> #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Slyfox, can you give a small example of what the code looks like before and after your change? I can see that turning 4 lines into 1 (by creating a new function definition) is good, but at best that makes it 4 times smaller, which is not the difference between linear and quadratic. I'd like to understand where the quadratic-ness is coming from! Thanks for investigating this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 10:31:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 10:31:37 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.28443c900d44ae96809ff295124c89e4@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): This bug might depend on the platform you are on or the version of `gcc` you are using. For me, on Ubuntu (gcc 4.8.4) with HEAD, running 'make TEST=cabal01' creates the files you mentioned, but they get deleted before the test finishes. On msys2 Window (gcc 4.6.3) with HEAD, the following files are left behind in `/tmp`: {{{ -rwxr-xr-x 1 ghc None 126940 Oct 19 10:25 570528145.exe -rw-r--r-- 1 ghc None 4729 Oct 19 10:26 ccgHM4XN -rw-r--r-- 1 ghc None 4729 Oct 19 10:26 ccqNwUwz -rw-r--r-- 1 ghc None 5874 Oct 19 10:25 ccysdfeq }}} I don't see any panics occuring. Running the same test on Windows with `TEST_HC=ghc-7.8.3` only leaves behind that `.exe` file, not the `ccXXXXXX` files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 11:44:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 11:44:31 -0000 Subject: [GHC] #10983: Installing GHC with Centos 7 In-Reply-To: <053.3631cbb1688bb70508cc1759e414e22e@haskell.org> References: <053.3631cbb1688bb70508cc1759e414e22e@haskell.org> Message-ID: <068.0d59221d5c93d9e470a8c5941331475f@haskell.org> #10983: Installing GHC with Centos 7 -------------------------------------+------------------------------------- Reporter: scott_wilson46 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): I don't know the answer, but you could try asking your question on the following mailinglist, to address a wider audience: https://mail.haskell.org/mailman/listinfo/glasgow-haskell-users Include the steps you've taken, and the exact error message you see. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 13:02:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 13:02:35 -0000 Subject: [GHC] #10972: Add a :binfo (beginner info) GHCi command In-Reply-To: <045.69c25027f6e9192e0896957840c11b0e@haskell.org> References: <045.69c25027f6e9192e0896957840c11b0e@haskell.org> Message-ID: <060.7f757660e3c08b454865e46256ad31b0@haskell.org> #10972: Add a :binfo (beginner info) GHCi command -------------------------------------+------------------------------------- Reporter: kanetw | Owner: kanetw Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Here's an idea: use the `default` list. We could even add `(->)` to that list. It would be otherwise pointless, but by putting it in the list, we get the specialization behavior above. And it's user-customizable. So if, say, an instructor is using a custom list type or introducing the `Foldable Maybe` instance, that person could then just change the `default` list and get the new specializations. The `default` list also tends to be somewhat short, yielding about the right number of specializations in the output. We could also consider just adding this behavior to `:info`. Perhaps a quick user poll is in order? Nitpick: I would prefer we "specialise" instead of "specialize". Since we're writing the '''Glasgow''' Haskell Compiler, it seems we should use the variant of English spoken (wait -- English spoken in Glasgow is nigh incomprehensible, to me at least)... er... ''written'' in Glasgow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 13:21:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 13:21:14 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.e98b5e423035cd62b6ec069eca3d6486@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1342 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Thanks, osa1, for taking this on. I'm taking the proposal under consideration to be TemplateHaskell/PackageKeyChanges. Under this design, is it still possible to get the package name/version in TH? That might be useful for printing out messages to users, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 14:06:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 14:06:45 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.30954e57ced22875514f5492b3e252b4@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1342 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Hm, we may have lost the package version part, if it's not included in package id strings. I will check this. If we lost the version numbers it's not because of this patch, but because of previous changes. This patch is merely for reflecting other changes in TemplateHaskell API and preventing some wrong uses of `NameG` etc. If we could provide a way to generate readable strings with version numbers from current package ids, then that would solve the problem. But I'm not sure if version numbers are included in package ids. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 14:12:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 14:12:47 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.adf2f843140b3a3646bcfeda6dd4be7e@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1342 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): But for longer package names, the name is truncated in the package key, no? Is there no way to get the full package name anymore? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 14:16:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 14:16:28 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.36a959ed2a4653f1749e669ac7f407bf@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1342 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): If they're truncated, then yes, we lost full names(and maybe also version numbers). It would be great to have a wiki page about package id design. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 14:38:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 14:38:45 -0000 Subject: [GHC] #10983: Installing GHC with Centos 7 In-Reply-To: <053.3631cbb1688bb70508cc1759e414e22e@haskell.org> References: <053.3631cbb1688bb70508cc1759e414e22e@haskell.org> Message-ID: <068.012a5134433c70c5a3a28716b64033a2@haskell.org> #10983: Installing GHC with Centos 7 -------------------------------------+------------------------------------- Reporter: scott_wilson46 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: invalid | 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 * failure: None/Unknown => Installing GHC failed * resolution: => invalid Comment: It appears that Centos 7 uses libgmp 6.0.0, which has a different [[https://blog.flameeyes.eu/2009/04/shared-object-version|soversion]] from the rather ancient 4.3.1 released used in 6.6 (for which our Centos builds are intended). It's possible you could use the Debian build on Centos 7 as Debian has used libgmp 6.0.0 for quite some time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 14:44:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 14:44:21 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.f36fd7b0601b6ffeb540cd8d2033f255@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1342 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): @goldfire, This may be relevant: {{{#!haskell -- | A string which uniquely identifies a package. For wired-in packages, -- it is just the package name, but for user compiled packages, it is a hash. -- ToDo: when the key is a hash, we can do more clever things than store -- the hex representation and hash-cons those strings. newtype UnitId = PId FastString deriving( Eq, Typeable ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 15:12:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 15:12:17 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.7e615e5b0a31de457bd47caa3c8f0cbc@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1342 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I did some more reading, (2) in this proposal would solve this problem: https://mail.haskell.org/pipermail/libraries/2015-May/025600.html I believe we can even hide `PkgKey` type completely, just provide `Package` to users. `Package` would then contain package name and version number. In `NameG` etc. we can use `Package` instead of `PkgKey`. I have no ideas how to implement `searchPackage` and `reifyPackage` though, I'll need to read some more code. I thought we're losing name and version information. If that's the case it may not be possible to implement `searchPackage` as described in the mailing list post. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 15:56:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 15:56:29 -0000 Subject: [GHC] #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs In-Reply-To: <046.1a97d00bdb899516ed37dc451d128951@haskell.org> References: <046.1a97d00bdb899516ed37dc451d128951@haskell.org> Message-ID: <061.9b25acffb7ad9872a7c4c6c63893363c@haskell.org> #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs -------------------------------------+------------------------------------- Reporter: mcandre | Owner: lukyanov Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: driver/T9360a | driver/T9360b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1337 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"7bbb61bc969c27a38b26a605d5ac70ac98c328d9/ghc" 7bbb61b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7bbb61bc969c27a38b26a605d5ac70ac98c328d9" Driver: `ghci -e` should behave like `ghc -e` (#9360) Patch by lukyanov. Reviewed by: bgamari Differential Revision: https://phabricator.haskell.org/D1337 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 15:57:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 15:57:25 -0000 Subject: [GHC] #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs In-Reply-To: <046.1a97d00bdb899516ed37dc451d128951@haskell.org> References: <046.1a97d00bdb899516ed37dc451d128951@haskell.org> Message-ID: <061.f2d97a2b54c11f33c138c7a93be3a6e1@haskell.org> #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs -------------------------------------+------------------------------------- Reporter: mcandre | Owner: lukyanov Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.8.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: driver/T9360a | driver/T9360b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1337 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed Comment: Thanks for the patch lukyanov. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 16:06:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 16:06:04 -0000 Subject: [GHC] #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs In-Reply-To: <046.1a97d00bdb899516ed37dc451d128951@haskell.org> References: <046.1a97d00bdb899516ed37dc451d128951@haskell.org> Message-ID: <061.be6dc928c00bb527be11fc3c15e6b49f@haskell.org> #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs -------------------------------------+------------------------------------- Reporter: mcandre | Owner: lukyanov Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.8.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: driver/T9360a | driver/T9360b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1337 Wiki Page: | -------------------------------------+------------------------------------- Comment (by lukyanov): Replying to [comment:10 thomie]: > Thanks for the patch lukyanov. You're welcome. Sorry I didn't submit it to Phabricator myself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 16:14:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 16:14:39 -0000 Subject: [GHC] #10149: The argument of mask does not always restore the masking state In-Reply-To: <056.a022411c5d769cb0ad858891d8d4fe85@haskell.org> References: <056.a022411c5d769cb0ad858891d8d4fe85@haskell.org> Message-ID: <071.3a7971416a0a96be0c1bdf813be1231b@haskell.org> #10149: The argument of mask does not always restore the masking state -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.11 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:D1327 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2b25a589ae8f6364bf086b4878f5ec26954931d3/ghc" 2b25a58/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2b25a589ae8f6364bf086b4878f5ec26954931d3" base: Have the argument of mask restore the state. The implementation of `mask` and `uninterruptibleMask` assumed so far that the restore argument would be called in a context with the same masking state as that set by `mask` or `uninterruptibleMask`. This patch has the restore argument restore the masking, whatever the current masking state is. Test Plan: validate Reviewers: simonmar, hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie, qnikst Differential Revision: https://phabricator.haskell.org/D1327 GHC Trac Issues: #10149 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 16:15:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 16:15:35 -0000 Subject: [GHC] #10149: The argument of mask does not always restore the masking state In-Reply-To: <056.a022411c5d769cb0ad858891d8d4fe85@haskell.org> References: <056.a022411c5d769cb0ad858891d8d4fe85@haskell.org> Message-ID: <071.4d8591bee34a7fd005d0b3620ccfce3f@haskell.org> #10149: The argument of mask does not always restore the masking state -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: merge Priority: normal | Milestone: Component: libraries/base | Version: 7.11 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:D1327 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge Comment: Going to merge to `ghc-7.10` as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 16:20:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 16:20:26 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.231ed191f71b2e1463c4aea31c179964@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1342 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): It sounds like we should wait for ezyang's input before delving too much deeper. I see you've already pinged him on IRC. I'm sure he'll be in touch soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 17:45:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 17:45:59 -0000 Subject: [GHC] #10871: Implement "fat" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.4977bc9c945651676af0d043fa63ee93@haskell.org> #10871: Implement "fat" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): I think the difference in opinion stems from whether or not it's reasonable to ask the user to have built on the non-leaves prior to actually building the unit in question. Of course, the only way the user is going to do this in practice is with external tooling, e.g. cabal- install. But this is true for pre-Backpack packages too; no one really can install a package without help from Cabal. And since packages are the unit of distribution, and you want other things like the ability to download them from Hackage, this is just fine. In contrast, I can work on a multi-module Haskell program without using Cabal, and it would pretty horrible user-experience if I had to "install" every module before I could use it in another program. So here is what I think is the difference of opinion: I want to view Backpack units more as modules than as packages (in the old Cabal sense). And the reason for this is entirely tied up with small-scale use of Backpack. For example: today, if `containers` publishes `Data.Map` which has a map data type, I can use it immediately in an hs file, no fussing about with Cabal. If someone publishes a `data-map` Backpack unit, which has a hole for keys, it would be bad user experience to force a user to use Cabal to build and install all the instantiated copies of `data-map` they might want to use before they can build their application. To add insult to injury, if the key type in question is in the package I was working on, they would have separate it out into new unit containing just their type definition, so that could be installed first and the used to instantiated `data-map`, before they can go ahead and build the package they're thinking about. So, I think your intuition is right when holes are roughly "package" shaped. But I think it's quite important to have reasonable non-Cabal workflow when the holes are smaller, which forces us to have GHC instantiate things on the fly, which leads us to fat interfaces. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 17:55:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 17:55:37 -0000 Subject: [GHC] #10987: -i option requires named module In-Reply-To: <047.1e49d068fee786f184a634b0d96d3438@haskell.org> References: <047.1e49d068fee786f184a634b0d96d3438@haskell.org> Message-ID: <062.639ac3145bd1debf1945a75b9d41e694@haskell.org> #10987: -i option requires named module -------------------------------------+------------------------------------- Reporter: crockeea | Owner: osa1 Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * owner: => osa1 Comment: Here's how this works: - When parsing a module, GHC assumes module name is Main if it's not given. (at least in GHCi. relevant code: HeaderInfo.getImports) - When a file or module name is passed, it first tries to disambiguate the string to see if it's a file path or module name. It does this by checking if .hs or .lhs exist. (relevant code: GHC.guessTarget) - If it's a file path, `GhcMake.summariseFile` is called. This one makes no assumptions one which module to look for. So this works fine. It doesn't check module name. In the example above, `ghci test/Bar` and `ghci Foo` run this function, because GHC finds `test/Bar.hs` and `Foo.hs` files. - If it's a module name(that is, GHC was unable to find `.hs`), then `GhcMake.summariseModule` is called. This one assumes that the module name is whatever's passed as argument, so it fails in the example above. `ghci -itest Bar` assumes module name should be `Bar`. `ghci Foo` would do the same, except it can find `Foo.hs` so it runs `summariseFile` which makes no assumptions on module name. One way to fix this is to never guess file names. `ghci Blah` would always look for a module named `Blah`, `ghci Blah.hs` would always look for a file, without any assumptions about which module it has. (To be continued...) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 17:57:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 17:57:27 -0000 Subject: [GHC] #10987: -i option requires named module In-Reply-To: <047.1e49d068fee786f184a634b0d96d3438@haskell.org> References: <047.1e49d068fee786f184a634b0d96d3438@haskell.org> Message-ID: <062.d73f2abbd98be8ee0d915db62222f803@haskell.org> #10987: -i option requires named module -------------------------------------+------------------------------------- Reporter: crockeea | Owner: osa1 Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): So `-i` argument is not used when looking for `.hs`, it's only used when looking for a module with given name(``). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 18:42:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 18:42:10 -0000 Subject: [GHC] #10985: When a "non-exhaustive pattern"-error occurs, output the arguments (if possible) In-Reply-To: <051.d679e661282bd34a5ded13247e74b71c@haskell.org> References: <051.d679e661282bd34a5ded13247e74b71c@haskell.org> Message-ID: <066.353b252e1280b1c1d7f4334d6ec56269@haskell.org> #10985: When a "non-exhaustive pattern"-error occurs, output the arguments (if possible) -------------------------------------+------------------------------------- Reporter: Watercrystal | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 (Debugging) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10972 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kanetw): A few things to consider: {{{#!hs fix :: (a -> a) -> a fix f = let x = f x in x data Nat = Z | S Nat deriving Show badFunction Z = undefined }}} The error for `badFunction (fix S)` would never terminate, but we can limit the length here. Just a thing to keep in mind, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 19:07:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 19:07:08 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.3720bd0baca883acee9992f5f8b33720@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1342 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): See also #10068 (longer comment coming) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 19:32:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 19:32:51 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.decd131625239693c2527092b0a00dd0@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1342 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Right. So the extended fix suggested by this ticket is a little out of date because of another renaming which is coming soon for GHC 8.0. The main change was "package key" turned into "unit id", and "installed package id" turned into "component id". The main semantic change was that installed package ids don't identify packages anymore; they identify components (usually the library component, but there are other components in a package too); and the main reason we moved away from the "package" nomenclature is laid out in #10622. So, as far as this ticket is concerned, the easy way to fix it is to just take anywhere you see "Package" and rename it to "Unit" (and "PkgKey" to "UnitId".) There is one little unfortunate thing, which is instead of the "Package" we have "Unit", which might be slightly confusing for users (it's not to be confused with `()`) but I can't think of a good alternative. OK, more on the ticket comments: > Hm, we may have lost the package version part, if it's not included in package id strings. I will check this. It doesn't matter, the name and the version is reported from the installed package (unit) database. We don't extract it out from the UnitId. The UnitId is opaque! So we're querying against the DATABASE. > If we could provide a way to generate readable strings with version numbers from current package ids, then that would solve the problem. But I'm not sure if version numbers are included in package ids. With new Cabal, UnitId should be readable by default. > I believe we can even hide PkgKey type completely, just provide Package to users. That's a possibility, but I think it makes sense to keep them decoupled, so users can synthesize UnitIds (PkgKeys). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 19:41:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 19:41:35 -0000 Subject: [GHC] #10988: Suggest LambdaCase Message-ID: <047.c578c63a11a114dc5217b8712da20ec7@haskell.org> #10988: Suggest LambdaCase -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 (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: -------------------------------------+------------------------------------- When I say {{{#!hs module Bug where foo = \case True -> False False -> True }}} I get {{{ Bug.hs:9:7: error: parse error: naked lambda expression '' }}} We can do far better. Setting priority to high because it's rather embarrassing to let your lambdas run around naked. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 19:53:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 19:53:28 -0000 Subject: [GHC] #10988: Suggest LambdaCase In-Reply-To: <047.c578c63a11a114dc5217b8712da20ec7@haskell.org> References: <047.c578c63a11a114dc5217b8712da20ec7@haskell.org> Message-ID: <062.b97a56494ecfaf6d9b9d52a241ee3ecf@haskell.org> #10988: Suggest LambdaCase -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_fail/ParserNoLambdaCase Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => parser/should_fail/ParserNoLambdaCase Comment: HEAD, as well as 7.8.4, shows: {{{ Test.hs:3:8: parse error on input ?case? }}} See e2b579e8d77357e8b36f57d15daead101586ac8e (#10498). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 20:24:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 20:24:49 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.bd874cdf83c0d5fbe4e39d03f2fdd2fc@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1342 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > It doesn't matter, the name and the version is reported from the installed package (unit) database. We don't extract it out from the UnitId. The UnitId is opaque! So we're querying against the DATABASE. Where's that DATABASE, exactly? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 21:05:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 21:05:38 -0000 Subject: [GHC] #602: Warning Suppression In-Reply-To: <047.d851345fc677a304d933040775d25d45@haskell.org> References: <047.d851345fc677a304d933040775d25d45@haskell.org> Message-ID: <062.4da7c527331cc27450a732a9fdc08cc1@haskell.org> #602: Warning Suppression -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edgar.zhavoronkov): Hi everyone! Do someone know, if there is such pragma or i need to implement it myself? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 21:14:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 21:14:16 -0000 Subject: [GHC] #10981: Not detecting clang correctly In-Reply-To: <044.a21ee178126ef9f166fcb27933cfa81b@haskell.org> References: <044.a21ee178126ef9f166fcb27933cfa81b@haskell.org> Message-ID: <059.7e2a3a750f0c521341ec0f930125d0b2@haskell.org> #10981: Not detecting clang correctly -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1336 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"96dc041a502754da475e38cb84ed2bb0e142d527/ghc" 96dc041/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="96dc041a502754da475e38cb84ed2bb0e142d527" Systools.hs: Improve detection of GCC and Clang Test Plan: Build on Debian using `--with-gcc=clang` Reviewers: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1336 GHC Trac Issues: #10981 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 21:14:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 21:14:38 -0000 Subject: [GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth In-Reply-To: <045.4946614216cb9413670db0e02815dfbc@haskell.org> References: <045.4946614216cb9413670db0e02815dfbc@haskell.org> Message-ID: <060.49e61f44607360cec60fdbc73aca9d8c@haskell.org> #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): Replying to [comment:5 simonpj]: > Slyfox, can you give a small example of what the code looks like before and after your change? I can see that turning 4 lines into 1 (by creating a new function definition) is good, but at best that makes it 4 times smaller, which is not the difference between linear and quadratic. I've rechecked the measurement and you are correct! Quadratic behaviour stil presents in manually converted sources. Seems I was looking at the wrong binary files when tweaking things. Apologies for the confusion :( (for completness) attaching source file before and after transformation for 200-entries file: {{{ $ ghc -c -fforce-recomp -c -O1 M_200_auto.hs $ ghc -c -fforce-recomp -c -O1 M_200_manual.hs $ size M_200_auto.o M_200_manual.o text data bss dec hex filename 3268679 41520 0 3310199 328277 M_200_auto.o 674695 16424 0 691119 a8baf M_200_manual.o }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 21:15:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 21:15:10 -0000 Subject: [GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth In-Reply-To: <045.4946614216cb9413670db0e02815dfbc@haskell.org> References: <045.4946614216cb9413670db0e02815dfbc@haskell.org> Message-ID: <060.0b4d65a141c04448615678381e0571cb@haskell.org> #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * Attachment "M_200_auto.hs" added. by ghc derived as-is -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 21:15:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 21:15:39 -0000 Subject: [GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth In-Reply-To: <045.4946614216cb9413670db0e02815dfbc@haskell.org> References: <045.4946614216cb9413670db0e02815dfbc@haskell.org> Message-ID: <060.a6727f5c8f527fc00fa2d695e8334311@haskell.org> #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * Attachment "M_200_manual.hs" added. factored out repetition -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 21:27:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 21:27:18 -0000 Subject: [GHC] #10981: Not detecting clang correctly In-Reply-To: <044.a21ee178126ef9f166fcb27933cfa81b@haskell.org> References: <044.a21ee178126ef9f166fcb27933cfa81b@haskell.org> Message-ID: <059.09b58e41dd6492bdbccebb72de024e8e@haskell.org> #10981: Not detecting clang correctly -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1336 Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 21:34:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 21:34:06 -0000 Subject: [GHC] #9414: GHC 7.8.3 compilation fails on Raspberry PI In-Reply-To: <047.40b5d8ee9b85e5848646d14a99373ff4@haskell.org> References: <047.40b5d8ee9b85e5848646d14a99373ff4@haskell.org> Message-ID: <062.b5ad8870e977d1b606945ba54738917f@haskell.org> #9414: GHC 7.8.3 compilation fails on Raspberry PI ---------------------------------+----------------------------- Reporter: ipuustin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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 erikd): * cc: erikd (added) Comment: Is this still an issue? There has a been a lot of work in 7.10.2 (which is the current release) to improve GHC on Arm and there has been a bunch more work that will be in 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 21:42:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 21:42:15 -0000 Subject: [GHC] #10469: ghc crash on arm with -j2: internal error: scavenge: unimplemented/strange closure type In-Reply-To: <047.60fe47838743a4cb466668b7b2d86836@haskell.org> References: <047.60fe47838743a4cb466668b7b2d86836@haskell.org> Message-ID: <062.6a1e3dc9aa66346399216fc237136936@haskell.org> #10469: ghc crash on arm with -j2: internal error: scavenge: unimplemented/strange closure type ---------------------------------------+------------------------------ Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------------+------------------------------ Changes (by erikd): * cc: erikd (added) Comment: Good news is that 7.10.2 is much better on Arm than 7.10.1 or 7.8.4. I also expect 7.10.3 and 8.0.1 to be better again. During debugging #10375 I found two serious problem with the interaction between Arm and Thumb2 code. Ghc 7.10.3 and 8.0 will both force all code to be `armv6-unknown-linux-gnueabihf` which should fix a lot of the problems like this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 21:47:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 21:47:43 -0000 Subject: [GHC] #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted In-Reply-To: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> References: <051.6de3bb6380bb073196bb38e7623ede92@haskell.org> Message-ID: <066.448bd2f4c85b2d52048220701a9dd8a7@haskell.org> #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted ---------------------------------------+------------------------------ Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: arm Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: #5642, #9675 | Differential Rev(s): Wiki Page: | ---------------------------------------+------------------------------ Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 21:48:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 21:48:35 -0000 Subject: [GHC] #7988: Big integers crashing integer-simple on qnxnto-arm In-Reply-To: <049.7e25cab1852e69b7f9c237cdefeb4eb3@haskell.org> References: <049.7e25cab1852e69b7f9c237cdefeb4eb3@haskell.org> Message-ID: <064.8ec6bb376d19a1deac5ebbdce7b290d3@haskell.org> #7988: Big integers crashing integer-simple on qnxnto-arm ----------------------------------+--------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: QNX | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+--------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 21:50:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 21:50:01 -0000 Subject: [GHC] #7316: GHC segfaults on ARM In-Reply-To: <044.80d09029baede03deac2ad7b7fbe42af@haskell.org> References: <044.80d09029baede03deac2ad7b7fbe42af@haskell.org> Message-ID: <059.bd40868712bce4f6c594dc950425db60@haskell.org> #7316: GHC segfaults on ARM -------------------------------------+------------------------------- Reporter: laney | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: 7623 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 21:51:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 21:51:40 -0000 Subject: [GHC] #10864: arm: strange closure type 64008 from cabal-install In-Reply-To: <048.6229c44b2e93186b58e67744c7d1c1ed@haskell.org> References: <048.6229c44b2e93186b58e67744c7d1c1ed@haskell.org> Message-ID: <063.2a2c7675e330703d66d913c75d9f4060@haskell.org> #10864: arm: strange closure type 64008 from cabal-install ----------------------------------+------------------------------ Reporter: muhmuhten | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Changes (by erikd): * cc: erikd (added) Comment: Highly likely this is related to the problem fixed in #10375 which has been fixed in the git HEAD (which will be the 8.0 release) is is likely to be pulled into the 7.10.3 release when and if it happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 22:05:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 22:05:46 -0000 Subject: [GHC] #602: Warning Suppression In-Reply-To: <047.d851345fc677a304d933040775d25d45@haskell.org> References: <047.d851345fc677a304d933040775d25d45@haskell.org> Message-ID: <062.84befff7c1dc46ba707e0dcfe6460a4b@haskell.org> #602: Warning Suppression -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This has not been implemented. You're welcome to try to specify this feature concretely and try to put together a patch! The specification comes first. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 22:07:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 22:07:47 -0000 Subject: [GHC] #10433: Fix load/store barriers in pre-ARMv7 builds In-Reply-To: <052.31a10dbc9e090605b3fa8f37a267b618@haskell.org> References: <052.31a10dbc9e090605b3fa8f37a267b618@haskell.org> Message-ID: <067.d5c3ad793e3fce37782944e319513cd3@haskell.org> #10433: Fix load/store barriers in pre-ARMv7 builds -------------------------------------+----------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10244 | Differential Rev(s): Wiki Page: | -------------------------------------+----------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 22:10:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 22:10:18 -0000 Subject: [GHC] #10409: Binary compiled with ghc-7.10 amd64/linux to aarch64/linux cross compiler segfaults. In-Reply-To: <044.281124fed1ab665b0c342f08f03cde68@haskell.org> References: <044.281124fed1ab665b0c342f08f03cde68@haskell.org> Message-ID: <059.bb5d89306de0617538aff90ad6f53ec6@haskell.org> #10409: Binary compiled with ghc-7.10 amd64/linux to aarch64/linux cross compiler segfaults. ----------------------------------+--------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: cross-compiling Operating System: Linux | Architecture: aarch64 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+--------------------------------------- Changes (by erikd): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 22:10:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 22:10:48 -0000 Subject: [GHC] #10409: Binary compiled with ghc-7.10 amd64/linux to aarch64/linux cross compiler segfaults. In-Reply-To: <044.281124fed1ab665b0c342f08f03cde68@haskell.org> References: <044.281124fed1ab665b0c342f08f03cde68@haskell.org> Message-ID: <059.99390dd5b021efbcf18806b9e1b8b339@haskell.org> #10409: Binary compiled with ghc-7.10 amd64/linux to aarch64/linux cross compiler segfaults. ----------------------------------+--------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: cross-compiling Operating System: Linux | Architecture: aarch64 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+--------------------------------------- Changes (by erikd): * milestone: 8.0.1 => 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 22:14:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 22:14:16 -0000 Subject: [GHC] #10988: Suggest LambdaCase In-Reply-To: <047.c578c63a11a114dc5217b8712da20ec7@haskell.org> References: <047.c578c63a11a114dc5217b8712da20ec7@haskell.org> Message-ID: <062.fa6754fc19cd3a8b8cde695b50c81f71@haskell.org> #10988: Suggest LambdaCase -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 (Parser) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_fail/ParserNoLambdaCase Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: Ah. Although I forgot to say so on the ticket, I tested against HEAD. But it's a slightly old HEAD. I guess this is fixed. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 22:24:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 22:24:58 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.23f3863227144a927ef39b5f42fd1af6@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by erikd): Yep, added `%d15` to the clobbered regs list and added a comment along the lines you suggested. As usual its in the `wip/aarch64-regd` in the GHC git repo. Behavour as expected is unchanged. Currently have ~170 test failing. Choosing one, pretty much at random, I notice that it fails in three different ways (as do many of the other failing tests): {{{ $ inplace/bin/ghc-stage2 -O -v0 -fforce-recomp \ testsuite/tests/numeric/should_run/T7014.hs -o a.out Illegal instruction (core dumped) $ inplace/bin/ghc-stage2 -O -v0 -fforce-recomp \ testsuite/tests/numeric/should_run/T7014.hs -o a.out Segmentation fault (core dumped) $ inplace/bin/ghc-stage2 -O -v0 -fforce-recomp \ testsuite/tests/numeric/should_run/T7014.hs -o a.out Bus error (core dumped) }}} Even after disabling ASLR (Address space layout randomization) it still fails in at least two ways. The above failure only happens with optimisation (`-O`) turned on. As usual, GDB provides nothing but a very poor backtrace: {{{ Program received signal SIGSEGV, Segmentation fault. 0x000006d6f9400288 in ?? () (gdb) bt #0 0x000006d6f9400288 in ?? () #1 0x0000007fb6db8ca4 in cwTZ_info$def () from .../libHSghc-7.11.20151019-ghc7.11.20151019.so }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 22:26:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 22:26:21 -0000 Subject: [GHC] #10870: PPC.Ppr: Shift by 32 bits is not allowed. In-Reply-To: <046.266af0561f46fb382b81907ac208339a@haskell.org> References: <046.266af0561f46fb382b81907ac208339a@haskell.org> Message-ID: <061.91d943513b7ad07f6260eb10f2919a67@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler (CodeGen) | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1322 Wiki Page: | ---------------------------------------+---------------------------------- Changes (by erikd): * Attachment "0001-PPC-Fix-right-shift-by-32-bits-10870.patch" added. Patch for 7.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 22:28:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 22:28:36 -0000 Subject: [GHC] #10870: PPC.Ppr: Shift by 32 bits is not allowed. In-Reply-To: <046.266af0561f46fb382b81907ac208339a@haskell.org> References: <046.266af0561f46fb382b81907ac208339a@haskell.org> Message-ID: <061.3df986b13d516d3745ba09acdb12c353@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler (CodeGen) | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1322 Wiki Page: | ---------------------------------------+---------------------------------- Comment (by erikd): The commit in the `master` branch doesn't apply to the `7.10` branch because of all the `powerpc64el` work in `master`. I have therefore attached a `7.10` specific patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 22:29:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 22:29:14 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.793d73b3398903bc12fc30f75da9d683@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1342 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): And how does Cabal enter into the picture? I'm afraid I'm quite lost here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 23:20:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 23:20:17 -0000 Subject: [GHC] #10650: Can't define GHCi :def macro with NoImplicitPrelude on In-Reply-To: <050.a9004b0bba20a10488d32b9b9c069466@haskell.org> References: <050.a9004b0bba20a10488d32b9b9c069466@haskell.org> Message-ID: <065.a8583edf2aaddba96b139c26d757dfe9@haskell.org> #10650: Can't define GHCi :def macro with NoImplicitPrelude on -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8640 #10508 | Differential Rev(s): D:974 Wiki Page: | -------------------------------------+------------------------------------- Changes (by archblob): * differential: => D:974 * related: #8640 => #8640 #10508 Comment: Apparently the issue was fixed in HEAD by D:974 before this ticket even got created :). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 23:26:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 23:26:44 -0000 Subject: [GHC] #602: Warning Suppression In-Reply-To: <047.d851345fc677a304d933040775d25d45@haskell.org> References: <047.d851345fc677a304d933040775d25d45@haskell.org> Message-ID: <062.366cb2ad852803438dda1b877ca4fee3@haskell.org> #602: Warning Suppression -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edgar.zhavoronkov): Replying to [comment:23 goldfire]: > This has not been implemented. You're welcome to try to specify this feature concretely and try to put together a patch! > > The specification comes first. :) Wrote some sort of informal specification with couple of use cases https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 23:29:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 23:29:57 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.ba64bef0b4eb297e56eede4cd6939e6d@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by erikd): Same problem compiling the most trivial "hello world" program. Without optimisation it compiles fine and the result executable works correctly. With optimisation the compiler crashes with a segfault. Add `-dshow-passes` results in: {{{ $ inplace/bin/ghc-stage2 hello-world.hs -O1 -dshow-passes -fforce-recomp -o \ hello-world Glasgow Haskell Compiler, Version 7.11.20151019, stage 2 booted by GHC version \ 7.8.4 Using binary package database: /home/erikd/ghc-upstream/inplace/lib/ package.conf.d/package.cache wired-in package ghc-prim mapped to ghc-prim-0.4.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.0 wired-in package base mapped to base-4.8.2.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.11.0.0 wired-in package ghc mapped to ghc-7.11.20151019 wired-in package dph-seq not found. wired-in package dph-par not found. wired-in package ghc-prim mapped to ghc-prim-0.4.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.0 wired-in package base mapped to base-4.8.2.0 wired-in package rts mapped to rts-1.0 wired-in package template-haskell mapped to template-haskell-2.11.0.0 wired-in package ghc mapped to ghc-7.11.20151019 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *hello-world.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2015-10-19 23:10:28.96994973 UTC ms_mod = Main, ms_textual_imps = [(Nothing, Prelude)] ms_srcimps = [] }] *** Deleting temp files: compile: input file hello-world.hs *** Checking old interface for Main: [1 of 1] Compiling Main ( hello-world.hs, hello-world.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 7, types: 5, coercions: 0} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 11, types: 10, coercions: 0} Result size of Simplifier = {terms: 11, types: 10, coercions: 0} *** Specialise: Illegal instruction (core dumped) }}} Regardless of the above, this is almost certainly an LLVM or linker problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 23:46:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 23:46:18 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.84de0cc0478d694c38fadb214d1a5bab@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by edmund): You're quoting cases of ghc-stage2 segfaulting. Presumably that's because ghc-stage1 generated bad code. And I'm guessing both stage1 and stage2 are registerised. It would be nice if you could find a simple program that gets compiled incorrectly, and to get that you could either run the test suite with the stage1 compiler (bearing in mind that some tests are expected to fail with a stage1 compiler) or find a way of building a registerised stage2 using an unregisterised stage1 (which doesn't appear to be entirely straightforward with the way the build infrastructure works). What do you think? You can tell GDB "info reg" and "x/i 0x0000007fb6db8ca4" to find out how it got from there to 0x000006d6f9400288. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 19 23:50:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Oct 2015 23:50:46 -0000 Subject: [GHC] #10376: arm/linux linking failure In-Reply-To: <044.29ac411aa184ff9b10d3766853c9a35d@haskell.org> References: <044.29ac411aa184ff9b10d3766853c9a35d@haskell.org> Message-ID: <059.ca6fdbb8e74c3bdc0c4357fd375312ef@haskell.org> #10376: arm/linux linking failure -------------------------------------+----------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10464 | Differential Rev(s): Wiki Page: | -------------------------------------+----------------------------- Comment (by erikd): I've just compiled GHC 7.10.2 with the [changeset:"933adc0f31164cb651d11ecfcfe612ac429f714f/ghc" 933adc0f/ghc]: {{{ commit 933adc0f31164cb651d11ecfcfe612ac429f714f Author: Erik de Castro Lopo Date: Sun Oct 11 16:48:11 2015 +1100 Fix GHCi on Arm (#10375). }}} applied on top and this problem remains. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 00:32:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 00:32:36 -0000 Subject: [GHC] #10954: Add class/context information to typed hole relevant bindings In-Reply-To: <045.32f5d1e1940c448cdbb57da9612bf97b@haskell.org> References: <045.32f5d1e1940c448cdbb57da9612bf97b@haskell.org> Message-ID: <060.1b767a74a40dfb681e49f909c847a965@haskell.org> #10954: Add class/context information to typed hole relevant bindings -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9479 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 00:36:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 00:36:02 -0000 Subject: [GHC] #9479: Report required constraints when reporting the type of a hole In-Reply-To: <056.d301c5f3e1df29c162c4f7ce444029a2@haskell.org> References: <056.d301c5f3e1df29c162c4f7ce444029a2@haskell.org> Message-ID: <071.925c44b4ba0cac45993298e1817b7bf2@haskell.org> #9479: Report required constraints when reporting the type of a hole -------------------------------------+------------------------------------- Reporter: | Owner: dominiquedevriese | Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.8.3 checker) | Resolution: | Keywords: holes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * priority: low => normal * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 02:21:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 02:21:43 -0000 Subject: [GHC] #10989: :ctags and :etags command can receive haskell source files as a parameter Message-ID: <045.de3e950ef6c4dee2c0f5411e366ebc4e@haskell.org> #10989: :ctags and :etags command can receive haskell source files as a parameter -------------------------------------+------------------------------------- Reporter: hugomg | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 7.10.2 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: -------------------------------------+------------------------------------- A friend of mine accidentally lost a bunch of uncomited code because he passed the name of his source file to ghci's ctags command {{{ :ctags hisstuff.hs }}} He tought that the ctags parameter was the name of the file to create the ctags from. Instead, that parameter is actually for the name of the file to write the tags to. His Haskell source file was instantly overwritten by the tag info. The source of this confusion is that the the documentation from the `:help` command just says it takes a "file" parameter, without explicitly mentioning that its the name of the *output* file. {{{ :ctags[!] [] create tags file for Vi (default: "tags") (!: use regex instead of line number) :etags [] create tags file for Emacs (default: "TAGS") }}} I think it would be safer to use a more precise name here instead of ``. Something like `` or ``. It might also be a good idea to forbid the ctags and etags commands from overwriting existing "hs" and "lhs" source files. If a user types `:ctags something.hs` then its almost certainly a mistake with potentially destructive consequences. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 07:30:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 07:30:02 -0000 Subject: [GHC] #10989: :ctags and :etags command can receive haskell source files as a parameter In-Reply-To: <045.de3e950ef6c4dee2c0f5411e366ebc4e@haskell.org> References: <045.de3e950ef6c4dee2c0f5411e366ebc4e@haskell.org> Message-ID: <060.bd713afb76adb0918136339d4d350f34@haskell.org> #10989: :ctags and :etags command can receive haskell source files as a parameter -------------------------------------+------------------------------------- Reporter: hugomg | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer * milestone: => 8.0.1 Comment: This sounds like a nice task for a newcomer: * Update the documentation as mentioned. * Change the function `collateAndWriteTags` in `ghc/GhciTags.hs` to not overwrite existing source files. * Add one or multiple tests in `testsuite/tests/ghci/scripts/`, see [wiki:Building/RunningTests/Adding]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 07:56:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 07:56:24 -0000 Subject: [GHC] #10990: Checking whether a default declaration is an instance of a defaultable typeclass is broken Message-ID: <045.0913ea572fc15f8b06002bba2c6402bf@haskell.org> #10990: Checking whether a default declaration is an instance of a defaultable typeclass is broken -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In TcDefaults.hs, `tcDefaults` is supposed to check whether the supplied default type is an instance o `Num` or `IsString` (note the lack of extended defaults here, so this has been broken for quite some time). Following the code we can see that `simplifyDefault` in TcSimplify.hs calls `reportAllUnsolved` and it does report the error -- with typechecker tracing on we see {{{ Adding error: :19:1: error: No instance for (Num []) arising from a 'default' declaration When checking the types in a default declaration }}} But typechecking never actually fails, so it returns `Just ()` regardless and the error gets swallowed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 08:05:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 08:05:58 -0000 Subject: [GHC] #10871: Implement "fat" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.63f11bb15b6c28e4993996ff994d61db@haskell.org> #10871: Implement "fat" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: 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 think the difference in opinion stems from whether or not it's reasonable to ask the user to have built the non-leaves prior to actually building the unit in question. In the case that it is necessary, the only way the user is going to be able to do this in practice is with external tooling, e.g. cabal-install. But this was true for pre-Backpack packages too; no one really can install a package without help from Cabal. And this seems to be fine. I'm not completely sure I understand what "built on the non-leaves" means, but I expect all of the packages (and instantiations thereof) that are dependencies of the current set of modules being built, are already built and installed in the package database. Which as you say, is exactly as it is now. > But there are other things for which it's not reasonable to ask the user to have run Cabal beforehand. For example, I can work on a multi-module Haskell program without using Cabal, and it would pretty horrible user- experience if I had to "install" every module before I could use it in another program. Absolutely. I expect to be able to do `ghc --make` on a collection of modules and signatures in a Backpack world, and provided all the external dependencies are satisfied in the package database, it should just work. > For example: today, if containers publishes Data.Map which has a map data type, I can use it immediately in an hs file, no fussing about with Cabal. If we translate this to Backpack, we get a data-map Backpack unit, which has a hole for the type of keys. It would be bad user experience to force a user to use Cabal to build and install all the instantiated copies of data-map they might want to use before they can build their application. To add insult to injury, if the key type in question is in the package I was working on, they would have separate it out into new unit containing just their type definition, so that could be installed first and the used to instantiated data-map, before they can go ahead and build the package they're thinking about. Yes - I do believe that to instantiate `Data.Map` you should have to build it (from the original source package) and install the instantiated result in the package database. But our tooling is going to do this for us automatically. This story is simple, fits with our current compilation model, and retains the logical separation between GHC (for building a collection of modules) and Cabal (for building and installing packages). I agree that this might be annoying from a user perspective if they aren't using the higher level tool, so I can see why you wanted to solve the problem differently. But isn't it going to be strange if building my program also requires a long sequence of compilations of external modules? And where do the results go? GHC has no business installing stuff, so they have to go in some local sandbox-like setup, which means that in some other project when you want the same instantiation you don't get to reuse the results. This is exactly what the package database is for! It caches compositions of packages. I think this relates to what you said earlier: > Here is where you might object, since I am cheating here, but what seems easiest is to have GHC and Cabal (but not cabal-install) conspire to deduplicate instantiated units "behind the scenes". I'm not sure exactly what mechanism you have in mind, but if Cabal and GHC have to conspire, what happens when you're using GHC by itself? This does seem extremely murky to me. Why not just use the package database, and have Cabal manage the installation of instantiated packages? So while I agree with you that it's important to have a story for using GHC(i) directly, in practice this isn't going to be the way people want to use it, and furthermore the more we try to make this a smooth user experience, the more we will end up putting features that should be in the higher-level tools into GHC itself, leading to a mess. So I think we should retain the current clear division of labour: stack/cabal know about collections of packages, Cabal-the-library knows about building + installing single packages, and GHC knows about building collections of modules. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 08:10:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 08:10:24 -0000 Subject: [GHC] #10650: Can't define GHCi :def macro with NoImplicitPrelude on In-Reply-To: <050.a9004b0bba20a10488d32b9b9c069466@haskell.org> References: <050.a9004b0bba20a10488d32b9b9c069466@haskell.org> Message-ID: <065.45a3950dd373d536a1c68d7e7ba42fdc@haskell.org> #10650: Can't define GHCi :def macro with NoImplicitPrelude on -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | ghci/scripts/T10508 Blocked By: | Blocking: Related Tickets: #8640 #10508 | Differential Rev(s): Phab:D974 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * testcase: => ghci/scripts/T10508 * differential: D:974 => Phab:D974 * resolution: => fixed * milestone: => 8.0.1 Comment: Replying to [comment:2 archblob]: > Apparently the issue was fixed in HEAD by D:974 before this ticket even got created :). Nice find! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 08:13:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 08:13:26 -0000 Subject: [GHC] #10990: Checking whether a default declaration is an instance of a defaultable typeclass is broken In-Reply-To: <045.0913ea572fc15f8b06002bba2c6402bf@haskell.org> References: <045.0913ea572fc15f8b06002bba2c6402bf@haskell.org> Message-ID: <060.c1572d145c3c7e05d84eeae2a7c2d3c6@haskell.org> #10990: Checking whether a default declaration is an instance of a defaultable typeclass is broken -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.10.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 thomie): Could you add sample code please (if you're not working on a fix already). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 08:28:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 08:28:41 -0000 Subject: [GHC] #10990: Checking whether a default declaration is an instance of a defaultable typeclass is broken In-Reply-To: <045.0913ea572fc15f8b06002bba2c6402bf@haskell.org> References: <045.0913ea572fc15f8b06002bba2c6402bf@haskell.org> Message-ID: <060.a04200fb94ee7b5c0a14e1539eae07a9@haskell.org> #10990: Checking whether a default declaration is an instance of a defaultable typeclass is broken -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.10.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 kanetw): Sure. {{{ % ./inplace/bin/ghc-stage2 --interactive -dtrace-level1 -ddump-tc-trace > default (Maybe Int) ... Adding error: :1:1: error: No instance for (Num (Maybe Int)) arising from a 'default' declaration When checking the types in a default declaration ... }}}. I might do a fix for this after I finish #10971. It's not a huge problem, but if we don't check for default declaration validity (which might be useful with a possible #10972 implementation) we should adjust the code/document it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 10:49:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 10:49:14 -0000 Subject: [GHC] #10945: Typed Template Haskell splices broken in HEAD (7.11) In-Reply-To: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> References: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> Message-ID: <063.38d1325bfff18d36ded772f27525d2b0@haskell.org> #10945: Typed Template Haskell splices broken in HEAD (7.11) -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10945 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * owner: => jstolarek -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 11:28:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 11:28:24 -0000 Subject: [GHC] #10945: Typed Template Haskell splices broken in HEAD (7.11) In-Reply-To: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> References: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> Message-ID: <063.8fba6b2efc6ba42db76590630a14ecd8@haskell.org> #10945: Typed Template Haskell splices broken in HEAD (7.11) -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10945 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): I initially thought that this bogus code - ie. top-level typed TH splice - should be rejected as a parse error. I spent some time trying to change the parser to reject the code but I couldn't find a good way of doing that. Then I realized that this code should parse: with TH enabled all top-level expressions should really be accepted, including a typed TH splice. After some more thought I believe that the right way of doing this would be to run the typed TH splice and then report a type error in the same way we report a type error here: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module T10945s where import Language.Haskell.TH True }}} {{{ T10945.hs:8:1: Couldn't match type ?Bool? with ?Q [Dec]? Expected type: DecsQ Actual type: Bool In the expression: True }}} Before investing more time into this I'd like to hear thoughts from other devs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 11:41:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 11:41:54 -0000 Subject: [GHC] #10991: Don't permit type variables in the context unless they are in the type Message-ID: <047.b262122a182410690e50f216776aeb9a@haskell.org> #10991: Don't permit type variables in the context unless they are in the type -------------------------------------+------------------------------------- Reporter: bernalex | Owner: bernalex Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Type checker) | 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: -------------------------------------+------------------------------------- GHC accepts the following: {{{ f :: Eq a => b -> b f b = b }}} This is not valid Haskell 2010[0], so we should not permit it. [0] ?The context cx must only contain type variables referenced in t?, https://www.haskell.org/report/node/2010/haskellch4.html#x10-660004.1.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 11:48:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 11:48:06 -0000 Subject: [GHC] #10991: Don't permit type variables in the context unless they are in the type In-Reply-To: <047.b262122a182410690e50f216776aeb9a@haskell.org> References: <047.b262122a182410690e50f216776aeb9a@haskell.org> Message-ID: <062.aee3a092de63760ad97ef75e57c0a550@haskell.org> #10991: Don't permit type variables in the context unless they are in the type -------------------------------------+------------------------------------- Reporter: bernalex | Owner: bernalex Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: checker) | 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 thomie): Which version of GHC are you using that this is accepted? ghc-7.10.2 reports: {{{ Test.hs:3:6: Could not deduce (Eq a0) from the context (Eq a) bound by the type signature for f :: Eq a => b -> b at Test.hs:3:6-19 The type variable ?a0? is ambiguous In the ambiguity check for the type signature for ?f?: f :: forall b a. Eq a => b -> b To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature for ?f?: f :: Eq a => b -> b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 11:50:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 11:50:30 -0000 Subject: [GHC] #10991: Don't permit type variables in the context unless they are in the type In-Reply-To: <047.b262122a182410690e50f216776aeb9a@haskell.org> References: <047.b262122a182410690e50f216776aeb9a@haskell.org> Message-ID: <062.40a7e9888df52584f48041038a66b8dd@haskell.org> #10991: Don't permit type variables in the context unless they are in the type -------------------------------------+------------------------------------- Reporter: bernalex | Owner: bernalex Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: checker) | 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 bernalex): Interesting. It seems to only accept the ill-typed code in GHCi. {{{ ? let f :: Eq a => b -> b; f b = b ? :t f f :: b -> b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 11:56:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 11:56:59 -0000 Subject: [GHC] #10992: Performance regression Message-ID: <046.c9e7f7c6b0bdb50720ba035d3861748a@haskell.org> #10992: Performance regression --------------------------------------+--------------------------------- Reporter: aleator | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: performane | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- For some reason Data.List.sum is much slower than the naive recursive definition for it. Does not seem happen in 7.8. {{{#!hs import Data.List import Criterion.Main sum1 [] = 0 sum1 (x:xs) = x + sum1 xs sum2 = foldr (+) 0 sum3 = foldl' (+) 0 sum4 = getSum #. foldMap Sum main = do let els = [1..100000] defaultMain [ bench "sum0" $ whnf (sum :: [Int] -> Int) els ,bench "sum" $ whnf (sum :: [Int] -> Int) els ,bench "sum1" $ whnf (sum1:: [Int] -> Int) els ,bench "sum2" $ whnf (sum2:: [Int] -> Int) els ,bench "sum3" $ whnf (sum3:: [Int] -> Int) els ,bench "sum4" $ whnf (sum4:: [Int] -> Int) els ] {- benchmarking sum0 time 128.0 ms (121.7 ms .. 133.8 ms) 0.997 R? (0.994 R? .. 1.000 R?) mean 132.8 ms (130.1 ms .. 136.3 ms) std dev 4.622 ms (2.980 ms .. 6.577 ms) variance introduced by outliers: 11% (moderately inflated) benchmarking sum time 131.0 ms (125.7 ms .. 136.7 ms) 0.998 R? (0.993 R? .. 1.000 R?) mean 131.9 ms (128.6 ms .. 136.7 ms) std dev 5.971 ms (2.903 ms .. 9.649 ms) variance introduced by outliers: 11% (moderately inflated) benchmarking sum1 time 26.29 ms (25.43 ms .. 27.24 ms) 0.995 R? (0.991 R? .. 0.998 R?) mean 26.30 ms (25.73 ms .. 26.98 ms) std dev 1.293 ms (953.2 ?s .. 1.804 ms) variance introduced by outliers: 15% (moderately inflated) benchmarking sum2 time 26.39 ms (25.49 ms .. 27.26 ms) 0.995 R? (0.991 R? .. 0.998 R?) mean 26.33 ms (25.77 ms .. 26.95 ms) std dev 1.295 ms (941.5 ?s .. 1.878 ms) variance introduced by outliers: 15% (moderately inflated) benchmarking sum3 time 7.695 ms (7.670 ms .. 7.722 ms) 1.000 R? (1.000 R? .. 1.000 R?) mean 7.703 ms (7.691 ms .. 7.733 ms) std dev 51.21 ?s (25.43 ?s .. 99.41 ?s) benchmarking sum4 time 26.29 ms (25.40 ms .. 27.21 ms) 0.995 R? (0.989 R? .. 0.998 R?) mean 26.36 ms (25.88 ms .. 27.08 ms) std dev 1.364 ms (954.5 ?s .. 1.899 ms) variance introduced by outliers: 20% (moderately inflated) -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 12:00:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 12:00:26 -0000 Subject: [GHC] #10945: Typed Template Haskell splices broken in HEAD (7.11) In-Reply-To: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> References: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> Message-ID: <063.9cce377af64cebdfc91c2e2305693a71@haskell.org> #10945: Typed Template Haskell splices broken in HEAD (7.11) -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10945 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): Oh, I have a nearly-one-line fix. Will post patch later for review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 12:08:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 12:08:06 -0000 Subject: [GHC] #10992: Performance regression due to lack of inlining of `foldl` and `foldl'`. (was: Performance regression) In-Reply-To: <046.c9e7f7c6b0bdb50720ba035d3861748a@haskell.org> References: <046.c9e7f7c6b0bdb50720ba035d3861748a@haskell.org> Message-ID: <061.953d4344b49d754ccd9dce938e902ece@haskell.org> #10992: Performance regression due to lack of inlining of `foldl` and `foldl'`. ---------------------------------+-------------------------------------- Reporter: aleator | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: performane Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by nomeata): I looked into this, and the cause is clear: In 7.10, `foldl (+) 0` (which is how `GHC.List.sum` is defined) resp. `foldl' (+) 0` are not inlined here. If they were, GHC would be able to transform both to the ideal code corresponding to an explicit recursion with accumulator. If I use these definitions: {{{ sum0 xs = sum xs sum3 xs = foldl' (+) 0 xs sum5 xs = foldl (+) 0 xs }}} then I get good code in all cases. The reason is that `foldl` is set up so that it inlines once the third argument is present: {{{ {-# INLINE foldl #-} foldl k z0 xs = ... {-# INLINE foldl' #-} foldl' k z0 xs = }}} This makes sense when trying to achieve list fusion, but even with two arguments (or maybe even one), inlining would be useful for the strictness analyzer to fire. I?m however not sure how relevant unsaturated calls to `foldl` are in practice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 13:01:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 13:01:11 -0000 Subject: [GHC] #10494: Representational equalities over AppTys are not hard failures In-Reply-To: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> References: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> Message-ID: <062.4fe272f921327dc8db67e29d3ba4ce1d@haskell.org> #10494: Representational equalities over AppTys are not hard failures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10494 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): goldfire, I've committed more head-scratching to porting this forward that perhaps I should have. Do you suppose you could port this to 7.10 (perhaps using `ghc-7.10.2-release` as a base commit)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 13:48:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 13:48:28 -0000 Subject: [GHC] #10945: Typed Template Haskell splices broken in HEAD (7.11) In-Reply-To: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> References: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> Message-ID: <063.9e2ef88304b7d295dd81eaeff2e09982@haskell.org> #10945: Typed Template Haskell splices broken in HEAD (7.11) -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10945 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1344 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * differential: => Phab:D1344 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 13:50:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 13:50:05 -0000 Subject: [GHC] #10991: Don't permit type variables in the context unless they are in the type In-Reply-To: <047.b262122a182410690e50f216776aeb9a@haskell.org> References: <047.b262122a182410690e50f216776aeb9a@haskell.org> Message-ID: <062.0067157d50d95f068078111369ff5a7c@haskell.org> #10991: Don't permit type variables in the context unless they are in the type -------------------------------------+------------------------------------- Reporter: bernalex | Owner: bernalex Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: checker) | Resolution: invalid | 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: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => invalid Comment: GHCi sets [https://downloads.haskell.org/~ghc/7.10.2/docs/html/users_guide /interactive-evaluation.html#extended-default-rules `-XExtendedDefaultRules`], which is the reason why your code is accepted. The following snippet is [https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-750004.3 valid Haskell], and thus always accepted, even when first running `:set -XNoExtendedDefaultRules` (note that because of #10857, running `ghci -XNoExtendedDefaultRules` doesn't work currently): {{{ let h :: Num a => b -> b; h b = b }}} The following is always rejected (only Show, Eq, and Ord are treated specially with `-XExtendedDefaultRules`): {{{ let g :: Read a => b -> b; g b = b }}} I don't think there is a bug here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 14:37:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 14:37:27 -0000 Subject: [GHC] #602: Warning Suppression In-Reply-To: <047.d851345fc677a304d933040775d25d45@haskell.org> References: <047.d851345fc677a304d933040775d25d45@haskell.org> Message-ID: <062.b81c6a3d86927ac4b274f1522fdf139a@haskell.org> #602: Warning Suppression -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): One point in the design space that anyone thinking about this should probably be aware of is that taken by [[https://doc.rust- lang.org/stable/reference.html#lint-check-attributes|Rust]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 15:09:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 15:09:51 -0000 Subject: [GHC] #8648: Initialization of C statics broken in threaded runtime In-Reply-To: <044.f1cfb611748ab32509135bb2aba15bfa@haskell.org> References: <044.f1cfb611748ab32509135bb2aba15bfa@haskell.org> Message-ID: <059.ec9b8c299859fe9526a8a837522a6250@haskell.org> #8648: Initialization of C statics broken in threaded runtime -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): This now just needs a test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 15:22:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 15:22:13 -0000 Subject: [GHC] #10993: Bad error message reported when -XBinaryLiterals is not enabled Message-ID: <043.4f825076a2552d01a1b8fea7502f9ccf@haskell.org> #10993: Bad error message reported when -XBinaryLiterals is not enabled -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (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: -------------------------------------+------------------------------------- When `-XBinaryLiterals` is not enabled, expressions like `0b10101` is causing this horrible error message: `Not in scope: ?b10101?`. The reason, as far as I understand, is that lexer is not lexing `0b0101` as a single token when `-XBinaryLiterals` is not enabled. Then the parser is parsing this as an application of `0` to `b0101`. (this can be observed with `-ddump-parsed`) My suggestion: Lexer should always generate a single token for `0b0101`. We don't do `ifExtension binaryLiteralsEnabled` checks in the lexer anymore. We somehow mark generated token as "requires extension: BinaryLiterals"(I don't know if we have the infrastructure for this right now). Then, when the parser sees an integer that requires `-XBinaryLiterals`, checks the flag and reports the error etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 15:33:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 15:33:38 -0000 Subject: [GHC] #602: Warning Suppression In-Reply-To: <047.d851345fc677a304d933040775d25d45@haskell.org> References: <047.d851345fc677a304d933040775d25d45@haskell.org> Message-ID: <062.d775b3e72f6dcec85fbc308ff58982a4@haskell.org> #602: Warning Suppression -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): And Rust's support reminds me very much of [http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks %2Ftask-suppress_warnings.htm Java's]. Both Rust and Java support warning suppression (or, for Rust, generation) based on scopes. Is that reasonable for Haskell? Maybe. We would continue to allow `OPTIONS` to specify flags for the whole file, but we could then also support local flags for definitions (or parts of definitions). The one thing this design wouldn't allow is setting warning suppression for a whole bunch of definitions (but not all). That may be an acceptable tradeoff. While we're thinking about this, it might be reasonable to consider adding arbitrary option-changes locally. (For example, I'd love to be able to turn on `LANGUAGE` pragmas only for part of a file.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 15:51:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 15:51:30 -0000 Subject: [GHC] #10993: Bad error message reported when -XBinaryLiterals is not enabled In-Reply-To: <043.4f825076a2552d01a1b8fea7502f9ccf@haskell.org> References: <043.4f825076a2552d01a1b8fea7502f9ccf@haskell.org> Message-ID: <058.5bb649af36db9cbb11b87de94c95483c@haskell.org> #10993: Bad error message reported when -XBinaryLiterals is not enabled -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (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 thomie): * cc: hvr (added) Comment: Hugs reports a similar error: Undefined variable "b10101". So I'm guessing the haskell report dictates `0b0101` should be parsed as 2 tokens (but I'm having difficulties finding out where it would say so exactly), and this would be a breaking change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 16:11:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 16:11:54 -0000 Subject: [GHC] #10457: Revise/remove custom mapM implementation for lists In-Reply-To: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> References: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> Message-ID: <059.b0c9347a23e430829da2235ef9dfe838@haskell.org> #10457: Revise/remove custom mapM implementation for lists -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 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:D1124 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: The performance regression is fixed: https://perf.haskell.org/ghc/#revision/fff02548d237655dea39f108364d7ebe6d0e122d. nofib/allocs/cryptarithm2 21545696 - 41.58% 12588032 bytes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 17:58:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 17:58:35 -0000 Subject: [GHC] #10426: matchGroupArity panic with PatternSynonyms In-Reply-To: <051.7a688bba15de9645a47ca046eb2525fe@haskell.org> References: <051.7a688bba15de9645a47ca046eb2525fe@haskell.org> Message-ID: <066.32548084334dbfcb0f8a2b13a200917c@haskell.org> #10426: matchGroupArity panic with PatternSynonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => PatternSynonyms * cc: mpickering, cactus (added) * os: Linux => Unknown/Multiple * architecture: x86 => Unknown/Multiple Comment: Not fixed yet in ghc-7.11.20151019. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 18:00:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 18:00:45 -0000 Subject: [GHC] #10250: API Annotations : add Locations in hsSyn were layout occurs In-Reply-To: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> References: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> Message-ID: <059.b9e3079842e00ce159e8d3dc0908884e@haskell.org> #10250: API Annotations : add Locations in hsSyn were layout occurs -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D815 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * owner: alanz => * status: closed => new * resolution: fixed => Comment: In commit 97d320f56b5848d6ba2c723c6e7f04f98e349a86: {{{ Author: Austin Seipp <> Date: Wed May 6 10:20:26 2015 -0500 Revert "API Annotations : add Locations in hsSyn were layout occurs" This reverts commit fb54b2c11cc7f2cfbafa35b6a1819d7443aa5494. As Alan pointed out, this will make cherry picking a lot harder until 7.10.2, so lets back it out until after the release. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 18:03:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 18:03:17 -0000 Subject: [GHC] #10250: API Annotations : add Locations in hsSyn were layout occurs In-Reply-To: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> References: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> Message-ID: <059.dc91f7dba3e27e8a01d91ebd0642bba0@haskell.org> #10250: API Annotations : add Locations in hsSyn were layout occurs -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D815 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Ok, now I understand, it was reverted. Is this work still scheduled for ghc-8? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 18:08:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 18:08:38 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.68f0eab461e67e45e607f790543e7683@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, Wiki Page: | Phab:D1268 -------------------------------------+------------------------------------- Changes (by thomie): * related: => #10424 Comment: #10424 is related: "Build path leaks into ABI hashes". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 18:26:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 18:26:37 -0000 Subject: [GHC] #10945: Typed Template Haskell splices broken in HEAD (7.11) In-Reply-To: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> References: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> Message-ID: <063.45234bfef74c0fcaa3cecc9548cf36b2@haskell.org> #10945: Typed Template Haskell splices broken in HEAD (7.11) -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10945 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1344 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Jan Stolarek ): In [changeset:"1750ebc2e40bab85246717326d3d5c60f132e652/ghc" 1750ebc2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1750ebc2e40bab85246717326d3d5c60f132e652" Reject top-level typed TH splices. Fixes #10945 When TemplateHaskell language extension is enabled it is valid to have top-level expressions. Each such expression is treated as a contents of a splice. The problem arises with typed splices. They are not valid at the top level and therefore we should interpret them not as a splice but as a top-level expression (aka. implicit splice). So saying: $$foo is equivalent of: $( $$foo ) This patch makes sure that this is indeed the case. Until now we incorrectly treated typed splices as explicit splices. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 18:30:42 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 18:30:42 -0000 Subject: [GHC] #10404: GHC panic when creating a monomorphised pattern synonym for GADT In-Reply-To: <051.7ba9349b8474f729185a50676c86da71@haskell.org> References: <051.7ba9349b8474f729185a50676c86da71@haskell.org> Message-ID: <066.cbdc7a3900e38c5ef333990599791f2c@haskell.org> #10404: GHC panic when creating a monomorphised pattern synonym for GADT -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: | PatternSynonyms Operating System: Linux | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: cactus, mpickering (added) * keywords: => PatternSynonyms * milestone: => 8.0.1 Old description: > I have an expression > > {{{#!hs > {-# LANGUAGE GADTs #-} > {-# LANGUAGE PatternSynonyms #-} > > data Exp a where > Fun :: (a -> b) -> (Exp a -> Exp b) > }}} > > and I want to create a pattern synonym for Int-expressions: > > {{{#!hs > -- This works: > -- pattern :: (a -> b) -> (Exp a -> Exp b) > -- pattern IntFun f x = Fun f x > > pattern :: (Int -> Int) -> (Exp Int -> Exp Int) > pattern IntFun f x = Fun f x > }}} > > which results in > > {{{#!hs > % ghci -ignore-dot-ghci Panic.hs > GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( Panic.hs, interpreted ) > > Panic.hs:8:28: > Couldn't match type ?a? with ?Int? > ?a? is a rigid type variable bound by > a pattern with constructor > Fun :: forall b a. (a -> b) -> Exp a -> Exp b, > in a pattern synonym declaration > at Panic.hs:8:22 > Expected type: Int -> Int > Actual type: a -> Int > Relevant bindings include > b :: Exp a (bound at Panic.hs:8:28) > a :: a -> Int (bound at Panic.hs:8:26) > Failed, modules loaded: none. > }}} > > So I try to be sneaky: > > {{{#!hs > pattern :: (a ~ Int) => (a -> b) -> (Exp a -> Exp b) > pattern IntFun f x = Fun f x > > -- % ghci -ignore-dot-ghci Panic.hs > -- ? > -- Couldn't match type ?a? with ?Int? > -- ?a? is a rigid type variable bound by > -- the type signature for IntFun :: (a1 -> b) -> Exp a1 -> Exp > b > -- at Panic.hs:8:22 > }}} > > and if I constrain both type variables it panics > > {{{#!hs > pattern :: (a ~ Int, b ~ Int) => (a -> b) -> (Exp a -> Exp b) > pattern IntFun f x = Fun f x > > -- Couldn't match type ?b? with ?Int? > -- ?b? is untouchable > -- inside the constraints () > -- bound by the type signature for > -- IntFun :: (a1 -> b) -> Exp a1 -> Exp b > -- at Panic.hs:8:9-14ghc: panic! (the 'impossible' happened) > -- (GHC version 7.10.0.20150316 for i386-unknown-linux): > -- No skolem info: b_alF[sk] > -- > -- Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > }}} > > The final version should look like: > > {{{#!hs > type Name = String > data Exp a where > Fun :: Name -> (a -> b) -> (Exp a -> Exp b) > ... > > pattern Suc :: Exp Int -> Exp Int > pattern Suc n <- Fun _ _ n where > Suc n = Fun "suc" (+ 1) n > }}} > > Shouldn't this work? New description: I have an expression {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} data Exp a where Fun :: (a -> b) -> (Exp a -> Exp b) }}} and I want to create a pattern synonym for Int-expressions: {{{#!hs -- This works: -- pattern IntFun :: (a -> b) -> (Exp a -> Exp b) -- pattern IntFun f x = Fun f x pattern IntFun :: (Int -> Int) -> (Exp Int -> Exp Int) pattern IntFun f x = Fun f x }}} which results in {{{#!hs % ghci -ignore-dot-ghci Panic.hs GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Panic.hs, interpreted ) Panic.hs:8:28: Couldn't match type ?a? with ?Int? ?a? is a rigid type variable bound by a pattern with constructor Fun :: forall b a. (a -> b) -> Exp a -> Exp b, in a pattern synonym declaration at Panic.hs:8:22 Expected type: Int -> Int Actual type: a -> Int Relevant bindings include b :: Exp a (bound at Panic.hs:8:28) a :: a -> Int (bound at Panic.hs:8:26) Failed, modules loaded: none. }}} So I try to be sneaky: {{{#!hs pattern IntFun :: (a ~ Int) => (a -> b) -> (Exp a -> Exp b) pattern IntFun f x = Fun f x -- % ghci -ignore-dot-ghci Panic.hs -- ? -- Couldn't match type ?a? with ?Int? -- ?a? is a rigid type variable bound by -- the type signature for IntFun :: (a1 -> b) -> Exp a1 -> Exp b -- at Panic.hs:8:22 }}} and if I constrain both type variables it panics {{{#!hs pattern IntFun :: (a ~ Int, b ~ Int) => (a -> b) -> (Exp a -> Exp b) pattern IntFun f x = Fun f x -- Couldn't match type ?b? with ?Int? -- ?b? is untouchable -- inside the constraints () -- bound by the type signature for -- IntFun :: (a1 -> b) -> Exp a1 -> Exp b -- at Panic.hs:8:9-14ghc: panic! (the 'impossible' happened) -- (GHC version 7.10.0.20150316 for i386-unknown-linux): -- No skolem info: b_alF[sk] -- -- Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The final version should look like: {{{#!hs type Name = String data Exp a where Fun :: Name -> (a -> b) -> (Exp a -> Exp b) ... pattern Suc :: Exp Int -> Exp Int pattern Suc n <- Fun _ _ n where Suc n = Fun "suc" (+ 1) n }}} Shouldn't this work? -- Comment: I can confirm the panic with ghc-7.11.20151019. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 18:31:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 18:31:04 -0000 Subject: [GHC] #10250: API Annotations : add Locations in hsSyn were layout occurs In-Reply-To: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> References: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> Message-ID: <059.280a621b9e917431cf3e146a3670bf2c@haskell.org> #10250: API Annotations : add Locations in hsSyn were layout occurs -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D815 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): Yes, it will remove a wart in the round-tripping process, at the cost of requiring CPP in ghc-exactprint. At this stage, I think it worth doing, for all the future versions to come. @mpickering, do you agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 18:33:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 18:33:49 -0000 Subject: [GHC] #10394: LLVM mangler doesn't mangle AVX instructions In-Reply-To: <047.b85b8723ab1fa78e7e23f08be8ccae23@haskell.org> References: <047.b85b8723ab1fa78e7e23f08be8ccae23@haskell.org> Message-ID: <062.49ea5b51f20d2b32c87885e1a248f506@haskell.org> #10394: LLVM mangler doesn't mangle AVX instructions -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1034 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): What is the status here. Fixed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 19:04:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 19:04:15 -0000 Subject: [GHC] #10390: Constraint order must match with RankNTypes In-Reply-To: <047.63f3af47f274c5481e6865e38f17f992@haskell.org> References: <047.63f3af47f274c5481e6865e38f17f992@haskell.org> Message-ID: <062.f0e016aed50ba8121ff49bcb7f7cb0df@haskell.org> #10390: Constraint order must match with RankNTypes -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.10.3 Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10390 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * testcase: => typecheck/should_compile/T10390 * resolution: => fixed * milestone: => 7.10.3 Comment: Already fixed. Milestone should really be 7.10.1 or 7.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 19:06:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 19:06:41 -0000 Subject: [GHC] #10388: GHC panic when compiling Yesod app In-Reply-To: <043.aed19344a06b3eee23932247443b10ff@haskell.org> References: <043.aed19344a06b3eee23932247443b10ff@haskell.org> Message-ID: <058.2552b8899d8046b9ef1c3c1dbe6564d7@haskell.org> #10388: GHC panic when compiling Yesod app -------------------------------------+------------------------------------- Reporter: chfi | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #10322 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #10322 Comment: Assuming this is indeed the same issue as #10322. Please reopen if this is still a problem! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 19:22:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 19:22:52 -0000 Subject: [GHC] #10380: "thread blocked indefinitely" exception while blocking on a socket In-Reply-To: <043.e2eff6afc40b5e20730c530fd6af2dce@haskell.org> References: <043.e2eff6afc40b5e20730c530fd6af2dce@haskell.org> Message-ID: <058.e0d6921719b96a315008a916c57fee57@haskell.org> #10380: "thread blocked indefinitely" exception while blocking on a socket -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #10317 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #10317 Comment: The example from the description works fine with 7.10.2. Assuming this was indeed a duplicate of #10317. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 20:13:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 20:13:26 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.8d993eda72a189a39fe520f78203d008@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, Wiki Page: | Phab:D1268 -------------------------------------+------------------------------------- Comment (by nomeata): > #10424 is related: "Build path leaks into ABI hashes". Are all tickets matching the regex `#[4012]+` related? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 20:15:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 20:15:18 -0000 Subject: [GHC] #10424: Build path leaks into ABI hashes In-Reply-To: <046.a66bd75799cab79a67d2ea94ef806de6@haskell.org> References: <046.a66bd75799cab79a67d2ea94ef806de6@haskell.org> Message-ID: <061.51ed9cfb0d8ddc8a47bd2c6581703109@haskell.org> #10424: Build path leaks into ABI hashes -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4012 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): JFTR, the Debian package of 7.10.2 in experimental is including this patch since a while: https://sources.debian.net/src/ghc/7.10.2-2/debian/patches /buildpath-abi-stability.patch/ So far, no bugs were reported, but I?m not sure how many users of the 7.10 package are out there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 20:16:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 20:16:58 -0000 Subject: [GHC] #10404: GHC panic when creating a monomorphised pattern synonym for GADT In-Reply-To: <051.7ba9349b8474f729185a50676c86da71@haskell.org> References: <051.7ba9349b8474f729185a50676c86da71@haskell.org> Message-ID: <066.356e676ac3306c18440c9eb8b4fc1104@haskell.org> #10404: GHC panic when creating a monomorphised pattern synonym for GADT -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: | PatternSynonyms Operating System: Linux | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The panic is bad but the original example fails to compile because there is a misunderstanding with the signature. The following program compiles. {{{ {-# LANGUAGE GADTs,PatternSynonyms #-} module Test where data Exp a where Fun :: (a -> b) -> (Exp a -> Exp b) pattern IntFun :: () => (a ~ Int) => (a -> b) -> (Exp a -> Exp b) pattern IntFun f x = Fun f x }}} Just giving one set of constraints correspond to provided constraints and an empty required constraints. In this case you want required constraints but empty provided constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 20:28:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 20:28:04 -0000 Subject: [GHC] #10975: At program exit, finalizer runs while foreign function is running In-Reply-To: <043.458893037bebf4938faaf143f16800cc@haskell.org> References: <043.458893037bebf4938faaf143f16800cc@haskell.org> Message-ID: <058.0d4712ff989c4ca0cb92e05023bf22ab@haskell.org> #10975: At program exit, finalizer runs while foreign function is running -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: 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 osa1): FWIW, I don't know why but marking "call" function `unsafe` prevents this(by default foreign functions are marked `safe`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 20:34:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 20:34:09 -0000 Subject: [GHC] #10457: Revise/remove custom mapM implementation for lists In-Reply-To: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> References: <044.1fa14ab770571abb07c789ec4259d0c5@haskell.org> Message-ID: <059.0fef972b575abf4cde096a614c0a30e6@haskell.org> #10457: Revise/remove custom mapM implementation for lists -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 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:D1124 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): JFTR: This instance of the regression has been fixed, because the `State` implementation got a sensible `Applicative` instance. The change in changeset:60297486/ghc still has the ability to regress any user code that has `(<*>) = ap`. OTOH, there is little we can do about it besides telling people to implement their Applicatives properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 20:39:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 20:39:00 -0000 Subject: [GHC] #10971: ExtendedDefaultRules defaults to [] for Foldable/Traversable In-Reply-To: <045.2898b5f70867473328360d4f8d9156ac@haskell.org> References: <045.2898b5f70867473328360d4f8d9156ac@haskell.org> Message-ID: <060.be1e306acc28a477222c6851473ea4c2@haskell.org> #10971: ExtendedDefaultRules defaults to [] for Foldable/Traversable -------------------------------------+------------------------------------- Reporter: kanetw | Owner: kanetw Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10963 | Differential Rev(s): phab:D1329 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"bb7e93c9c78bdf746e34cf6715eeffa6dd5682de/ghc" bb7e93c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bb7e93c9c78bdf746e34cf6715eeffa6dd5682de" Extended default rules now specialize Foldable, Traversable to [] (#10971) Default rules deliberately accept any kind. Reviewed By: simonpj, thomie, goldfire Differential Revision: https://phabricator.haskell.org/D1329 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 20:44:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 20:44:04 -0000 Subject: [GHC] #10971: ExtendedDefaultRules defaults to [] for Foldable/Traversable In-Reply-To: <045.2898b5f70867473328360d4f8d9156ac@haskell.org> References: <045.2898b5f70867473328360d4f8d9156ac@haskell.org> Message-ID: <060.ffed9cbaf2410147c3d767246cded661@haskell.org> #10971: ExtendedDefaultRules defaults to [] for Foldable/Traversable -------------------------------------+------------------------------------- Reporter: kanetw | Owner: kanetw Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10971a | typecheck/should_fail/T10971b | T10971d Blocked By: | Blocking: Related Tickets: #10963 | Differential Rev(s): phab:D1329 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => typecheck/should_compile/T10971a typecheck/should_fail/T10971b T10971d * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 21:00:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 21:00:00 -0000 Subject: [GHC] #10355: Dynamic linker not initialised In-Reply-To: <046.b020405a0b5eb69acc1047433b42d151@haskell.org> References: <046.b020405a0b5eb69acc1047433b42d151@haskell.org> Message-ID: <061.595c598bc0f59926192c57e51c7b613e@haskell.org> #10355: Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: dpiponi | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9868 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: dpiponi: could you check if this is still a problem with ghc-7.10.2? Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 21:48:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 21:48:44 -0000 Subject: [GHC] #10350: Should be able to specify path for eventlog output. In-Reply-To: <046.5c9ba8e32681deff5b385781c81731cc@haskell.org> References: <046.5c9ba8e32681deff5b385781c81731cc@haskell.org> Message-ID: <061.7515f1ed20f926bf9926fccd0cb65211@haskell.org> #10350: Should be able to specify path for eventlog output. -------------------------------------+------------------------------------- Reporter: literon | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.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 thomie): * type: bug => feature request Comment: Would you like to submit a patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 21:57:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 21:57:45 -0000 Subject: [GHC] #10334: __ctzdi2/si2/__clzdi2/si2 unknown symbols in ghc-prim on non-shared libs platform In-Reply-To: <046.e3ef261ac65799c1bb5faa4b0f1fb891@haskell.org> References: <046.e3ef261ac65799c1bb5faa4b0f1fb891@haskell.org> Message-ID: <061.4654db52bbb671b56a0ea6d57554c4ba@haskell.org> #10334: __ctzdi2/si2/__clzdi2/si2 unknown symbols in ghc-prim on non-shared libs platform -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.11 Resolution: | Keywords: 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 thomie): * cc: ekmett (added) * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 22:05:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 22:05:01 -0000 Subject: [GHC] #10320: -ddump-to-file should create empty dump files when there was nothing to dump In-Reply-To: <047.561f277130457f34a85813c7ce1004aa@haskell.org> References: <047.561f277130457f34a85813c7ce1004aa@haskell.org> Message-ID: <062.49ffafeb4ac99b83d5779cf194c05307@haskell.org> #10320: -ddump-to-file should create empty dump files when there was nothing to dump -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.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 thomie): * owner: MarceColl => Comment: Or just delete the old `foo.dump-rule-firings` file? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 22:08:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 22:08:49 -0000 Subject: [GHC] #10319: Eta expand PAPs In-Reply-To: <046.b3c3c7cd138df67521682745f755e763@haskell.org> References: <046.b3c3c7cd138df67521682745f755e763@haskell.org> Message-ID: <061.425d1cf41c9a1bdeb45ff7761ab6728a@haskell.org> #10319: Eta expand PAPs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 22:14:29 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 22:14:29 -0000 Subject: [GHC] #10311: package name returned from tyConPackage is garbled In-Reply-To: <049.befe981d27d5c4c24d07557f283ecb8b@haskell.org> References: <049.befe981d27d5c4c24d07557f283ecb8b@haskell.org> Message-ID: <064.b628b24ec2b153faa393b00650aedf88@haskell.org> #10311: package name returned from tyConPackage is garbled -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.10.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 thomie): * component: Compiler => Package system -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 22:18:22 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 22:18:22 -0000 Subject: [GHC] #10871: Implement "fat" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.4d43b3a732c71b2a1c4e5474360eae21@haskell.org> #10871: Implement "fat" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): SM, I think you have convinced me that eventually, we will need a version of cabal-install that is Backpack-aware, and has a work item in its install plan for each instantiated Backpack package. I am also going to claim this implementation of `cabal-install` is not going to be "simple". Let me first state an principle which we have both agreed is desirable: **It should be possible to build a Backpack unit without Cabal** (...assuming that all external dependencies have been built already.) This principle forces a few choices: **We need a separate file format for Backpack.** Suppose that we don't have a separate file format for Backpack, e.g. that all the Backpack information is recorded in a Cabal file (as it was in our older design from a year ago.) GHC can't parse a Cabal file, but it needs to know specifically what unit provides any module it wants to import. How can you get this info to GHC? 1. In our old design, you could pass a pile of `-package` flags with renamings to make sure every module name points to the correct module from the correct instantiated unit. Obviously this is completely unusable by hand; you'd need a tool which knows about Backpack to generate these flags. So much for using Backpack without Cabal! My advisor complained a lot about this, and that was the impetus that lead us down the route to fat interface files. 2. You could write any Backpack-specific information to its own file and pass that to GHC. This is a lot better! Now the only extra information you might need to pass is how the holes are to be instantiated (in case the unit is indefinite but you want to compile it). **It is GHC, not Cabal, who knows how to instantiate units.** Simple corollary of the above. And I also assume that we don't want to duplicate code, so this code for instantiation should only live in one place. Notice that in the old design, it was Cabal that had the Backpack smarts! But I think this was the wrong choice: GHC should have the Backpack smarts. **Cabal needs to ask GHC for information about how it instantiated units.** Since the code for unit instantiation lives in GHC, but each instantiated unit needs to get installed to the database (a Cabal concern), it follows that Cabal needs to call GHC in order to get information about how units are instantiated. This is directly relevant to cabal-install. Traditionally, cabal-install takes the package to be built, resolves the dependency graph, and then builds the dependency graph (now an install plan) in topological order. But if GHC, not Cabal, does instantiation, we don't know what the full set of instantiated units a Backpack package needs until after we have configured it. Essentially, as we process packages in the install plan, after we configure, we have to ask GHC to tell us what other dependencies are needed, and then splice those dependencies into the install plan as extra targets that must be built. This is further complicated by the fact that the Cabal library may be embedded in a custom Setup script; in which case we have to define an interchange format between Cabal and cabal-install to communicate this information. I don't think this is the wrong way to do it, but it will take work to implement. Let me argue for fat interface files one more time. One of my top priorities at this stage is to get Backpack working "just enough" so that we can roll it out and let users (including me) play with it and use it for real applications. So if there is a way to get thing working today (maybe not entirely the Right(TM) way) in a way that doesn't impair our ability to make it work right later, I would quite like to take it. Fat interfaces are a way to get Backpack integrated with the Cabal ecosystem without having to rewrite cabal-install's install plan runner, make it easier to experiment with Backpack, have the property, "If you don't care about it, you don't have to", and most importantly, is mostly implemented at this point. This discussion has also reminded me that there is still an elephant in the room with regards to recompilation avoidance in Backpack. In a package model, GHC will not recompile if the package key of the depended upon package has not changed. Since we don't generally expect package keys to change on an edit/recompile cycle, it's unsound to keep around build files from an old compilation. This means that you end up doing a lot of recompiling with Cabal today when you change a package that is depended upon by other packages you are building. In fact, we want something like this: we don't *care* about recompilation avoidance when we are installing, but if we are edit/rebuilding, we want accurate recompilation avoidance for the entire set of packages which we may be editing and building. This sounds exactly like the "local package database" that we end up creating when compiling Backpack units using fat interfaces. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 22:20:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 22:20:57 -0000 Subject: [GHC] #10301: Plugins/dynamic loading subtly broken (it seems) In-Reply-To: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> References: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> Message-ID: <067.c6509b072c9b9952d7ed0374a2a33413@haskell.org> #10301: Plugins/dynamic loading subtly broken (it seems) -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | plugins/T10294 Blocked By: | Blocking: Related Tickets: #8276 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * os: Windows => Unknown/Multiple Comment: Not Windows only. `DYNAMIC_GHC_PROGRAMS=NO` is needed to trigger the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 22:25:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 22:25:16 -0000 Subject: [GHC] #10296: Segfaults when using dynamic wrappers and concurrency In-Reply-To: <046.5415c655699223aa287cb69e9ee1b595@haskell.org> References: <046.5415c655699223aa287cb69e9ee1b595@haskell.org> Message-ID: <061.b23e93b1a1351959ac84e03b38a983e4@haskell.org> #10296: Segfaults when using dynamic wrappers and concurrency -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 Resolution: | Keywords: 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 thomie): * cc: simonmar (added) * priority: normal => high * component: Compiler => Runtime System * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 22:47:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 22:47:04 -0000 Subject: [GHC] #10994: Test failing with DYNAMIC_GHC_PROGRAMS = NO Message-ID: <044.42dbe48749121c55fde6256f3a4f4246@haskell.org> #10994: Test failing with DYNAMIC_GHC_PROGRAMS = NO -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Test Suite | Version: 7.11 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: -------------------------------------+------------------------------------- Current git HEAD has failing tests after Phab:D975 when compiling with `DYNAMIC_GHC_PROGRAMS = NO`. {{{ Unexpected failures: ghci.debugger/scripts break001 [bad exit code] (ghci) ghci.debugger/scripts break005 [bad exit code] (ghci) ghci.debugger/scripts break006 [bad exit code] (ghci) ghci.debugger/scripts break011 [bad exit code] (ghci) ghci.debugger/scripts break017 [bad exit code] (ghci) ghci.debugger/scripts dynbrk007 [bad exit code] (ghci) ghci.debugger/scripts hist001 [bad exit code] (ghci) ghci.debugger/scripts print001 [bad exit code] (ghci) ghci.debugger/scripts print002 [bad exit code] (ghci) ghci.debugger/scripts print003 [bad exit code] (ghci) ghci.debugger/scripts print004 [bad exit code] (ghci) ghci.debugger/scripts print005 [bad exit code] (ghci) ghci.debugger/scripts print006 [bad exit code] (ghci) ghci.debugger/scripts print008 [bad exit code] (ghci) ghci.debugger/scripts print010 [bad exit code] (ghci) ghci.debugger/scripts print011 [bad exit code] (ghci) ghci.debugger/scripts print012 [bad exit code] (ghci) ghci.debugger/scripts print013 [bad exit code] (ghci) ghci.debugger/scripts print016 [bad exit code] (ghci) ghci.debugger/scripts print017 [bad exit code] (ghci) ghci.debugger/scripts print019 [bad exit code] (ghci) ghci.debugger/scripts print020 [bad exit code] (ghci) ghci.debugger/scripts print023 [bad exit code] (ghci) ghci.debugger/scripts print024 [bad exit code] (ghci) ghci.debugger/scripts print026 [bad exit code] (ghci) ghci.debugger/scripts print028 [bad exit code] (ghci) ghci.debugger/scripts print031 [bad exit code] (ghci) ghci.debugger/scripts print032 [bad exit code] (ghci) ghci.debugger/scripts print034 [bad exit code] (ghci) ghci/scripts T2976 [bad exit code] (ghci) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 22:48:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 22:48:54 -0000 Subject: [GHC] #10271: Typed Template Haskell splice difficulty when resolving overloading In-Reply-To: <046.badc08a7987a9ad09aee9fd76d6b2f30@haskell.org> References: <046.badc08a7987a9ad09aee9fd76d6b2f30@haskell.org> Message-ID: <061.9d2c046fd62f19b2939f00f441cb5a53@haskell.org> #10271: Typed Template Haskell splice difficulty when resolving overloading -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.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 thomie): * component: Compiler => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 23:09:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 23:09:05 -0000 Subject: [GHC] #10994: Test failing with DYNAMIC_GHC_PROGRAMS = NO In-Reply-To: <044.42dbe48749121c55fde6256f3a4f4246@haskell.org> References: <044.42dbe48749121c55fde6256f3a4f4246@haskell.org> Message-ID: <059.bc10a7a1fdaada992866fbfda9e00932@haskell.org> #10994: Test failing with DYNAMIC_GHC_PROGRAMS = NO -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Minimal test case to reproduce this is: {{{ inplace/bin/ghc-stage2 -fno-ghci-history --interactive -v0 -ignore-dot- ghci \ +RTS -I0.1 -RTS < testsuite/tests/ghci/scripts/T2976.script }}} Dropping the `+RTS -I0.1 -RTS` part will cause the test to pass. This suggests that the segfault happens when the GC runs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 20 23:50:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Oct 2015 23:50:34 -0000 Subject: [GHC] #10994: GHCi segfaults when built with DYNAMIC_GHC_PROGRAMS = NO (was: Test failing with DYNAMIC_GHC_PROGRAMS = NO) In-Reply-To: <044.42dbe48749121c55fde6256f3a4f4246@haskell.org> References: <044.42dbe48749121c55fde6256f3a4f4246@haskell.org> Message-ID: <059.e28695b7a3e15287b1afa7a596b77a32@haskell.org> #10994: GHCi segfaults when built with DYNAMIC_GHC_PROGRAMS = NO -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Test Suite | Version: 7.11 Resolution: | Keywords: 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 Oct 21 00:10:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 00:10:31 -0000 Subject: [GHC] #10994: GHCi segfaults when built with DYNAMIC_GHC_PROGRAMS = NO In-Reply-To: <044.42dbe48749121c55fde6256f3a4f4246@haskell.org> References: <044.42dbe48749121c55fde6256f3a4f4246@haskell.org> Message-ID: <059.fa51a3f2243d8228cf5d02b13e427e26@haskell.org> #10994: GHCi segfaults when built with DYNAMIC_GHC_PROGRAMS = NO -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Running it in GDB gave the usual useless backtrace. Just as a test I compiled GHC unregisterised to see if it still segfaults like that (which would give me a backtrace), but it doesn't segfault when compiled unregisterised. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 04:33:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 04:33:21 -0000 Subject: [GHC] #10469: ghc crash on arm with -j2: internal error: scavenge: unimplemented/strange closure type In-Reply-To: <047.60fe47838743a4cb466668b7b2d86836@haskell.org> References: <047.60fe47838743a4cb466668b7b2d86836@haskell.org> Message-ID: <062.7a9fcc89ae9497b703d72996bf394cf1@haskell.org> #10469: ghc crash on arm with -j2: internal error: scavenge: unimplemented/strange closure type ---------------------------------------+------------------------------ Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------------+------------------------------ Comment (by joeyhess): Thanks for looking into this erik. But would forcing hf mean ghc can't be used on regular eabi arm systems? Debian is still targeting eabi in its armel architecture. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 04:45:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 04:45:39 -0000 Subject: [GHC] #10995: Existentials in newtypes Message-ID: <047.143918d29abaf7f99fa5e194222eda4a@haskell.org> #10995: Existentials in newtypes -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code compiles: {{{ {-# LANGUAGE ConstraintKinds, TypeFamilies, RankNTypes, PolyKinds, KindSignatures #-} import GHC.Prim import Data.Proxy type family Ctx2 ctx a b :: Constraint newtype Proxy1 c a = P1 (forall b . Ctx2 c a b => Proxy b -> Int) }}} but if I explicitly poly-kind `Ctx2`: `type family Ctx2 ctx a (b :: k) :: Constraint` I get the errors {{{ Main.hs:10:22: Could not deduce (b ~ b0) from the context (Ctx2 c a b) bound by the type of the constructor ?P1?: Ctx2 c a b => Proxy b -> Int at Main.hs:10:22 ?b? is a rigid type variable bound by the type of the constructor ?P1?: Ctx2 c a b => Proxy b -> Int at Main.hs:10:22 Expected type: Proxy b -> Int Actual type: Proxy b0 -> Int In the ambiguity check for the type of the constructor ?P1?: P1 :: forall c a (k :: BOX). (forall (b :: k). Ctx2 c a b => Proxy b -> Int) -> Proxy1 c a To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the definition of data constructor ?P1? In the newtype declaration for ?Proxy1? Main.hs:10:22: A newtype constructor cannot have existential type variables P1 :: forall c a (k :: BOX). (forall (b :: k). Ctx2 c a b => Proxy b -> Int) -> Proxy1 c a In the definition of data constructor ?P1? In the newtype declaration for ?Proxy1? }}} It seems like the code should compile, but I might be missing something. This ticket is really about the second error message: there were existential types in a newtype before and after the change, so this error should occur in both places or neither. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 05:00:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 05:00:01 -0000 Subject: [GHC] #10996: family is treated as keyword in types even without TypeFamilies enabled Message-ID: <045.27f49ff532e9a720de796a9ae0ad68ae@haskell.org> #10996: family is treated as keyword in types even without TypeFamilies enabled -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: type Test | Blocked By: family = family | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following is as far as I know correct H2010 code, but breaks in GHC: {{{ GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> type Test family = family :2:11: parse error on input `family' Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 05:38:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 05:38:22 -0000 Subject: [GHC] #10996: family is treated as keyword in types even without TypeFamilies enabled In-Reply-To: <045.27f49ff532e9a720de796a9ae0ad68ae@haskell.org> References: <045.27f49ff532e9a720de796a9ae0ad68ae@haskell.org> Message-ID: <060.46a73e838e78b2a229b745bf01c7df42@haskell.org> #10996: family is treated as keyword in types even without TypeFamilies enabled -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: type Test valid program | family = family Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by oerjan): Just as a musing, I think it ''might'' just be possible to treat `family` entirely as a non-keyword like `as` or `hiding`. The only kind of ambiguity I can think of that requires lookahead is with `TypeOperators` enabled and {{{ type family MyTypeFamily a b = ... type family :~: work = ... }}} but even then, it is disambiguated by whether the next token is an identifier or an operator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 05:49:19 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 05:49:19 -0000 Subject: [GHC] #10994: GHCi segfaults when built with DYNAMIC_GHC_PROGRAMS = NO In-Reply-To: <044.42dbe48749121c55fde6256f3a4f4246@haskell.org> References: <044.42dbe48749121c55fde6256f3a4f4246@haskell.org> Message-ID: <059.2a13ebb810cce52d4a0e8f2b67ea35b7@haskell.org> #10994: GHCi segfaults when built with DYNAMIC_GHC_PROGRAMS = NO -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * cc: simonmar (added) * component: Test Suite => Runtime System (Linker) Comment: Adding @simonmar (hope thats ok). I've done a code review and the only thing I can find which is obvioulsy not what you intended is the function `getPageSize`. I think you meant something like: {{{ static StgWord getPageSize(void) { static StgWord pagesize = 0; if (pagesize == 0) { pagesize = sysconf(_SC_PAGESIZE); } return pagesize; } }}} I'm willing to do a lot of the legwork on getting this fixed but would appreciated nudge in the right direction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 06:39:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 06:39:51 -0000 Subject: [GHC] #10994: GHCi segfaults when built with DYNAMIC_GHC_PROGRAMS = NO In-Reply-To: <044.42dbe48749121c55fde6256f3a4f4246@haskell.org> References: <044.42dbe48749121c55fde6256f3a4f4246@haskell.org> Message-ID: <059.b968c66488263ce875172690ed50f201@haskell.org> #10994: GHCi segfaults when built with DYNAMIC_GHC_PROGRAMS = NO -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by olsner): * cc: olsner (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 07:43:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 07:43:28 -0000 Subject: [GHC] #10995: Existentials in newtypes In-Reply-To: <047.143918d29abaf7f99fa5e194222eda4a@haskell.org> References: <047.143918d29abaf7f99fa5e194222eda4a@haskell.org> Message-ID: <062.3d6709baa5c7c9965178b09d255cb46d@haskell.org> #10995: Existentials in newtypes -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10715 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: goldfire (added) * component: Compiler => Compiler (Type checker) * related: => #10715 Comment: HEAD also compiles your first example without errors. Your second example results in the error messages below. The `pprTrace "RAE1"` is from 2f9809efdbc11fee445dbe3d5c555433ec3c5e6a (#10715). {{{ $ ghc-7.11.20151019 Test.hs [1 of 1] Compiling Test ( Test.hs, Test.o ) RAE1 [W] cobox_apw :: k0_apq[tau:3] ~ k_apn[sk] (CNonCanonical) k0_apq[tau:3] k_apn[sk] False Test.hs:10:22: error: Couldn't match kind ?k0? with ?k? ?k0? is untouchable inside the constraints: Ctx2 c a b bound by the type of the constructor ?P1?: Ctx2 c a b => Proxy b -> Int at Test.hs:10:22 ?k? is a rigid type variable bound by the type of the constructor ?P1?: (forall (b :: k). Ctx2 c a b => Proxy b -> Int) -> Proxy1 c a at Test.hs:10:22 Expected type: Proxy b -> Int Actual type: Proxy b -> Int In the ambiguity check for the type of the constructor ?P1?: P1 :: forall c a (k :: BOX). (forall (b :: k). Ctx2 c a b => Proxy b -> Int) -> Proxy1 c a To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the definition of data constructor ?P1? In the newtype declaration for ?Proxy1? Test.hs:10:22: error: Could not deduce: Ctx2 c a b from the context: Ctx2 c a b bound by the type of the constructor ?P1?: Ctx2 c a b => Proxy b -> Int at Test.hs:10:22 In the ambiguity check for the type of the constructor ?P1?: P1 :: forall c a (k :: BOX). (forall (b :: k). Ctx2 c a b => Proxy b -> Int) -> Proxy1 c a To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the definition of data constructor ?P1? In the newtype declaration for ?Proxy1? Test.hs:10:22: error: A newtype constructor cannot have existential type variables P1 :: forall c a (k :: BOX). (forall (b :: k). Ctx2 c a b => Proxy b -> Int) -> Proxy1 c a In the definition of data constructor ?P1? In the newtype declaration for ?Proxy1? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 07:59:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 07:59:21 -0000 Subject: [GHC] #10994: GHCi segfaults when built with DYNAMIC_GHC_PROGRAMS = NO In-Reply-To: <044.42dbe48749121c55fde6256f3a4f4246@haskell.org> References: <044.42dbe48749121c55fde6256f3a4f4246@haskell.org> Message-ID: <059.db7ed23f9d4b1d8bbffc56ff43edf467@haskell.org> #10994: GHCi segfaults when built with DYNAMIC_GHC_PROGRAMS = NO -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Thanks, I'll look into this today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 07:59:34 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 07:59:34 -0000 Subject: [GHC] #10994: GHCi segfaults when built with DYNAMIC_GHC_PROGRAMS = NO In-Reply-To: <044.42dbe48749121c55fde6256f3a4f4246@haskell.org> References: <044.42dbe48749121c55fde6256f3a4f4246@haskell.org> Message-ID: <059.ad8829cf860d4066810898aea68d06a1@haskell.org> #10994: GHCi segfaults when built with DYNAMIC_GHC_PROGRAMS = NO -------------------------------------+------------------------------------- Reporter: erikd | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 08:34:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 08:34:41 -0000 Subject: [GHC] #8957: ghci's :l -> internal error: evacuate: strange closure type 8306 In-Reply-To: <044.563d8e81c14de09a7df4021e1ba0119d@haskell.org> References: <044.563d8e81c14de09a7df4021e1ba0119d@haskell.org> Message-ID: <059.51d99ada3d37fe6dc6fb2916614fbbdb@haskell.org> #8957: ghci's :l -> internal error: evacuate: strange closure type 8306 -------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Unfortunately GHC 7.6.3 is no longer supported. Since this bug is not reproducible, and we haven't seen these "strange closure type" panics at all in the 7.10 series, I'm going to assume this is fixed and close this ticket. Please reopen if you run into this problem again. And thank you for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 08:36:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 08:36:03 -0000 Subject: [GHC] #8687: Strange closure type 9983 In-Reply-To: <042.e67240730f3538eb274d4089a3c1c88e@haskell.org> References: <042.e67240730f3538eb274d4089a3c1c88e@haskell.org> Message-ID: <057.a9110667908284f822baadaf71fd2893@haskell.org> #8687: Strange closure type 9983 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: worksforme | 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 thomie): * status: new => closed * resolution: => worksforme Comment: Since this bug is not reproducible, and we haven't seen these "strange closure type" panics at all in the 7.10 series, I'm going to assume this is fixed and close this ticket. Thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 08:36:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 08:36:57 -0000 Subject: [GHC] #8687: Strange closure type 9983 In-Reply-To: <042.e67240730f3538eb274d4089a3c1c88e@haskell.org> References: <042.e67240730f3538eb274d4089a3c1c88e@haskell.org> Message-ID: <057.c924e035e9427a155993ce0bbcc53472@haskell.org> #8687: Strange closure type 9983 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #10258, #8957 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #10258, #8957 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 08:37:20 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 08:37:20 -0000 Subject: [GHC] #8957: ghci's :l -> internal error: evacuate: strange closure type 8306 In-Reply-To: <044.563d8e81c14de09a7df4021e1ba0119d@haskell.org> References: <044.563d8e81c14de09a7df4021e1ba0119d@haskell.org> Message-ID: <059.f8edc5e46080c406724b8962c657c979@haskell.org> #8957: ghci's :l -> internal error: evacuate: strange closure type 8306 ----------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #10258, #8687 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by thomie): * related: => #10258, #8687 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 08:42:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 08:42:58 -0000 Subject: [GHC] #10870: PPC.Ppr: Shift by 32 bits is not allowed. In-Reply-To: <046.266af0561f46fb382b81907ac208339a@haskell.org> References: <046.266af0561f46fb382b81907ac208339a@haskell.org> Message-ID: <061.038bf702e5066682dc599df2b5f78b26@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler (CodeGen) | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1322 Wiki Page: | ---------------------------------------+---------------------------------- Comment (by trommler): Replying to [comment:9 erikd]: > The commit in the `master` branch doesn't apply to the `7.10` branch because of all the `powerpc64el` work in `master`. Speaking of 64-bit: I suppose I should implement shifts by 64 bit in a similar fashion for 64-bit PowerPC. I'll create a new ticket for that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 08:50:09 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 08:50:09 -0000 Subject: [GHC] #10258: internal error: evacuate: strange closure type 3269 In-Reply-To: <047.cc59713a7da2897a27b68eb8f93d7d29@haskell.org> References: <047.cc59713a7da2897a27b68eb8f93d7d29@haskell.org> Message-ID: <062.70850dad4671f6835c79addb934dfff5@haskell.org> #10258: internal error: evacuate: strange closure type 3269 ---------------------------------+---------------------------------------- Reporter: lukaramu | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: worksforme | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #8687, #8957 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme * related: => #8687, #8957 Comment: Since this bug is not reproducible, and we haven't seen these "strange closure type" panics at all in the 7.10 series, I'm going to assume this is fixed and close this ticket. Thanks for reporting, and do reopen if you see it again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 09:13:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 09:13:15 -0000 Subject: [GHC] #10249: GHCi leaky abstraction: error message mentions `ghciStepIO` (was: Suboptimal error message with deferred type errors) In-Reply-To: <051.818ff8bc84030bedfa7f9663d4a7c3ef@haskell.org> References: <051.818ff8bc84030bedfa7f9663d4a7c3ef@haskell.org> Message-ID: <066.ae9e14ef91f3a9bf5ef794fbf1d1a7a1@haskell.org> #10249: GHCi leaky abstraction: error message mentions `ghciStepIO` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.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 thomie): * type: feature request => bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 09:48:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 09:48:59 -0000 Subject: [GHC] #10994: GHCi segfaults when built with DYNAMIC_GHC_PROGRAMS = NO In-Reply-To: <044.42dbe48749121c55fde6256f3a4f4246@haskell.org> References: <044.42dbe48749121c55fde6256f3a4f4246@haskell.org> Message-ID: <059.c573469d865385ba459285292316bc79@haskell.org> #10994: GHCi segfaults when built with DYNAMIC_GHC_PROGRAMS = NO -------------------------------------+------------------------------------- Reporter: erikd | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D1346, D1345 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * differential: => D1346, D1345 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 09:49:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 09:49:14 -0000 Subject: [GHC] #10994: GHCi segfaults when built with DYNAMIC_GHC_PROGRAMS = NO In-Reply-To: <044.42dbe48749121c55fde6256f3a4f4246@haskell.org> References: <044.42dbe48749121c55fde6256f3a4f4246@haskell.org> Message-ID: <059.7195d0afffed7b838cc230b261e23d75@haskell.org> #10994: GHCi segfaults when built with DYNAMIC_GHC_PROGRAMS = NO -------------------------------------+------------------------------------- Reporter: erikd | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1346, Wiki Page: | Phab:D1345 -------------------------------------+------------------------------------- Changes (by simonmar): * differential: D1346, D1345 => Phab:D1346, Phab:D1345 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 09:59:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 09:59:42 -0000 Subject: [GHC] #10242: Multiple constraint wildcards allowed with PartialTypeSignatures In-Reply-To: <049.a953ada63cab8a32d81242f76b55213a@haskell.org> References: <049.a953ada63cab8a32d81242f76b55213a@haskell.org> Message-ID: <064.8ad092d5134343cbdbe2b2818649e299@haskell.org> #10242: Multiple constraint wildcards allowed with PartialTypeSignatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: thomasw Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: | PartialTypeSignatures Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: partial- invalid program | sigs/should_fail/ExtraConstraintsWildcardTwice Blocked By: | Blocking: Related Tickets: #10098 | Differential Rev(s): Phab:D613 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * testcase: => partial-sigs/should_fail/ExtraConstraintsWildcardTwice * resolution: => fixed * milestone: => 7.10.3 Comment: Already fixed. Milestone should really be 7.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 10:07:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 10:07:12 -0000 Subject: [GHC] #10225: GHC does not specialize based on type equality In-Reply-To: <046.56c40228dad7f1d8895238a61375d58f@haskell.org> References: <046.56c40228dad7f1d8895238a61375d58f@haskell.org> Message-ID: <061.a41ff53bd7371627e5c19eb4b806abc7@haskell.org> #10225: GHC does not specialize based on type equality -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 thomie): * status: new => infoneeded * failure: None/Unknown => Runtime performance bug Comment: yongqli: can you supply a test case? Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 11:07:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 11:07:08 -0000 Subject: [GHC] #10996: family is treated as keyword in types even without TypeFamilies enabled In-Reply-To: <045.27f49ff532e9a720de796a9ae0ad68ae@haskell.org> References: <045.27f49ff532e9a720de796a9ae0ad68ae@haskell.org> Message-ID: <060.9775bff84b501e0218d00be848dfd600@haskell.org> #10996: family is treated as keyword in types even without TypeFamilies enabled -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: type Test valid program | family = family Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Indeed. In `Parser.y` we see: {{{ tyvarid :: { Located RdrName } : VARID { sL1 $1 $! mkUnqual tvName (getVARID $1) } | special_id { sL1 $1 $! mkUnqual tvName (unLoc $1) } | 'unsafe' { sL1 $1 $! mkUnqual tvName (fsLit "unsafe") } | 'safe' { sL1 $1 $! mkUnqual tvName (fsLit "safe") } | 'interruptible' { sL1 $1 $! mkUnqual tvName (fsLit "interruptible") } varid :: { Located RdrName } : VARID { sL1 $1 $! mkUnqual varName (getVARID $1) } | special_id { sL1 $1 $! mkUnqual varName (unLoc $1) } | 'unsafe' { sL1 $1 $! mkUnqual varName (fsLit "unsafe") } | 'safe' { sL1 $1 $! mkUnqual varName (fsLit "safe") } | 'interruptible' { sL1 $1 $! mkUnqual varName (fsLit "interruptible")} | 'forall' { sL1 $1 $! mkUnqual varName (fsLit "forall") } | 'family' { sL1 $1 $! mkUnqual varName (fsLit "family") } | 'role' { sL1 $1 $! mkUnqual varName (fsLit "role") } -- These special_ids are treated as keywords in various places, -- but as ordinary ids elsewhere. 'special_id' collects all these -- except 'unsafe', 'interruptible', 'forall', 'family', and 'role', -- whose treatment differs depending on context special_id :: { Located FastString } special_id : 'as' { sL1 $1 (fsLit "as") } | 'qualified' { sL1 $1 (fsLit "qualified") } | 'hiding' { sL1 $1 (fsLit "hiding") } | 'export' { sL1 $1 (fsLit "export") } | 'label' { sL1 $1 (fsLit "label") } | 'dynamic' { sL1 $1 (fsLit "dynamic") } | 'stdcall' { sL1 $1 (fsLit "stdcall") } | 'ccall' { sL1 $1 (fsLit "ccall") } | 'capi' { sL1 $1 (fsLit "capi") } | 'prim' { sL1 $1 (fsLit "prim") } | 'javascript' { sL1 $1 (fsLit "javascript") } | 'group' { sL1 $1 (fsLit "group") } }}} The idea of `special_id` is a good one, because it avoids stealing keywords. The comment claims that 'unsafe', 'safe', and 'interruptible' have treatment that varies by context; but that claim seems bogus. The ONLY uses of `special_id` is the code above, so adding those three to `special_id` and removing them from `varid` and `tyvarid` should be a useful simplification. Can someone try? 'forall' is different because in ''terms'' it is not a keyword, but in ''types'' it is. The lexer therefore only recognises it when specific flags are on. 'role' and 'family' are the warts. Can we put them in `special_id`? I think (but I am not certain) that the reason they are not there is to exclude them from `tyvarid`. Why do that? I think (but I am not sure) that the reason is to resolve the ambiguity in comment:1. If someone felt able to resolve that ambiguity some other way, it'd be great. Otherwise this really is a bug. This isn't really hard, I think; just needs someone to to think clearly for a while. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 11:22:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 11:22:23 -0000 Subject: [GHC] #10607: Auto derive from top to bottom In-Reply-To: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> References: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> Message-ID: <060.9fa2893b80bc57a825aac0034ac06795@haskell.org> #10607: Auto derive from top to bottom -------------------------------------+------------------------------------- Reporter: songzh | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: deriving, | typeclass, auto Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by songzh): Replying to [comment:7 goldfire]: > Replying to [comment:6 songzh]: > > > > 1. It forces me to use `KindSignatures`, `ConstraintKind` and other extension which should not be needed.(please see `TopDownDeriveTest.hs` file) > > Fair enough. But, in truth, you ''might'' need these extensions, depending on the definitions of types you are deriving for. One way forward here is to allow Template Haskell to turn on some extensions just within a splice, instead of specifying them at the top of a file. (This actually shouldn't be hard, once #10820 is complete.) > 1. Thanks very much. I will watch the ticket. > > > > 2. For type synonym, I want to do it without using TypeSynonymInstance, but I am not sure how to get the arity of a type constructor. For example: `type T a = (a,a,a,a,a)` I need to generate (Eq a , Eq b, Eq c ,Eq d, Eq e) => (a,b,c,d,e). However, the type synonym can be eta reduced, what should do to handle this case? > > I'm not sure what the problem is here. Are you worried about deriving, say, `Functor`, for which the eta reduction is necessary? But your example actually cannot be eta-reduced, because the variable `a` is used multiple times in the RHS. So I'm not sure what you're getting at on this one. > > > 2. I will try to solve it, just not sure about how to handle `TySynD` case. {{{ getTyVarCons :: Name -> Q ([TyVarBndr], [Con]) getTyVarCons name = do info <- reify name case info of TyConI dec -> case dec of DataD _ _ tvbs cons _ -> return (tvbs,cons) NewtypeD _ _ tvbs con _ -> return (tvbs,[con]) TySynD _ vars type' -> undefined -- need to handle type eta reduction _ -> error "must be data, newtype definition or type synonym!" _ -> error "bad type name, quoted name is not a type!" }}} You can see that I am not sure how to handle `TySynD` case. If the user declares {{{ data A a b c = A a b c type A' a = A a String a }}} > > 3. When I derive some instances that based on Generic class like Binary or FromJSON it gives me a type error: > > > > {{{ > > Could not deduce (G.Generic a) > > arising from a use of `binary-0.7.6.1:Data.Binary.Class.$gdmget' > > from the context (B.Binary a) > > bound by the instance declaration > > }}} > > > > while I think `deriving instance (Binary a ,Binary b) => Binary (A a b)` should work fine. Why do I have to write `deriving instance (B.Binary a, G.Generic a) => (B.Binary (B a))`? And could you give me some suggestions to solve it. > > I'm a little lost here. What's the code being type-checked? What's `A`? What's `B`? Does the error happen both with and without TH? Or only when using TH? 3. Sorry for confusing you. Normmally, I derive the type classes in the following way: {{{ {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE DeriveAnyClass #-} import qualified GHC.Generics as G import qualified Data.Binary as B data C a b = A (B a) deriving (Eq, G.Generic, Ord) data B a = B a | F (D a) deriving (Eq, G.Generic, Ord) data D b = D b | E b deriving (Eq, G.Generic, Ord) deriving instance B.Binary b => B.Binary (D b) deriving instance B.Binary a => B.Binary (B a) deriving instance (B.Binary a , B.Binary b) => (B.Binary (C a b)) }}} For standalone deriving `(B.Binary (C a b))`, I do not need to give `G.Generic a` and `G.Generic b` in its context. However, if I derive `G.Generic` for `C` by using standalone deriving, GHC complains that I did not give `G.Generic` in context `(B.Binary a, B.Binary b)` {{{ {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE DeriveAnyClass #-} import qualified GHC.Generics as G import qualified Data.Binary as B data C a b = A (B a) deriving (Eq, Ord) data B a = B a | F (D a) deriving (Eq, G.Generic, Ord) data D b = D b | E b deriving (Eq, G.Generic, Ord) deriving instance (G.Generic a, G.Generic b) => (G.Generic (C a b)) deriving instance B.Binary b => B.Binary (D b) deriving instance B.Binary a => B.Binary (B a) deriving instance (B.Binary a , B.Binary b) => (B.Binary (C a b)) }}} This means that I have to discriminate generic standalone deriving(i.e. with `G.Generic` context) and non-generic standalone deriving(i.e. without `G.Generic` context), which is not very nice. Are there any way to solve this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 11:33:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 11:33:43 -0000 Subject: [GHC] #10469: ghc crash on arm with -j2: internal error: scavenge: unimplemented/strange closure type In-Reply-To: <047.60fe47838743a4cb466668b7b2d86836@haskell.org> References: <047.60fe47838743a4cb466668b7b2d86836@haskell.org> Message-ID: <062.a40efd8152b801788d31832d450d011a@haskell.org> #10469: ghc crash on arm with -j2: internal error: scavenge: unimplemented/strange closure type ---------------------------------------+------------------------------ Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------------+------------------------------ Comment (by erikd): Ah ok. The patch currently forces `armv6-unknown-linux-gnueabihf`, but the `hf` is not the important bit. The important bit is to make sure the C code and Haskell code both get compiled to Arm instructions and not Thumb2 instructions. I suppose what we really need is two distinct but related architectures; `armv6-unknown-linux-gnueabihf` and something `armel` related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 11:51:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 11:51:16 -0000 Subject: [GHC] #10997: Pattern synonym causes Iface error. Message-ID: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> #10997: Pattern synonym causes Iface error. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From the mailing list.. Hello, We have a pattern synonym as follows type family Showable (a :: k) :: Constraint where Showable (a :: *) = (Show a) Showable a = () pattern Just' :: () => (Showable a) => a -> (Maybe a) pattern Just' a <- (extractJust -> (True, a)) where Just' a = Just a When we try to use the pattern in a different package, the error was [1 of 1] Compiling Bar ( Bar.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Bar.o ) /tmp/test/p2/.stack- work/install/x86_64-linux/lts-3.5/7.10.2/lib/x86_64-linux- ghc-7.10.2/p1-0.1.0.0-I5t4il6dN7vIqsT1XgYsM3/Foo.hi Declaration for Just' Pattern synonym Just': Iface type variable out of scope: k Cannot continue after interface file error The error only occurred when Showable was polykinded and we used synonym in a different package . Using the synonym in the same package works fine. This problem did not happen with the following definition of (non polykinded ) Showable type family Showable a :: Constraint where Showable a = (Show a) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 11:51:45 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 11:51:45 -0000 Subject: [GHC] #10997: Pattern synonym causes Iface error. In-Reply-To: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> References: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> Message-ID: <064.a1398e57b4d6d2f91ebdbdfb24d168b1@haskell.org> #10997: Pattern synonym causes Iface error. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by mpickering: Old description: > From the mailing list.. > > Hello, > > We have a pattern synonym as follows > > type family Showable (a :: k) :: Constraint where > Showable (a :: *) = (Show a) > Showable a = () > > pattern Just' :: () => (Showable a) => a -> (Maybe a) > pattern Just' a <- (extractJust -> (True, a)) where > Just' a = Just a > > When we try to use the pattern in a different package, the error was > > [1 of 1] Compiling Bar ( Bar.hs, .stack- > work/dist/x86_64-linux/Cabal-1.22.4.0/build/Bar.o ) > /tmp/test/p2/.stack- > work/install/x86_64-linux/lts-3.5/7.10.2/lib/x86_64-linux- > ghc-7.10.2/p1-0.1.0.0-I5t4il6dN7vIqsT1XgYsM3/Foo.hi > Declaration for Just' > Pattern synonym Just': > Iface type variable out of scope: k > Cannot continue after interface file error > > The error only occurred when Showable was polykinded and we used synonym > in a different package . Using the synonym in the same package works > fine. > > This problem did not happen with the following definition of (non > polykinded ) Showable > > type family Showable a :: Constraint where > Showable a = (Show a) New description: From the mailing list.. Hello, We have a pattern synonym as follows {{{ type family Showable (a :: k) :: Constraint where Showable (a :: *) = (Show a) Showable a = () pattern Just' :: () => (Showable a) => a -> (Maybe a) pattern Just' a <- (extractJust -> (True, a)) where Just' a = Just a }}} When we try to use the pattern in a different package, the error was {{{ [1 of 1] Compiling Bar ( Bar.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Bar.o ) /tmp/test/p2/.stack- work/install/x86_64-linux/lts-3.5/7.10.2/lib/x86_64-linux- ghc-7.10.2/p1-0.1.0.0-I5t4il6dN7vIqsT1XgYsM3/Foo.hi Declaration for Just' Pattern synonym Just': Iface type variable out of scope: k Cannot continue after interface file error }}} The error only occurred when Showable was polykinded and we used synonym in a different package . Using the synonym in the same package works fine. This problem did not happen with the following definition of (non polykinded ) Showable {{{ type family Showable a :: Constraint where Showable a = (Show a) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 11:54:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 11:54:21 -0000 Subject: [GHC] #10995: Existentials in newtypes In-Reply-To: <047.143918d29abaf7f99fa5e194222eda4a@haskell.org> References: <047.143918d29abaf7f99fa5e194222eda4a@haskell.org> Message-ID: <062.663655966165452a8210e09715495d9f@haskell.org> #10995: Existentials in newtypes -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10715 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ahh... There is clearly a bug here. But it's a bug hiding a design question. If you see this: {{{ data T = MkT (forall a f. f a -> Int) }}} which of these two would you expect to get? {{{ data T1 @k = MkT (forall (a::k) (f::k->*). f a -> Int ) data T2 = MkT (forall k. forall (a::k) (f::k->*). f a -> Int) }}} That is, where should the kind be quantified? A similar choice arises for ordinary function type signatures; see this comment in `TcHsType`: {{{ Note [Kind generalisation] ~~~~~~~~~~~~~~~~~~~~~~~~~~ We do kind generalisation only at the outer level of a type signature. For example, consider T :: forall k. k -> * f :: (forall a. T a -> Int) -> Int When kind-checking f's type signature we generalise the kind at the outermost level, thus: f1 :: forall k. (forall (a:k). T k a -> Int) -> Int -- YES! and *not* at the inner forall: f2 :: (forall k. forall (a:k). T k a -> Int) -> Int -- NO! Reason: same as for HM inference on value level declarations, we want to infer the most general type. The f2 type signature would be *less applicable* than f1, because it requires a more polymorphic argument. }}} On this basis, to be consistent, we should go for `T1` not `T2`. (Which raises the question of how you could get `T2` or `f2` if you wanted them.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 11:55:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 11:55:30 -0000 Subject: [GHC] #10997: Pattern synonym causes Iface error. In-Reply-To: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> References: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> Message-ID: <064.f72b8d6c442550f232c5a5254ac85683@haskell.org> #10997: Pattern synonym causes Iface error. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Does this amount to a reproducible test case? What is `Bar.hs`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 11:59:07 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 11:59:07 -0000 Subject: [GHC] #10997: Pattern synonym causes Iface error. In-Reply-To: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> References: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> Message-ID: <064.f188664e279ffd71385ce3482cf9bd17@haskell.org> #10997: Pattern synonym causes Iface error. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * Attachment "bug.tar.gz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 12:03:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 12:03:05 -0000 Subject: [GHC] #10997: Pattern synonym causes Iface error. In-Reply-To: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> References: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> Message-ID: <064.736d69a43ca2ecabca881b82371e6af7@haskell.org> #10997: Pattern synonym causes Iface error. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Yes, see the attached file and run "stack build" in p2/ is one way. Another way to trigger it is to have, two files `Foo.hs` and `Bar.hs` as follows. Then run the following commands.. {{{ ghc Bar.hs vim Bar.hs .... make a simple change... ghc Bar.hs }}} {{{ [2 of 2] Compiling Bar ( Bar.hs, Bar.o ) The interface for ?Foo? Declaration for Just' Pattern synonym Just': Iface type variable out of scope: k Cannot continue after interface file error }}} {{{ {-# LANGUAGE PatternSynonyms, ViewPatterns, ConstraintKinds, TypeFamilies, PolyKinds, KindSignatures #-} module Foo where import GHC.Exts type family Showable (a :: k) :: Constraint where Showable (a :: *) = (Show a) Showable a = () extractJust :: Maybe a -> (Bool, a) extractJust (Just a) = (True, a) extractJust _ = (False, undefined) pattern Just' :: () => (Showable a) => a -> (Maybe a) pattern Just' a <- (extractJust -> (True, a)) where Just' a = Just a }}} {{{ module Bar where import Foo bar :: (Showable a) => Maybe a -> Maybe a bar (Just' a) = Just' a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 12:25:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 12:25:44 -0000 Subject: [GHC] #10672: GHCi linker does not understand C++ exception tables on Windows In-Reply-To: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> References: <045.04cee7c60b130b0ccc29791ed61c4f5f@haskell.org> Message-ID: <060.8c574ae82f85a682d6c9f3b26e6ad881@haskell.org> #10672: GHCi linker does not understand C++ exception tables on Windows -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Phyx- Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | rts/T10672/T10672_x86 T10672_x64 Blocked By: | Blocking: Related Tickets: #9297 #10563 | Differential Rev(s): Phab:D1244 #8237 #9907 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 12:26:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 12:26:03 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.eabf2827b2dada37dddbf9dad99fbaf7@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Rev(s): Phab:D1123 #10435 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 12:26:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 12:26:17 -0000 Subject: [GHC] #10726: Upgrade MingW-w64 distributions for windows In-Reply-To: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> References: <044.e594d39c5a4f94e11b40a05b50d182bb@haskell.org> Message-ID: <059.21cfb488f41c77ef1184a79923dd9ac6@haskell.org> #10726: Upgrade MingW-w64 distributions for windows -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.10.3 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9218 #9014 | Differential Rev(s): Phab:D1123 #10435 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 12:27:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 12:27:56 -0000 Subject: [GHC] #10817: Looping default associated type family without UndecidableInstances In-Reply-To: <047.64ffaf6cb4d5ab1829ed952b25df0d19@haskell.org> References: <047.64ffaf6cb4d5ab1829ed952b25df0d19@haskell.org> Message-ID: <062.8a640098ebe8c59cc1fca0430a400640@haskell.org> #10817: Looping default associated type family without UndecidableInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_fail/T10817 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1262 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 12:28:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 12:28:08 -0000 Subject: [GHC] #10899: Polytype accepted in RHS of default associated type In-Reply-To: <047.7b758dc1f514e80e61654f6aef2fa500@haskell.org> References: <047.7b758dc1f514e80e61654f6aef2fa500@haskell.org> Message-ID: <062.a894edbd2e624377cb7cbed382ed4d5f@haskell.org> #10899: Polytype accepted in RHS of default associated type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_fail/T10899 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1262 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 12:31:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 12:31:54 -0000 Subject: [GHC] #10997: Pattern synonym causes Iface error. In-Reply-To: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> References: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> Message-ID: <064.2568ef641c5e03d579922a9cf84c0137@haskell.org> #10997: Pattern synonym causes Iface error. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"68a084f378fbab857ccea81643eee15254b2917b/ghc" 68a084f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="68a084f378fbab857ccea81643eee15254b2917b" Testsuite: add test for #10997 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 12:32:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 12:32:59 -0000 Subject: [GHC] #10997: Pattern synonym causes Iface error. In-Reply-To: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> References: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> Message-ID: <064.ddd362aae037a2c640f40bccf826592d@haskell.org> #10997: Pattern synonym causes Iface error. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10997 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => PatternSynonyms * testcase: => typecheck/should_compile/T10997 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 13:14:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 13:14:33 -0000 Subject: [GHC] #10494: Representational equalities over AppTys are not hard failures In-Reply-To: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> References: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> Message-ID: <062.0f817057034263bce518c36ce05f283f@haskell.org> #10494: Representational equalities over AppTys are not hard failures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10494 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: The problem here is the fix seems to depend upon, {{{ commit c1edbdfd9148ad9f74bfe41e76c524f3e775aaaa Author: Richard Eisenberg Date: Mon Mar 23 10:30:19 2015 -0400 Do proper depth checking in the flattener to avoid looping. This implements (roughly) the plan put forward in comment:14:ticket:7788, fixing #7788, #8550, #9554, #10139, and addressing concerns raised in #10079. There are some regressions w.r.t. GHC 7.8, but only with pathological type families (like F a = F a). This also (hopefully -- don't have a test case) fixes #10158. Unsolved problems include #10184 and #10185, which are both known deficiencies of the approach used here. }}} Which is quite a large patch and does not apply cleanly at all. Ultimately I think we'll need to punt on this one for 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 13:26:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 13:26:53 -0000 Subject: [GHC] #602: Warning Suppression In-Reply-To: <047.d851345fc677a304d933040775d25d45@haskell.org> References: <047.d851345fc677a304d933040775d25d45@haskell.org> Message-ID: <062.e06b5e16a8092297f8846b117323d6ab@haskell.org> #602: Warning Suppression -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Jeremy mentions in https://mail.haskell.org/pipermail/libraries/2015-October/026376.html: .NET has a very flexible system for suppressing code analysis warnings, it may be informative for formulating a GHC solution. https://msdn.microsoft.com/en-us/library/ms244717.aspx -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 13:27:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 13:27:24 -0000 Subject: [GHC] #10994: GHCi segfaults when built with DYNAMIC_GHC_PROGRAMS = NO In-Reply-To: <044.42dbe48749121c55fde6256f3a4f4246@haskell.org> References: <044.42dbe48749121c55fde6256f3a4f4246@haskell.org> Message-ID: <059.64e9142b6599537a2b514bc615c459f9@haskell.org> #10994: GHCi segfaults when built with DYNAMIC_GHC_PROGRAMS = NO -------------------------------------+------------------------------------- Reporter: erikd | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1346, Wiki Page: | Phab:D1345 -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"7855afba393218d1b9f5a1552e53e124a9919845/ghc" 7855afba/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7855afba393218d1b9f5a1552e53e124a9919845" Fix breakage in the GHCi debugger Summary: There was a broken offset calculation that only worked when the sections of the binary were in a particular order, and this broke (sometimes) after we started mapping the sections separately in the linker (see D975). Test Plan: ghci debugger tests now work with DYNAMIC_GHC_PROGRAMS=NO Reviewers: austin, hvr, bgamari, erikd Reviewed By: bgamari Subscribers: Phyx, thomie, trommler Differential Revision: https://phabricator.haskell.org/D1346 GHC Trac Issues: #10994 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 13:28:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 13:28:22 -0000 Subject: [GHC] #10994: GHCi segfaults when built with DYNAMIC_GHC_PROGRAMS = NO In-Reply-To: <044.42dbe48749121c55fde6256f3a4f4246@haskell.org> References: <044.42dbe48749121c55fde6256f3a4f4246@haskell.org> Message-ID: <059.3982c27774b9ebad1d4ae240817f808b@haskell.org> #10994: GHCi segfaults when built with DYNAMIC_GHC_PROGRAMS = NO -------------------------------------+------------------------------------- Reporter: erikd | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Runtime System | Version: 7.11 (Linker) | 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:D1346, Wiki Page: | Phab:D1345 -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 13:29:09 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 13:29:09 -0000 Subject: [GHC] #10494: Representational equalities over AppTys are not hard failures In-Reply-To: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> References: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> Message-ID: <062.0b1d60144779bd0affeb0b524b8a8055@haskell.org> #10494: Representational equalities over AppTys are not hard failures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10494 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * milestone: 7.10.3 => 8.0.1 Comment: Changing Milestone accordingly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 13:33:19 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 13:33:19 -0000 Subject: [GHC] #10998: Parser should suggest -XMagicHash Message-ID: <043.3df6745fc43649973c9f6cd84b47f3f2@haskell.org> #10998: Parser should suggest -XMagicHash -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When using GHCi, this is leading to a weird situation where GHCi is actually suggesting an identifier with `#` in it, but also rejecting when you actually type it: {{{ ? ~ ghc-stage2 --interactive GHCi, version 7.11.20151016: http://www.haskell.org/ghc/ :? for help ?:1> :m + GHC.Prim ?:2> :t unsafe unsafeCoerce# unsafeFreezeArrayArray# unsafeFreezeSmallArray# unsafeThawSmallArray# unsafeFreezeArray# unsafeFreezeByteArray# unsafeThawArray# ?:2> :t unsafeCoerce# :1:14: error: parse error (possibly incorrect indentation or mismatched brackets) ?:3> :set -XMagicHash ?:4> :t unsafeCoerce# unsafeCoerce# :: a -> b }}} (also tried with 7.10) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 15:40:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 15:40:04 -0000 Subject: [GHC] #10995: Existentials in newtypes In-Reply-To: <047.143918d29abaf7f99fa5e194222eda4a@haskell.org> References: <047.143918d29abaf7f99fa5e194222eda4a@haskell.org> Message-ID: <062.5767a3901fcf4bf885a55f4e50ba2d4b@haskell.org> #10995: Existentials in newtypes -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10715 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:2 simonpj]: > There is clearly a bug here. But it's a bug hiding a design question. I agree with that statement, but disagree in the particulars. And I think that Note is wrong. Consider this: {{{ foo :: (Proxy a -> ()) -> () foo = undefined bar :: (forall a. Proxy a -> ()) -> () bar = undefined quux :: (forall (a :: k). Proxy a -> ()) -> () quux = undefined }}} With `-fprint-explicit-kinds -fprint-explicit-foralls`: {{{ *Scratch> :t foo foo :: forall (k :: BOX) (a :: k). (Proxy k a -> ()) -> () *Scratch> :t bar bar :: forall (k :: BOX). (forall (a :: k). Proxy k a -> ()) -> () *Scratch> :t quux quux :: (forall (k :: BOX) (a :: k). Proxy k a -> ()) -> () }}} With no explicit quantification, `foo`'s kind and type variables are quantified at the top-level. With `a` explicitly quantified in `bar`, `a` is not top-level, but `a`'s kind `k` is top-level. In `quux`, because `k` is explicit mentioned first in the scope of an inner quantification, it is quantified there, too. I find this design a little strange, but in the absence of explicit kind quantification, I don't see a better option. Any of these possibilities make sense and a programmer might want any of them. (Note, we will have explicit kind quantification in GHC 8.0.) Let's get back to datatypes. There is a third possibility Simon omits, and it's actually the one that GHC uses. When we see {{{ data T = MkT (forall a f. f a -> Int) }}} GHC will infer {{{ data T3 = forall k. MkT (forall a f. f a -> Int) }}} which indeed has an existential kind. The good news is that it's easy to work around this problem: just say {{{ data T = MkT (forall (a :: k) f. f a -> Int) }}} and you'll get `T2`, which has no existential kinds. Note that your first declaration, without polykinds, also has no existential variables. It has higher-rank variables, but not existential ones. As for the "could not deduce" error, I think it might be accurate, but I'm not sure. For example, consider {{{ type family F :: Constraint x1 :: (forall b. F => Proxy b -> Int) -> () x1 = undefined x2 :: (forall b. Proxy b -> Int) -> () x2 = undefined }}} `x2` compiles fine. `x1` does not, with a "could not deduce" error much like the one above. Note that `F` is just some unknown constraint, much like `Ctx2`. My guess is that GHC is more timid about unifying under the scope of an equality constraint in `x1`. In `x2`, where the constraint is obviously not an equality, everything is fine. So, error messages could perhaps be improved (can't they always?) but I don't think GHC is wrong here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 15:46:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 15:46:00 -0000 Subject: [GHC] #10271: Typed Template Haskell splice difficulty when resolving overloading In-Reply-To: <046.badc08a7987a9ad09aee9fd76d6b2f30@haskell.org> References: <046.badc08a7987a9ad09aee9fd76d6b2f30@haskell.org> Message-ID: <061.e80dc719d1824c5959122c622b181d12@haskell.org> #10271: Typed Template Haskell splice difficulty when resolving overloading -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * component: Template Haskell => Compiler (Type checker) Comment: This has much more to do with the overall type-checking algorithm than with Template Haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 16:04:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 16:04:32 -0000 Subject: [GHC] #602: Warning Suppression In-Reply-To: <047.d851345fc677a304d933040775d25d45@haskell.org> References: <047.d851345fc677a304d933040775d25d45@haskell.org> Message-ID: <062.3d82a65869cc6bbc7ae2db71e1ac86ec@haskell.org> #602: Warning Suppression -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | Design/LocalWarningPragmas | -------------------------------------+------------------------------------- Changes (by hvr): * wikipage: => Design/LocalWarningPragmas -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 16:06:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 16:06:04 -0000 Subject: [GHC] #10607: Auto derive from top to bottom In-Reply-To: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> References: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> Message-ID: <060.698a91578fae367ce53797bb6fc68272@haskell.org> #10607: Auto derive from top to bottom -------------------------------------+------------------------------------- Reporter: songzh | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: deriving, | typeclass, auto Operating System: 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:9 songzh]: > 2. I will try to solve it, just not sure about how to handle `TySynD` case. Have you tried `th-expand-syns`? The snippet you've given just retrieves the constructors (with their bound variables) of a type. The fact that your `A'` synonym repeats a variable `a` shouldn't affect anything. You should be able to just use `th-expand-syns` and then recur. I'm sorry -- I still don't see the problem. > 3. This is more straightforward: you have unnecessary assumptions in your manual `Generic` instance. Deriving `G.Generic (C a b)` does not require `G.Generic` instances for `a` and `b`. In your standalone-deriving version, you've added these, so when the default methods in `Binary` use `C`'s `Generic` instance, GHC also tries to get those others. Omit the context for your `Generic (C a b)` instance and your second example compiles. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 16:06:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 16:06:57 -0000 Subject: [GHC] #10871: Implement "fat" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.a720208cfb967f24b9cb4e0d91ec0d63@haskell.org> #10871: Implement "fat" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: 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): > We need a separate file format for Backpack. Well sure, I'm happy to move command-line flags into a file of some kind with sensible syntax. > It is GHC, not Cabal, who knows how to instantiate units. In my (perhaps naive) view of the way this works, "instantiating a unit" is just compiling modules in dependency order, exactly as GHC does today. This is the case that we already have covered; all of the new stuff is in typechecking modules without concrete dependencies. So yes - GHC instantiates units. But installing the instantiated unit and recording it in the package database is Cabal's job. The package database can record that we have an instance of A, and that it was built by instantiating A with B. > Cabal needs to ask GHC for information about how it instantiated units. I don't think so. Why can't it look in the package database? On your point about shipping something usable in a timely manner, by all means forge ahead. I don't want to block you, especially when you've done a lot more thinking about this problem and implementing it than I have! But I am very keen that we end up with a story that (a) retains the property of cabal-install depending only on its inputs, (b) keeps a sensible separation of layers between GHC, Cabal, and {cabal- install,stack}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 16:08:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 16:08:11 -0000 Subject: [GHC] #10494: Representational equalities over AppTys are not hard failures In-Reply-To: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> References: <047.6c55cf81fc9e307934dd2710cdafc698@haskell.org> Message-ID: <062.486ebd8d8bc16f14a746a2b9f8e00239@haskell.org> #10494: Representational equalities over AppTys are not hard failures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10494 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Ah -- thanks for sorting that out. I'll move this out of my queue then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 16:41:07 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 16:41:07 -0000 Subject: [GHC] #10943: Suggest PatternSynonyms In-Reply-To: <047.ef0761bfe320d77c0d572f9c36753978@haskell.org> References: <047.ef0761bfe320d77c0d572f9c36753978@haskell.org> Message-ID: <062.60873b03fbba0b3b72e7fd037edef499@haskell.org> #10943: Suggest PatternSynonyms -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: cocreature Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 cocreature): * owner: => cocreature -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 17:46:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 17:46:18 -0000 Subject: [GHC] #10173: Panic: Irrefutable pattern failed for pattern Data.Maybe.Just In-Reply-To: <045.560814a380f9a1315a0b9eab831acc66@haskell.org> References: <045.560814a380f9a1315a0b9eab831acc66@haskell.org> Message-ID: <060.0d6470e79e0d99b0b8a3d14dd98f770e@haskell.org> #10173: Panic: Irrefutable pattern failed for pattern Data.Maybe.Just ---------------------------------------+----------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------------+----------------------------- Comment (by thomie): I can not reproduce this bug with `ghc-7.8.4:i386` from https://launchpad.net/~hvr/+archive/ubuntu/ghc, installed on x86_64 Ubuntu 14.04. {{{ .cabal-sandbox/i386-linux-ghc-7.8.4-packages.conf.d attoparsec-0.12.1.2 hashable-1.2.3.3 primitive-0.6.1.0 scientific-0.3.4.2 text-1.2.1.3 vector-0.11.0.0 }}} @mietek: are you still able to reproduce this? Which versions of the dependencies did cabal install for you? Any special cabal settings you are using? Perhaps I should really test this on a 32-bit system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 18:27:49 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 18:27:49 -0000 Subject: [GHC] #10161: GHC does not relink if a library's code changed In-Reply-To: <042.f94fd40b8b796db48ebc9683f2aefa4a@haskell.org> References: <042.f94fd40b8b796db48ebc9683f2aefa4a@haskell.org> Message-ID: <057.ac4a675e219e533e93055553d0b5b960@haskell.org> #10161: GHC does not relink if a library's code changed -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10966 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Driver * related: => #10966 Comment: Might have same underlying cause as #10966. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 18:28:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 18:28:28 -0000 Subject: [GHC] #10966: dirtiness checking isn't keeping track of which source file contained Main In-Reply-To: <044.5fcdeb9071ae79d9f9b6bcbc72d714db@haskell.org> References: <044.5fcdeb9071ae79d9f9b6bcbc72d714db@haskell.org> Message-ID: <059.906ed7e791c4654684ae3fe50b405124@haskell.org> #10966: dirtiness checking isn't keeping track of which source file contained Main -------------------------------------+------------------------------------- Reporter: gueux | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10161 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #10161 Comment: See also #10161. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 18:37:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 18:37:24 -0000 Subject: [GHC] #10871: Implement "fat" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.098a8eaef5ac7197aa52e3f8eaa52c02@haskell.org> #10871: Implement "fat" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): > In my (perhaps naive) view of the way this works, "instantiating a unit" is just compiling modules in dependency order, exactly as GHC does today. No, more has to be done. For example, imagine package foo and bar set up this way: {{{ -- package foo unit foo where signature H module P }}} {{{ -- package bar unit a-impl where module A unit bar where include p include a-impl (A as H) }}} At the end of the day, we need to compile an instance of foo compiled against h-impl, e.g. `foo(H -> h-impl:A)`. How do we know that this is the case? Backpack specifies an ALGORITHM for figuring it out, which involves taking package `bar`, and then doing analysis on the includes (renames and all) to figure out what units are providing modules that other units require. If you support cross-package mutual recursion, this algorithm can be quite tricky indeed, since you need the business with infinite regular trees. So it seems quite desirable for this logic to live in GHC. So no, Cabal cannot just figure out how to instantiate units by looking at the package database, without also implementing a key part of the Backpack algorithms. (In the old design, Cabal DID implement this algorithm, but we really want to get away from that.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 18:40:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 18:40:41 -0000 Subject: [GHC] #10161: GHC does not relink if a library's code changed In-Reply-To: <042.f94fd40b8b796db48ebc9683f2aefa4a@haskell.org> References: <042.f94fd40b8b796db48ebc9683f2aefa4a@haskell.org> Message-ID: <057.1507bfef17006b59422e2019f26ee207@haskell.org> #10161: GHC does not relink if a library's code changed -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10966 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): So, I'm pretty sure the problem (in this bug) is this: 1. You made an ABI-compatible change to an upstream library. 2. Recompilation avoidance decides that myexe does not need to be recompiled (rightly so) 3. The decision whether to relink or not depends purely on whether or not any local modules got recompiled. Which they did not. It sort of sounds like we need to store some extra metadata in the final linked executable which talks about the precise objects involved, so we know when to relink. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 18:47:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 18:47:26 -0000 Subject: [GHC] #10961: Make it possible to purely use the parser In-Reply-To: <049.fcc8c76168c1ad7ed5e00c80467dcc18@haskell.org> References: <049.fcc8c76168c1ad7ed5e00c80467dcc18@haskell.org> Message-ID: <064.473756ce9bac13695688a015e2f79ab3@haskell.org> #10961: Make it possible to purely use the parser -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new 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: #10143 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #10143 Comment: #10143 also wants to split out a part of DynFlags. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 19:07:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 19:07:53 -0000 Subject: [GHC] #10143: Separate PprFlags (used by Outputable) from DynFlags In-Reply-To: <045.0c964cf0fdf539316860c6c8c56c5f9e@haskell.org> References: <045.0c964cf0fdf539316860c6c8c56c5f9e@haskell.org> Message-ID: <060.58991acc0976f21d6d403477ec0bb9d0@haskell.org> #10143: Separate PprFlags (used by Outputable) from DynFlags -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10961 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #10961 Comment: If this means DynFlags doesn't have to import Outputable and Pretty anymore: yes please! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 19:18:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 19:18:32 -0000 Subject: [GHC] #10117: Change the scheme for reporting redundant imports In-Reply-To: <046.c9fe94ada7957e35dfd23f2313543a1b@haskell.org> References: <046.c9fe94ada7957e35dfd23f2313543a1b@haskell.org> Message-ID: <061.92252ba39092821be8c5f778626114db@haskell.org> #10117: Change the scheme for reporting redundant imports -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: deprecate | warning 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 thomie): * cc: hvr (added) * keywords: => deprecate warning Comment: @hvr might be interested in this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 20:08:45 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 20:08:45 -0000 Subject: [GHC] #10053: Regression on MacOS platform, error in ghci calling main after loading compiled code: "Too late for parseStaticFlags..." In-Reply-To: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> References: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> Message-ID: <060.30afbdad25ad12a5f2b74aea38cc4d20@haskell.org> #10053: Regression on MacOS platform, error in ghci calling main after loading compiled code: "Too late for parseStaticFlags..." -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: MacOS X | 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 thomie): Replying to [comment:9 George]: > As this is an annoying regression and should be simple to fix I've changed the milestone to 7.10.2 It requires someone with a Mac to start fixing OS X specific GHC bugs. Currently there is no such person. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 20:12:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 20:12:10 -0000 Subject: [GHC] #10049: Lower level memcpy primop In-Reply-To: <049.7926ad1e5d4d0b6d73e54643d844bbc7@haskell.org> References: <049.7926ad1e5d4d0b6d73e54643d844bbc7@haskell.org> Message-ID: <064.678324fc16efa46f6deb7b9383c1bfe0@haskell.org> #10049: Lower level memcpy primop -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 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 thomie): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 20:52:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 20:52:28 -0000 Subject: [GHC] #10014: Data.Array.Base.elems needlessly calls bounds. In-Reply-To: <045.0294d47a72574992ce1409b67b846198@haskell.org> References: <045.0294d47a72574992ce1409b67b846198@haskell.org> Message-ID: <060.b1c745b03621a79c912670bdf5feaf7a@haskell.org> #10014: Data.Array.Base.elems needlessly calls bounds. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.8.4 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: ekmett (added) * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: Fixed in https://github.com/ghc/packages- array/commit/297f9a5367868df9c03d53e461a7a6cfb9d328d5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 21:08:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 21:08:15 -0000 Subject: [GHC] #10469: ghc crash on arm with -j2: internal error: scavenge: unimplemented/strange closure type In-Reply-To: <047.60fe47838743a4cb466668b7b2d86836@haskell.org> References: <047.60fe47838743a4cb466668b7b2d86836@haskell.org> Message-ID: <062.9738e9ff30a3d6bfe8d30a574b37022b@haskell.org> #10469: ghc crash on arm with -j2: internal error: scavenge: unimplemented/strange closure type ---------------------------------------+------------------------------ Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------------+------------------------------ Comment (by erikd): @joeyhess, if you have access to an `armel` machine with Clang installed, get a simple C file (eg `hello-world.c`) and compile with clang capturing the LLVM IR output: {{{ clang -S -emit-llvm foo.c }}} which will produce a `foo.ll` file containing the text LLVM IR code. If you could post the first 10 or so lines of that file (it should contain information about the target triple) that would be a good first step. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 22:38:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 22:38:00 -0000 Subject: [GHC] #10996: family is treated as keyword in types even without TypeFamilies enabled In-Reply-To: <045.27f49ff532e9a720de796a9ae0ad68ae@haskell.org> References: <045.27f49ff532e9a720de796a9ae0ad68ae@haskell.org> Message-ID: <060.84555ff28d88aba85602ef92164a4c32@haskell.org> #10996: family is treated as keyword in types even without TypeFamilies enabled -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: type Test valid program | family = family Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by oerjan): `family` and `role` are really the same as `forall`: they can currently be used as `varid`s, even with their extensions enabled. The error is that they can ''never'' be used as `tyvarid`s. (I think my [comment:1 comment:1] applies to `role` as well, but not to `forall`, because `forall` can appear in places where an applied type constructor variable would fit.) However, `forall` actually ''does'' appear to be special cased. Without any extensions enabled: {{{ Prelude> type Test role = role :2:11: parse error on input `role' Prelude> type Test forall = forall Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 22:50:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 22:50:54 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.abd106435d01d39d28ac4aeaf512e2fc@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by edmund): Does {{{( cd testsuite && make TEST=ado001 stage=1 )}}} fail for you on arm64? Does it pass on other architectures? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 21 23:14:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Oct 2015 23:14:50 -0000 Subject: [GHC] #10996: family is treated as keyword in types even without TypeFamilies enabled In-Reply-To: <045.27f49ff532e9a720de796a9ae0ad68ae@haskell.org> References: <045.27f49ff532e9a720de796a9ae0ad68ae@haskell.org> Message-ID: <060.521d7050fdc62e90a64aef0291e71d56@haskell.org> #10996: family is treated as keyword in types even without TypeFamilies enabled -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: type Test valid program | family = family Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by oerjan): As I said, in principle there may be no real ambiguity, but unfortunately it seems like the head of these constructions is parsed as a `type` (nonterminal) token, and the check for whether it is of the right form is only done ''after'' the `Happy` parsing: {{{ Prelude> :set -XTypeFamilies Prelude> type family' a = a :28:6: Malformed head of type or class declaration: family' a Prelude> type family a = a :30:13: Malformed head of type or class declaration: a }}} A token that parses those and only those `type`s that can appear as the head of these declarations (in particular, disallowing ''applied'' type variables) might solve this problem. (Unless, of course, there's some ambiguous case that I've forgotten, but that should hopefully show up as a reduce/* conflict.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 01:18:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 01:18:39 -0000 Subject: [GHC] #10469: ghc crash on arm with -j2: internal error: scavenge: unimplemented/strange closure type In-Reply-To: <047.60fe47838743a4cb466668b7b2d86836@haskell.org> References: <047.60fe47838743a4cb466668b7b2d86836@haskell.org> Message-ID: <062.0fd1d8a2b9131fd446937a5366f1aa33@haskell.org> #10469: ghc crash on arm with -j2: internal error: scavenge: unimplemented/strange closure type ---------------------------------------+------------------------------ Reporter: joeyhess | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------------+------------------------------ Comment (by joeyhess): The triple for armel is armv4t-unknown-linux-gnueabi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 04:53:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 04:53:51 -0000 Subject: [GHC] #10970: Built in MIN_VERSION macro support In-Reply-To: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> References: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> Message-ID: <060.ea1064b680969f9557c2ace0ac576dd4@haskell.org> #10970: Built in MIN_VERSION macro support -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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:D1349 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * differential: => Phab:D1349 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 05:27:16 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 05:27:16 -0000 Subject: [GHC] #10999: ghc: panic! (the 'impossible' happened) Message-ID: <042.e700677e826396486b3741ddf6f847b0@haskell.org> #10999: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: res | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The attached program elicits the following error from GHC 7.10.2: {{{ Couldn't match type ?a? with ?(t0, t1, t2)? ?a? is untouchable inside the constraints () bound by the inferred type of updateKeytab :: FilePath -> Handle -> IO () at /u/res/g/src/remctl-tools/foo.hs:(58,1)-(69,26)ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): No skolem info: a_akOb[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 05:30:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 05:30:06 -0000 Subject: [GHC] #10999: ghc: panic! (the 'impossible' happened) In-Reply-To: <042.e700677e826396486b3741ddf6f847b0@haskell.org> References: <042.e700677e826396486b3741ddf6f847b0@haskell.org> Message-ID: <057.ebb33501ab788937a996791601cc8255@haskell.org> #10999: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: res | Owner: Type: bug | Status: new 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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by res): * Attachment "foo.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 06:43:14 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 06:43:14 -0000 Subject: [GHC] #10318: Cycles in class declaration (via superclasses) sometimes make sense. In-Reply-To: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> References: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> Message-ID: <060.0db5990427a6d739cc14dca164de44d9@haskell.org> #10318: Cycles in class declaration (via superclasses) sometimes make sense. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kosmikus): * cc: kosmikus (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 06:56:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 06:56:10 -0000 Subject: [GHC] #10318: Cycles in class declaration (via superclasses) sometimes make sense. In-Reply-To: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> References: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> Message-ID: <060.be4d542d13cdb0a2b8197cad5b15f1a4@haskell.org> #10318: Cycles in class declaration (via superclasses) sometimes make sense. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): I think that every example I have does indeed terminate in a finite manner in this way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 07:25:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 07:25:05 -0000 Subject: [GHC] #10996: family is treated as keyword in types even without TypeFamilies enabled In-Reply-To: <045.27f49ff532e9a720de796a9ae0ad68ae@haskell.org> References: <045.27f49ff532e9a720de796a9ae0ad68ae@haskell.org> Message-ID: <060.55a6e9e65dbfedafca364188f4f7a7a7@haskell.org> #10996: family is treated as keyword in types even without TypeFamilies enabled -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: type Test valid program | family = family Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Oerjan, that's exactly right. I'm not sure how much effort it's worth devoting to this, but I agree that that the current situation is a mess: * Most things are dealt with as `special_id`; good * 'forall' has its own special lexer treatment, so at least it is not stolen until you switch on `ExplicitForAlls` * But 'role' and 'family' are stolen all the time, in types. Which is a Haskell 98 or 2010 violation. It's annoying! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 07:42:22 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 07:42:22 -0000 Subject: [GHC] #10829: Simplification in the RHS of rules In-Reply-To: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> References: <046.7ca7c028ab82ec2d7ad263cb88680067@haskell.org> Message-ID: <061.be361fe8279ed9a0659f0f419b2a548e@haskell.org> #10829: Simplification in the RHS of rules -------------------------------------+------------------------------------- Reporter: afarmer | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10528 | Differential Rev(s): Phab:D1246 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 07:42:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 07:42:52 -0000 Subject: [GHC] #10607: Auto derive from top to bottom In-Reply-To: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> References: <045.e09b97a7eafdf9652cf786c0b3852657@haskell.org> Message-ID: <060.441551995deed3b3ec5773c46b54ea34@haskell.org> #10607: Auto derive from top to bottom -------------------------------------+------------------------------------- Reporter: songzh | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: deriving, | typeclass, auto Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by songzh): 2. I am a newbie of TH, but thanks, I will look into `th-expand-syns` 3. I noticed and understood the reason why we do not need type variable `Generic a` in the context finally!! thanks. I may request an API for querying whether `Eq a => List a` is an instance of Eq typeclass. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 07:43:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 07:43:47 -0000 Subject: [GHC] #10934: Iface type variable out of scope In-Reply-To: <047.1cb3ee5ab1249c924fa43e250146dc6f@haskell.org> References: <047.1cb3ee5ab1249c924fa43e250146dc6f@haskell.org> Message-ID: <062.fc6a56edcf4967f28cc7e9036d0a55b0@haskell.org> #10934: Iface type variable out of scope -------------------------------------+------------------------------------- Reporter: mjmrotek | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: interface Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | polykinds/T10934 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 07:44:30 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 07:44:30 -0000 Subject: [GHC] #10375: arm: ghci hits an illegal instruction In-Reply-To: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> References: <044.4268b4c62bfdf2f8712c54066cf3d003@haskell.org> Message-ID: <059.fc13468ddfeec36e51a2e2687f6f2d21@haskell.org> #10375: arm: ghci hits an illegal instruction -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #10969 | Differential Rev(s): Phab:D1323 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 07:46:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 07:46:45 -0000 Subject: [GHC] #7830: Error: operand out of range In-Reply-To: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> References: <044.bbf9a3f391f247f721fd2a101caaa0e8@haskell.org> Message-ID: <059.f1245fa11f7a13719d0286c8ac98ee15@haskell.org> #7830: Error: operand out of range -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.3 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1296 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 07:50:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 07:50:51 -0000 Subject: [GHC] #10870: PPC.Ppr: Shift by 32 bits is not allowed. In-Reply-To: <046.266af0561f46fb382b81907ac208339a@haskell.org> References: <046.266af0561f46fb382b81907ac208339a@haskell.org> Message-ID: <061.ac91e4c53a6bcfdcc5c3c5c8c9ce3133@haskell.org> #10870: PPC.Ppr: Shift by 32 bits is not allowed. ---------------------------------------+---------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler (CodeGen) | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1322 Wiki Page: | ---------------------------------------+---------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 07:51:35 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 07:51:35 -0000 Subject: [GHC] #10498: "if ... then \case -> else ..." causes a "missing else clause" error In-Reply-To: <050.28cad0c5bb9248828a1f63b683a53853@haskell.org> References: <050.28cad0c5bb9248828a1f63b683a53853@haskell.org> Message-ID: <065.74c98bba5703a83b1074bc2c6f174df7@haskell.org> #10498: "if ... then \case -> else ..." causes a "missing else clause" error -------------------------------------+------------------------------------- Reporter: dramforever | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 (Parser) | 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:D1309 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 07:53:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 07:53:24 -0000 Subject: [GHC] #10149: The argument of mask does not always restore the masking state In-Reply-To: <056.a022411c5d769cb0ad858891d8d4fe85@haskell.org> References: <056.a022411c5d769cb0ad858891d8d4fe85@haskell.org> Message-ID: <071.0f70244c3276c5b94262fc7cff4b9d17@haskell.org> #10149: The argument of mask does not always restore the masking state -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.11 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:D1327 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 07:54:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 07:54:38 -0000 Subject: [GHC] #10747: Infix pattern synonyms fail to parse (regression) In-Reply-To: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> References: <048.dc77b17374ac8b11e33228cc9dd19430@haskell.org> Message-ID: <063.dc276d77f7850aeaa56a23fea4853aac@haskell.org> #10747: Infix pattern synonyms fail to parse (regression) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: mpickering Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: fixed | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | patsyn/should_compile/T10747 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1295 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 08:01:17 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 08:01:17 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.f662c45fcbf1d0735054b1100397bd58@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D586 Wiki Page: | Phab:D587 Phab:D1244 Phab:D1310 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 08:01:34 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 08:01:34 -0000 Subject: [GHC] #1407: Add the ability to :set -l{foo} in .ghci files In-Reply-To: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> References: <044.ced6846230ff2e238418885a3d68ddd9@haskell.org> Message-ID: <059.b7f81c597023b8aa390f8190e33a3eaa@haskell.org> #1407: Add the ability to :set -l{foo} in .ghci files -------------------------------------+------------------------------------- Reporter: guest | Owner: archblob Type: feature request | Status: closed Priority: normal | Milestone: 7.10.3 Component: GHCi | Version: 6.6.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D194 Wiki Page: | Phab:D1310 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 08:03:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 08:03:53 -0000 Subject: [GHC] #9297: Packages linked against certain Windows .dll files give warnings at runtime In-Reply-To: <050.15e3ebd6026e8054e922a0058e2d13ac@haskell.org> References: <050.15e3ebd6026e8054e922a0058e2d13ac@haskell.org> Message-ID: <065.1ca8d33f640c39a72f3c22ed64863645@haskell.org> #9297: Packages linked against certain Windows .dll files give warnings at runtime -----------------------------------+-------------------------------------- Reporter: RyanGlScott | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2283, #9218 | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Changes (by thomie): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 09:28:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 09:28:29 -0000 Subject: [GHC] #9297: Packages linked against certain Windows .dll files give warnings at runtime In-Reply-To: <050.15e3ebd6026e8054e922a0058e2d13ac@haskell.org> References: <050.15e3ebd6026e8054e922a0058e2d13ac@haskell.org> Message-ID: <065.0eaf26ae94df32148a72229c0cf15167@haskell.org> #9297: Packages linked against certain Windows .dll files give warnings at runtime -----------------------------------+-------------------------------------- Reporter: RyanGlScott | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: Runtime System | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2283, #9218 | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 10:03:36 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 10:03:36 -0000 Subject: [GHC] #10999: ghc: panic! (the 'impossible' happened) In-Reply-To: <042.e700677e826396486b3741ddf6f847b0@haskell.org> References: <042.e700677e826396486b3741ddf6f847b0@haskell.org> Message-ID: <057.65c667d250bd0d53a325bf4087026c2f@haskell.org> #10999: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: res | Owner: Type: bug | Status: new 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: | Blocking: Related Tickets: #10045 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #10045 Comment: Here is a smaller test to trigger the same bug: {{{ module T10999 where import qualified Data.Set as Set f :: () -> _ f _ = Set.fromList undefined g = map fst $ Set.toList $ f () }}} It is already fixed in HEAD, and seems like a duplicate of #10045. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 10:11:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 10:11:38 -0000 Subject: [GHC] #10998: Parser should suggest -XMagicHash In-Reply-To: <043.3df6745fc43649973c9f6cd84b47f3f2@haskell.org> References: <043.3df6745fc43649973c9f6cd84b47f3f2@haskell.org> Message-ID: <058.1539da7f23b9e5f67d38b064388cc505@haskell.org> #10998: Parser should suggest -XMagicHash -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (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 thomie): * component: Compiler => Compiler (Parser) Comment: Good idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 10:31:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 10:31:54 -0000 Subject: [GHC] #10992: Performance regression due to lack of inlining of `foldl` and `foldl'`. In-Reply-To: <046.c9e7f7c6b0bdb50720ba035d3861748a@haskell.org> References: <046.c9e7f7c6b0bdb50720ba035d3861748a@haskell.org> Message-ID: <061.236f374d44c4f17b0be1a42c6a9b6e7f@haskell.org> #10992: Performance regression due to lack of inlining of `foldl` and `foldl'`. -------------------------------------+------------------------------------- Reporter: aleator | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: performane Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: ekmett (added) * failure: None/Unknown => Runtime performance bug * component: Compiler => Core Libraries Comment: Replying to [comment:1 nomeata]: > If I use...: > {{{ > sum0 xs = sum xs > }}} > then I get good code... Tricky. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 10:33:09 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 10:33:09 -0000 Subject: [GHC] #10493: Inaccessible code might be accessible with newtypes and Coercible In-Reply-To: <047.2c11d0767c97fbdfa43aeb457c1a28e7@haskell.org> References: <047.2c11d0767c97fbdfa43aeb457c1a28e7@haskell.org> Message-ID: <062.cfc892a581f8dd3bc24a0e2309a2ffe0@haskell.org> #10493: Inaccessible code might be accessible with newtypes and Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10493 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Unfortunately while this fix was quite straightforward to merge to `ghc-7.10`, it turns out that (I believe) we would also need merge this as well for the fix to be effective, {{{ commit ff82387d6fe61762fe4f507e8f9799f5bdc3c43a Author: Richard Eisenberg Date: Mon Jun 8 22:32:40 2015 -0400 Decompose wanted repr. eqs. when no matchable givens. This is pursuant to a conversion with SPJ, where we agreed that the logic behind Note [Instance and Given overlap] in TcInteract applied to newtype decomposition for representational equality. There is no bug report or test case, as tickling this kind of thing is quite hard to do! }}} which is itself dependent upon, {{{ commit 228ddb95ee137e7cef02dcfe2521233892dd61e0 Author: Simon Peyton Jones Date: Wed May 13 12:49:13 2015 +0100 Make the "matchable-given" check happen first This change makes the matchable-given check apply uniformly to - constraint tuples - natural numbers - Typeable as well as to vanilla class constraints. See Note [Instance and Given overlap] in TcInteract }}} which interacts with another patch not present in `ghc-7.10`, {{{ commit a1275a762ec04c1159ae37199b1c8f998a5c5499 Author: Simon Peyton Jones Date: Wed Apr 29 13:43:09 2015 +0100 Improve improvement in the constraint solver }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 10:34:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 10:34:58 -0000 Subject: [GHC] #10945: Typed Template Haskell splices broken in HEAD (7.11) In-Reply-To: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> References: <048.3674bf59da48a1703fc3f1d0ef904b2f@haskell.org> Message-ID: <063.ef0fb008c312a2b1e0f3b46bf83f0a54@haskell.org> #10945: Typed Template Haskell splices broken in HEAD (7.11) -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10945 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1344 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: The test is passing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 10:38:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 10:38:23 -0000 Subject: [GHC] #10992: Performance regression due to lack of inlining of `foldl` and `foldl'`. In-Reply-To: <046.c9e7f7c6b0bdb50720ba035d3861748a@haskell.org> References: <046.c9e7f7c6b0bdb50720ba035d3861748a@haskell.org> Message-ID: <061.bf7614c93a397aa6b46e2d6131773461@haskell.org> #10992: Performance regression due to lack of inlining of `foldl` and `foldl'`. -------------------------------------+------------------------------------- Reporter: aleator | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: performane Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I should add that I?m inclined to suggest to change the definitions to {{{ {-# INLINE foldl #-} foldl k z0 = \xs -> ... {-# INLINE foldl' #-} foldl' k z0 = \xs -> ... }}} which should fix the problem at hand, but I?d like to have at least a second opinion on this by someone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 11:05:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 11:05:32 -0000 Subject: [GHC] #11000: Implement `-Wcompat` Message-ID: <042.320fb0d4d15a64c4acbdb24f3f1efcf0@haskell.org> #11000: Implement `-Wcompat` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature | Status: new request | Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: Design/Warnings -------------------------------------+------------------------------------- Currently we have only the following generic warning "levels": {{{ -W enable normal warnings -w disable all warnings -Wall enable almost all warnings (details in ) }}} It would be useful to be able to refer collectively to all currently implemented forward-compatibility warnings (e.g. about upcoming changes in `base`, like `-fwarn-amp`) via a symbolic `-Wcompat` flag. This way, users have more flexibility in opt-in or out of such warnings. So e.g. the following settings are possible in `.cabal` files: `ghc-options: -Wall` :: enable "almost all warnings" as before. Some compat warnings maybe part of `-Wall`, some won't (yet). `ghc-options: -Wall -Wcompat` :: enable "almost all warnings" as well as all implemented warnings. E.g. if GHC 8.0 implements `-fwarn-mfp-compat` but doesn't include it in `-Wall`, this allows users to get notified asap about warnings to opt into that `ghc-options: -Wall -Wno-compat` :: This enables `-Wall` **minus** any future-compat warnings. This is for users who want to be warned at all about any future compat warnings. `ghc-options: -Wcompat` :: Of course, `-W(no-)compat` can be used also w/o `-Wall`, and then is equivalent to turning on/off the respective individual `-fwarn-*-compat` flags. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 11:13:09 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 11:13:09 -0000 Subject: [GHC] #10493: Inaccessible code might be accessible with newtypes and Coercible In-Reply-To: <047.2c11d0767c97fbdfa43aeb457c1a28e7@haskell.org> References: <047.2c11d0767c97fbdfa43aeb457c1a28e7@haskell.org> Message-ID: <062.08996da331621007862d4d3f1f6d50d8@haskell.org> #10493: Inaccessible code might be accessible with newtypes and Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10493 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I was able to cherry-pick 228ddb95ee137e7cef02dcfe2521233892dd61e0 to `ghc-7.10`. Unfortunately ff82387d6fe61762fe4f507e8f9799f5bdc3c43a appears to depend upon the superclass rework so I think I'll just have to punt on all of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 11:15:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 11:15:42 -0000 Subject: [GHC] #11000: Implement `-Wcompat` In-Reply-To: <042.320fb0d4d15a64c4acbdb24f3f1efcf0@haskell.org> References: <042.320fb0d4d15a64c4acbdb24f3f1efcf0@haskell.org> Message-ID: <057.7252b235eb325044eeca8c4ac568b291@haskell.org> #11000: Implement `-Wcompat` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Description changed by hvr: Old description: > Currently we have only the following generic warning "levels": > > {{{ > -W enable normal warnings > -w disable all warnings > -Wall enable almost all warnings (details in ) > }}} > > It would be useful to be able to refer collectively to all currently > implemented forward-compatibility warnings (e.g. about upcoming changes > in `base`, like `-fwarn-amp`) via a symbolic `-Wcompat` flag. > > This way, users have more flexibility in opt-in or out of such warnings. > So e.g. the following settings are possible in `.cabal` files: > > `ghc-options: -Wall` :: enable "almost all warnings" as before. Some > compat warnings maybe part of `-Wall`, some won't (yet). > `ghc-options: -Wall -Wcompat` :: enable "almost all warnings" as well > as all implemented warnings. E.g. if GHC 8.0 implements `-fwarn-mfp- > compat` but doesn't include it in `-Wall`, this allows users to get > notified asap about warnings to opt into that > `ghc-options: -Wall -Wno-compat` :: This enables `-Wall` **minus** any > future-compat warnings. This is for users who want to be warned at all > about any future compat warnings. > `ghc-options: -Wcompat` :: Of course, `-W(no-)compat` can be used also > w/o `-Wall`, and then is equivalent to turning on/off the respective > individual `-fwarn-*-compat` flags. New description: Currently we have only the following generic warning "levels": {{{ -W enable normal warnings -w disable all warnings -Wall enable almost all warnings (details in ) }}} It would be useful to be able to refer collectively to all currently implemented forward-compatibility warnings (e.g. about upcoming changes in `base`, like `-fwarn-amp`) via a symbolic `-Wcompat` flag. This way, users have more flexibility in opt-in or out of such warnings. So e.g. the following settings are possible in `.cabal` files: `ghc-options: -Wall` :: enable "almost all warnings" as before. Some compatibility warnings may be part of `-Wall`, some won't (yet). `ghc-options: -Wall -Wcompat` :: enable "almost all warnings" as well as all currently implemented warnings. E.g. if GHC 8.0 implements `-fwarn- mfp-compat` but doesn't include it in `-Wall`, this gives users a way to opt in to get notified early about upcoming changes. `ghc-options: -Wall -Wno-compat` :: This enables `-Wall` **minus** any future-compat warnings. This is for users who want to be warned at all about any future compat warnings. `ghc-options: -Wcompat` :: Of course, `-W(no-)compat` can be used also w/o `-Wall`, and then is equivalent to turning on/off the respective individual `-fwarn-*-compat` flags. `ghc-options: -Wall -Wcompat -Wno-mfp-compat` :: This would allow to acknowledge the MFP compat warnings, while enabling other future GHC compat warnings. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 11:18:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 11:18:32 -0000 Subject: [GHC] #10493: Inaccessible code might be accessible with newtypes and Coercible In-Reply-To: <047.2c11d0767c97fbdfa43aeb457c1a28e7@haskell.org> References: <047.2c11d0767c97fbdfa43aeb457c1a28e7@haskell.org> Message-ID: <062.8f1dccc8ff794ae9fa65369df6b10331@haskell.org> #10493: Inaccessible code might be accessible with newtypes and Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10493 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 7.10.3 => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 11:20:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 11:20:18 -0000 Subject: [GHC] #10007: Fix misattribution of Cost Centre profiles to lintAnnots In-Reply-To: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> References: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> Message-ID: <067.cbc8c4a3214385eefeceec459b83c91f@haskell.org> #10007: Fix misattribution of Cost Centre profiles to lintAnnots -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: scpmw Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Profiling | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9961,#5654 | Differential Rev(s): Phab:D616 Wiki Page: | Phab:D636 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 7.10.3 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 11:22:50 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 11:22:50 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.4ddd00682d09bc0e5eb07cd2ecc10e11@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) ---------------------------------+-------------------------------------- Reporter: rleslie | Owner: trommler Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * milestone: 7.10.3 => 8.0.1 Comment: Remilestoning as there there is no fix ready for 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 11:36:17 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 11:36:17 -0000 Subject: [GHC] #10549: floatExpr tick break<2> In-Reply-To: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> References: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> Message-ID: <066.e9741fe91b1ccf4080ef606eae251056@haskell.org> #10549: floatExpr tick break<2> -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10549 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1128 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c633f71f9b687dcb9154ffd558442193cbced0e3/ghc" c633f71/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c633f71f9b687dcb9154ffd558442193cbced0e3" Add another test for #10549 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 11:36:59 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 11:36:59 -0000 Subject: [GHC] #10549: floatExpr tick break<2> In-Reply-To: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> References: <051.49bf684e76c5aa6a97c58ee954a78f33@haskell.org> Message-ID: <066.4353f1d41c8d454fe670dc96358ddf48@haskell.org> #10549: floatExpr tick break<2> -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | T10549,T10549a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1128 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: T10549 => T10549,T10549a -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 11:39:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 11:39:32 -0000 Subject: [GHC] #10173: Panic: Irrefutable pattern failed for pattern Data.Maybe.Just In-Reply-To: <045.560814a380f9a1315a0b9eab831acc66@haskell.org> References: <045.560814a380f9a1315a0b9eab831acc66@haskell.org> Message-ID: <060.d5fb0ecd764918556309732a80a0d1ad@haskell.org> #10173: Panic: Irrefutable pattern failed for pattern Data.Maybe.Just ---------------------------------------+----------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------------+----------------------------- Comment (by mietek): I was unable to reproduce it on any platform other than 32-bit Red Hat Enterprise Linux 6.5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 11:40:01 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 11:40:01 -0000 Subject: [GHC] #10943: Suggest PatternSynonyms In-Reply-To: <047.ef0761bfe320d77c0d572f9c36753978@haskell.org> References: <047.ef0761bfe320d77c0d572f9c36753978@haskell.org> Message-ID: <062.72cdade0b8d57155fadbd3c04d65b5be@haskell.org> #10943: Suggest PatternSynonyms -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: cocreature Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 Thomas Miedema ): In [changeset:"1e8d1f1c6d85457c786b50b1e054facdb61cbae1/ghc" 1e8d1f1c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1e8d1f1c6d85457c786b50b1e054facdb61cbae1" Suggest enabling PatternSynonyms (#10943) Suggest enabling PatternSynonyms if we find an invalid signature that looks like a pattern synonym. Reviewed By: austin, thomie Differential Revision: https://phabricator.haskell.org/D1347 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 11:40:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 11:40:52 -0000 Subject: [GHC] #10623: Handling of ASCII encodings introduced in D898 breaks Unicode terminal detection In-Reply-To: <046.3a764cfd54e5a4e4443ef4864c8fddbf@haskell.org> References: <046.3a764cfd54e5a4e4443ef4864c8fddbf@haskell.org> Message-ID: <061.6b0f91521348984511e501f70182e2e3@haskell.org> #10623: Handling of ASCII encodings introduced in D898 breaks Unicode terminal detection -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T8958a Blocked By: | Blocking: Related Tickets: #10298, #7695 | Differential Rev(s): Phab:D1059, Wiki Page: | Phab:D1085 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 7.10.3 => 8.0.1 Comment: The issue mentioned in comment:11 is still outstanding. Punting to 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 11:45:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 11:45:13 -0000 Subject: [GHC] #9646: Simplifer non-determinism leading to 8 fold difference in run time performance In-Reply-To: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> References: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> Message-ID: <059.63896779fa5b16ea24813b7f240acbb7@haskell.org> #9646: Simplifer non-determinism leading to 8 fold difference in run time performance -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 7.10.3 => 8.0.1 Comment: Still needs a test but this won't happen for 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 11:45:14 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 11:45:14 -0000 Subject: [GHC] #10943: Suggest PatternSynonyms In-Reply-To: <047.ef0761bfe320d77c0d572f9c36753978@haskell.org> References: <047.ef0761bfe320d77c0d572f9c36753978@haskell.org> Message-ID: <062.c2a2cb4766736738755e14affb92bda8@haskell.org> #10943: Suggest PatternSynonyms -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: cocreature Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_fail/NoPatternSynonyms Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1347 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => parser/should_fail/NoPatternSynonyms * differential: => Phab:D1347 * milestone: => 8.0.1 Comment: Great patch cocreature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 11:45:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 11:45:24 -0000 Subject: [GHC] #10943: Suggest PatternSynonyms In-Reply-To: <047.ef0761bfe320d77c0d572f9c36753978@haskell.org> References: <047.ef0761bfe320d77c0d572f9c36753978@haskell.org> Message-ID: <062.28329f1805db4ef92bf1839e93e83bea@haskell.org> #10943: Suggest PatternSynonyms -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: cocreature Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_fail/NoPatternSynonyms Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1347 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 11:47:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 11:47:54 -0000 Subject: [GHC] #10053: Regression on MacOS platform, error in ghci calling main after loading compiled code: "Too late for parseStaticFlags..." In-Reply-To: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> References: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> Message-ID: <060.fce1a269154a69645d593c20a652b407@haskell.org> #10053: Regression on MacOS platform, error in ghci calling main after loading compiled code: "Too late for parseStaticFlags..." -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 7.10.3 => 8.0.1 Old description: > ghci > GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help > Prelude> :load rsa > Ok, modules loaded: Main. > Prelude Main> :show modules > Main ( rsa.hs, rsa.o ) > Prelude Main> main > Too late for parseStaticFlags: call it before runGhc or runGhcT > Exception: ExitFailure 1 > Prelude Main> > > note, there is no failure if I load interpreted code New description: {{{ $ ghci GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help Prelude> :load rsa Ok, modules loaded: Main. Prelude Main> :show modules Main ( rsa.hs, rsa.o ) Prelude Main> main Too late for parseStaticFlags: call it before runGhc or runGhcT Exception: ExitFailure 1 Prelude Main> }}} note, there is no failure if I load interpreted code -- Comment: This isn't going to be fixed for 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 11:51:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 11:51:06 -0000 Subject: [GHC] #10301: Plugins/dynamic loading subtly broken (it seems) In-Reply-To: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> References: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> Message-ID: <067.414a4d64a299d95552424f61f1c1b57b@haskell.org> #10301: Plugins/dynamic loading subtly broken (it seems) -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | plugins/T10294 Blocked By: | Blocking: Related Tickets: #8276 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 7.10.3 => 8.0.1 Comment: Will not be fixed for 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 11:52:02 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 11:52:02 -0000 Subject: [GHC] #10409: Binary compiled with ghc-7.10 amd64/linux to aarch64/linux cross compiler segfaults. In-Reply-To: <044.281124fed1ab665b0c342f08f03cde68@haskell.org> References: <044.281124fed1ab665b0c342f08f03cde68@haskell.org> Message-ID: <059.f12484f21fb7d19b6cfb4fac20b44c80@haskell.org> #10409: Binary compiled with ghc-7.10 amd64/linux to aarch64/linux cross compiler segfaults. ----------------------------------+--------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Resolution: wontfix | Keywords: cross-compiling Operating System: Linux | Architecture: aarch64 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+--------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => wontfix Comment: We don't have a fix for 7.10.3. Closing as the reporter claims `master` works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 11:52:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 11:52:27 -0000 Subject: [GHC] #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images In-Reply-To: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> References: <044.0e4dde9e3a0324f18f8091c422680492@haskell.org> Message-ID: <059.4b3ca614a60344dffedfe66804afa19c@haskell.org> #10416: GHC 7.10.1 User Guide profiling section 5.4 missing images -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.10.1 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): Phab:D958, Wiki Page: | Phab:D970 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 7.10.3 => 8.0.1 Comment: Not fixed in 7.10.3, only in 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 11:54:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 11:54:23 -0000 Subject: [GHC] #10506: SourceNotes are not applied to all identifiers In-Reply-To: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> References: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> Message-ID: <064.f2ac4bef6f2711ade540c57f974d2158@haskell.org> #10506: SourceNotes are not applied to all identifiers -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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: 7.10.3 => 8.0.1 Comment: This won't be fixed for 7.10.3 as there is no fix yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 11:54:50 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 11:54:50 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310520=3A_RecordWildCards_causes_?= =?utf-8?q?=E2=80=9Cis_not_a_=28visible=29_field_of_constructor?= =?utf-8?b?4oCdIGluIGdoY2k=?= In-Reply-To: <043.c857f67e883ef833a204da9e13d91bc2@haskell.org> References: <043.c857f67e883ef833a204da9e13d91bc2@haskell.org> Message-ID: <058.54a63f7b3bc72135fc3198f280046448@haskell.org> #10520: RecordWildCards causes ?is not a (visible) field of constructor? in ghci -------------------------------------+------------------------------------- Reporter: ion1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: fixed | Keywords: | RecordWildCards 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 bgamari): * milestone: 7.10.3 => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 11:56:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 11:56:23 -0000 Subject: [GHC] #10594: the ghc-7.10.1-x86_64-apple-darwin.tar.bz2 doesn't install /sw/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3/GHC In-Reply-To: <046.69b85de5f279bc6fd8a3f5ec62466a80@haskell.org> References: <046.69b85de5f279bc6fd8a3f5ec62466a80@haskell.org> Message-ID: <061.c127039a19402647cbee392a256f345b@haskell.org> #10594: the ghc-7.10.1-x86_64-apple-darwin.tar.bz2 doesn't install /sw/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3/GHC -------------------------------------+------------------------------------- Reporter: howarth | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 7.10.3 => 8.0.1 Comment: Won't be fixed in 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 12:00:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 12:00:27 -0000 Subject: [GHC] #10769: Yet another crash from typed holes In-Reply-To: <049.adcd25e8757381b099d00f18d1417d8a@haskell.org> References: <049.adcd25e8757381b099d00f18d1417d8a@haskell.org> Message-ID: <064.ac1ae3025ce5aeffe45c488bf24cae30@haskell.org> #10769: Yet another crash from typed holes -------------------------------+-------------------------------------- Reporter: rpglover64 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | 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 bgamari): * status: new => closed * resolution: => fixed * milestone: 7.10.3 => 8.0.1 Comment: Fix won't be present in 7.10.3 but this should work in 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 12:01:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 12:01:51 -0000 Subject: [GHC] #10815: Need more kind inference in associated type instances In-Reply-To: <047.d8bc1a4461bf2f49e829557a2b73313c@haskell.org> References: <047.d8bc1a4461bf2f49e829557a2b73313c@haskell.org> Message-ID: <062.60b9a4e36bb7e573c48a58823669e59d@haskell.org> #10815: Need more kind inference in associated type instances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T10815 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1195 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 7.10.3 => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 12:05:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 12:05:39 -0000 Subject: [GHC] #10876: stack overflow regression In-Reply-To: <044.3685b2599dc5dd8fb0cf47784fa834c3@haskell.org> References: <044.3685b2599dc5dd8fb0cf47784fa834c3@haskell.org> Message-ID: <059.7ad724c2ac8a36c560452ebf468348b2@haskell.org> #10876: stack overflow regression -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: 7.10.3 => 8.0.1 Comment: We still don't know which commit fixed this so this won't be fixed in 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 12:07:22 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 12:07:22 -0000 Subject: [GHC] #10924: Template variable unbound in rewrite rule In-Reply-To: <047.723a648571c518eb9cf0f244f8acc218@haskell.org> References: <047.723a648571c518eb9cf0f244f8acc218@haskell.org> Message-ID: <062.fbc2a9a6ec4c57e47ed8e3be5f651b48@haskell.org> #10924: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: singletons, | templatehaskell Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: The fix for #10689 will be present in 7.10.3. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 12:09:30 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 12:09:30 -0000 Subject: [GHC] #10582: Tiny bug in lexer around lexing banana brackets In-Reply-To: <047.08a52be5ab9ac23a1408480f99ba99e9@haskell.org> References: <047.08a52be5ab9ac23a1408480f99ba99e9@haskell.org> Message-ID: <062.69935f23bfd0511570b8643fc343c8d4@haskell.org> #10582: Tiny bug in lexer around lexing banana brackets -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_compile/T10582 Blocked By: 10583 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 7.10.3 => 8.0.1 Comment: This won't be fixed in 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 12:28:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 12:28:58 -0000 Subject: [GHC] #10428: GHC cannot match representations using Coercible constraint In-Reply-To: <047.fbead4304e2da30bbf57add55471b5d0@haskell.org> References: <047.fbead4304e2da30bbf57add55471b5d0@haskell.org> Message-ID: <062.bbc6ddab5e930e25589a75c7d13db88e@haskell.org> #10428: GHC cannot match representations using Coercible constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10428 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 7.10.3 => 8.0.1 Comment: Sadly this won't be fixed in 7.10.3 either on account of the fix depending upon a rather large patch that would be quite tricky to backport (see #10494). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 12:29:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 12:29:31 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.05c2d7cb8ff9df5f3b2de7676c11f026@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: libraries/base | Version: 7.10.2 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:D1205 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 13:02:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 13:02:49 -0000 Subject: [GHC] #10242: Multiple constraint wildcards allowed with PartialTypeSignatures In-Reply-To: <049.a953ada63cab8a32d81242f76b55213a@haskell.org> References: <049.a953ada63cab8a32d81242f76b55213a@haskell.org> Message-ID: <064.2b0f4be4423050032b62f90bb5e6ffcc@haskell.org> #10242: Multiple constraint wildcards allowed with PartialTypeSignatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: thomasw Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: | PartialTypeSignatures Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: partial- invalid program | sigs/should_fail/ExtraConstraintsWildcardTwice Blocked By: | Blocking: Related Tickets: #10098 | Differential Rev(s): Phab:D613 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 7.10.3 => 8.0.1 Comment: This won't be going in to 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 13:17:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 13:17:24 -0000 Subject: [GHC] #10249: GHCi leaky abstraction: error message mentions `ghciStepIO` In-Reply-To: <051.818ff8bc84030bedfa7f9663d4a7c3ef@haskell.org> References: <051.818ff8bc84030bedfa7f9663d4a7c3ef@haskell.org> Message-ID: <066.dc83d22c2d33c0ba0e0859850a2603c8@haskell.org> #10249: GHCi leaky abstraction: error message mentions `ghciStepIO` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 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 bgamari): * failure: None/Unknown => Incorrect warning at compile-time * milestone: => 8.0.1 Old description: > {{{#!hs > $ ghci -fdefer-type-errors -ignore-dot-ghci > GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help > Prelude> _ > > :2:1: Warning: > Found hole ?_? with type: IO t0 > Where: ?t0? is an ambiguous type variable > In the first argument of ?GHC.GHCi.ghciStepIO :: > IO a_aly -> IO a_aly?, namely > ?_? > In a stmt of an interactive GHCi command: > it <- GHC.GHCi.ghciStepIO :: IO a_aly -> IO a_aly _ > *** Exception: :2:1: > Found hole ?_? with type: IO t0 > Where: ?t0? is an ambiguous type variable > In the first argument of ?GHC.GHCi.ghciStepIO :: > IO a_aly -> IO a_aly?, namely > ?_? > In a stmt of an interactive GHCi command: > it <- GHC.GHCi.ghciStepIO :: IO a_aly -> IO a_aly _ > (deferred type error) > Prelude> > }}} > > It should ideally not expose `ghciStepIO` to the user. New description: {{{ $ ghci -fdefer-type-errors -ignore-dot-ghci GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help Prelude> _ :2:1: Warning: Found hole ?_? with type: IO t0 Where: ?t0? is an ambiguous type variable In the first argument of ?GHC.GHCi.ghciStepIO :: IO a_aly -> IO a_aly?, namely ?_? In a stmt of an interactive GHCi command: it <- GHC.GHCi.ghciStepIO :: IO a_aly -> IO a_aly _ *** Exception: :2:1: Found hole ?_? with type: IO t0 Where: ?t0? is an ambiguous type variable In the first argument of ?GHC.GHCi.ghciStepIO :: IO a_aly -> IO a_aly?, namely ?_? In a stmt of an interactive GHCi command: it <- GHC.GHCi.ghciStepIO :: IO a_aly -> IO a_aly _ (deferred type error) Prelude> }}} It should ideally not expose `ghciStepIO` to the user. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 13:36:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 13:36:08 -0000 Subject: [GHC] #10506: SourceNotes are not applied to all identifiers In-Reply-To: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> References: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> Message-ID: <064.7224c9c04970c81b5b5c923c233c02ad@haskell.org> #10506: SourceNotes are not applied to all identifiers -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 scpmw): Right. Is this still current? If I remember correctly I tried to track down why my patch doesn't do the right thing here, but got lost somewhere. This is a really easy change, we should resolve it one way or the other. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 13:40:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 13:40:53 -0000 Subject: [GHC] #4295: Review higher-rank and impredicative types In-Reply-To: <046.deb0cd055a25dd8587cadf865ab4d37f@haskell.org> References: <046.deb0cd055a25dd8587cadf865ab4d37f@haskell.org> Message-ID: <061.bcc9e1189694a7034ee2dbde5d21b54b@haskell.org> #4295: Review higher-rank and impredicative types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: task | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 6.12.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: Simon, did this ever happen? It looks like most of the tests you list are okay, ||= test =||= status =|| || tc150 || ok || || tc194 || ok || || tcfail198 || ok || || tcfail174 || ok || || tcfail165 || ok || || tcfail145 || ok || || tcfail104 || ok || || tc211 || ok || || indexed-types/should_compile/T4120 || ok || || simpl017 || ok || || boxy/Base1 || broken due to #4295 || || boxy/Church1 || broken due to #4295 || || boxy/Church2 || broken due to #1330 || || boxy/PList1 || broken due to #4295 || || boxy/PList2 || broken due to #4295 || || boxy/SystemF || broken due to #4295 || || boxy/boxy || broken due to #4295 || || boxy/Compose || ok || || boxy/T2193 || ok || -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 13:45:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 13:45:29 -0000 Subject: [GHC] #5429: Docase notation as GHC extension In-Reply-To: <045.599f2cac9d50a43552a7650797f7452f@haskell.org> References: <045.599f2cac9d50a43552a7650797f7452f@haskell.org> Message-ID: <060.ac8c3b3a555ed144491f9634b33be95a@haskell.org> #5429: Docase notation as GHC extension -------------------------------------+------------------------------------- Reporter: tomasp | Owner: tomasp Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: Resolution: | Keywords: monad, | syntactic sugar, mzip, | comprehensions 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: > Many monads provide additional combinators for ''parallel composition'', > ''choice'' and ''aliasing''. In our Haskell Symposium 2011 paper > (http://www.cl.cam.ac.uk/~tp322/papers/docase.html) we call a monad with > these 3 additional combinators a '''joinad'''. > > The monads that implement (some of) these three operations include: > > * '''Par monad''' for parallel programming implements ''parallel > composition'' (run two computations in parallel) and ''aliasing'' (start > computation and access the result in multiple other computations) and can > be extended to support (non-deterministic) ''choice'' > * '''Parsers''' can implement ''parallel composition'' as an > intersection of languages (parse the same input using multiple parsers), > which is useful for encoding validation rules and ''choice'' (use the > result of a first parser that succeeds). > * '''Other monads''' that can be considered include the `Orc` monad > (for concurrent orchestration) and the encoding of CHP (Communicating > Haskell Processes). > > The proposal is to implement the a GHC extension that allows the `docase` > notation for working with ''joinads''. Using the `Par` monad as an > example, the following snippet implements a function `all` which tests > whether a predicate holds for all leaves of a tree: > > {{{ > all :: (a -> Bool) -> Tree a -> Par Bool > > all p (Leaf v) = return (p v) > all p (Node left right) = > docase all p left, all p right of > False, ? -> return False > ?, False -> return False > allL, allR -> return (allL && allR) > }}} > > The left and right sub-trees are processed in parallel (using ''parllel > composition''). The special pattern `?` denotes that the corresponding > computation does not have to complete in order for the clause to match. > This means that the first two clauses implement short-circuiting behavior > (and can match even if the other branch is still being processed). > > The operations used by the desugaring are expected to have the following > types: > > * `mzip :: m a -> m b -> m (a, b)`[[br]]This operation has been added by > the recent patch that re-implements ''monad comprehensions'', so we can > reuse it. > * `morelse :: m a -> m a -> m a`[[br]]The operation has the same type as > `mplus` from `MonadPlus`, but we require an operation that is left- > biased. One possible option is to add `MonadOr` type class as suggested > in http://www.haskell.org/haskellwiki/MonadPlus_reform_proposal. > * `malias :: m a -> m (m a)`[[br]]The operation "starts" a computation > and returns a handle for accessing the result. It has been used e.g. by > the authors of the `Orc` monad. For many simpler monads, this can be > implemented as monadic `return`. > > ===Feedback=== > I would appreciate any feedback from GHC users and developers! In > particular, here are some general, as well as more specific questions > that I've heard in the past: > > * What existing monads can implement the interface? (I believe there are > quite a few of them including `Par`, Parsers, `Orc`, CPH, but I'd love to > know about more.) > > * What to do about monads that implement only some operations? > Currently, the `malias` operation has default implementation. If a > `docase` notation has just a single clause, then `morelse` is not > required. If it has multiple clauses, each having just a single ''binding > pattern'' (non `?`) then `mzip` is not required. > > * The laws - the paper includes detailed discussion about laws (e.g. why > `mzip` should be symmetric and why `morelse` should have left-biase). > Does the community agree with the laws, or do you suggest some changes? > > * Syntax seems to be a tricky question - the notation intentionally > resembles `case`, but it takes a list of arguments (of type `m a1`, ..., > `m an`), so it is not using ''tuple syntax''. Is there any better > alternative? > > * Correspondence with ''monad comprehensions'' - the `docase` notation > can express parallel composition in a similar way as ''monad > comprehensions''. I think this parity is a good thing. However, it allows > more expressivity in one direction (by adding choice) and less in another > (no group/order by comprehensions). Do you think this is a good ballance? New description: Many monads provide additional combinators for ''parallel composition'', ''choice'' and ''aliasing''. In our Haskell Symposium 2011 paper (http://www.cl.cam.ac.uk/~tp322/papers/docase.html) we call a monad with these 3 additional combinators a '''joinad'''. The monads that implement (some of) these three operations include: * '''Par monad''' for parallel programming implements ''parallel composition'' (run two computations in parallel) and ''aliasing'' (start computation and access the result in multiple other computations) and can be extended to support (non-deterministic) ''choice'' * '''Parsers''' can implement ''parallel composition'' as an intersection of languages (parse the same input using multiple parsers), which is useful for encoding validation rules and ''choice'' (use the result of a first parser that succeeds). * '''Other monads''' that can be considered include the `Orc` monad (for concurrent orchestration) and the encoding of CHP (Communicating Haskell Processes). The proposal is to implement the a GHC extension that allows the `docase` notation for working with ''joinads''. Using the `Par` monad as an example, the following snippet implements a function `all` which tests whether a predicate holds for all leaves of a tree: {{{ all :: (a -> Bool) -> Tree a -> Par Bool all p (Leaf v) = return (p v) all p (Node left right) = docase all p left, all p right of False, ? -> return False ?, False -> return False allL, allR -> return (allL && allR) }}} The left and right sub-trees are processed in parallel (using ''parllel composition''). The special pattern `?` denotes that the corresponding computation does not have to complete in order for the clause to match. This means that the first two clauses implement short-circuiting behavior (and can match even if the other branch is still being processed). The operations used by the desugaring are expected to have the following types: * `mzip :: m a -> m b -> m (a, b)`[[br]]This operation has been added by the recent patch that re-implements ''monad comprehensions'', so we can reuse it. * `morelse :: m a -> m a -> m a`[[br]]The operation has the same type as `mplus` from `MonadPlus`, but we require an operation that is left-biased. One possible option is to add `MonadOr` type class as suggested in http://www.haskell.org/haskellwiki/MonadPlus_reform_proposal. * `malias :: m a -> m (m a)`[[br]]The operation "starts" a computation and returns a handle for accessing the result. It has been used e.g. by the authors of the `Orc` monad. For many simpler monads, this can be implemented as monadic `return`. ==Feedback== I would appreciate any feedback from GHC users and developers! In particular, here are some general, as well as more specific questions that I've heard in the past: * What existing monads can implement the interface? (I believe there are quite a few of them including `Par`, Parsers, `Orc`, CPH, but I'd love to know about more.) * What to do about monads that implement only some operations? Currently, the `malias` operation has default implementation. If a `docase` notation has just a single clause, then `morelse` is not required. If it has multiple clauses, each having just a single ''binding pattern'' (non `?`) then `mzip` is not required. * The laws - the paper includes detailed discussion about laws (e.g. why `mzip` should be symmetric and why `morelse` should have left-biase). Does the community agree with the laws, or do you suggest some changes? * Syntax seems to be a tricky question - the notation intentionally resembles `case`, but it takes a list of arguments (of type `m a1`, ..., `m an`), so it is not using ''tuple syntax''. Is there any better alternative? * Correspondence with ''monad comprehensions'' - the `docase` notation can express parallel composition in a similar way as ''monad comprehensions''. I think this parity is a good thing. However, it allows more expressivity in one direction (by adding choice) and less in another (no group/order by comprehensions). Do you think this is a good ballance? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 13:47:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 13:47:00 -0000 Subject: [GHC] #5429: Docase notation as GHC extension In-Reply-To: <045.599f2cac9d50a43552a7650797f7452f@haskell.org> References: <045.599f2cac9d50a43552a7650797f7452f@haskell.org> Message-ID: <060.3ea49087cfa93f209d607340fabfb11b@haskell.org> #5429: Docase notation as GHC extension -------------------------------------+------------------------------------- Reporter: tomasp | Owner: tomasp Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: Resolution: wontfix | Keywords: monad, | syntactic sugar, mzip, | comprehensions 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 Old description: > Many monads provide additional combinators for ''parallel composition'', > ''choice'' and ''aliasing''. In our Haskell Symposium 2011 paper > (http://www.cl.cam.ac.uk/~tp322/papers/docase.html) we call a monad with > these 3 additional combinators a '''joinad'''. > > The monads that implement (some of) these three operations include: > > * '''Par monad''' for parallel programming implements ''parallel > composition'' (run two computations in parallel) and ''aliasing'' (start > computation and access the result in multiple other computations) and can > be extended to support (non-deterministic) ''choice'' > * '''Parsers''' can implement ''parallel composition'' as an > intersection of languages (parse the same input using multiple parsers), > which is useful for encoding validation rules and ''choice'' (use the > result of a first parser that succeeds). > * '''Other monads''' that can be considered include the `Orc` monad > (for concurrent orchestration) and the encoding of CHP (Communicating > Haskell Processes). > > The proposal is to implement the a GHC extension that allows the `docase` > notation for working with ''joinads''. Using the `Par` monad as an > example, the following snippet implements a function `all` which tests > whether a predicate holds for all leaves of a tree: > > {{{ > all :: (a -> Bool) -> Tree a -> Par Bool > > all p (Leaf v) = return (p v) > all p (Node left right) = > docase all p left, all p right of > False, ? -> return False > ?, False -> return False > allL, allR -> return (allL && allR) > }}} > > The left and right sub-trees are processed in parallel (using ''parllel > composition''). The special pattern `?` denotes that the corresponding > computation does not have to complete in order for the clause to match. > This means that the first two clauses implement short-circuiting behavior > (and can match even if the other branch is still being processed). > > The operations used by the desugaring are expected to have the following > types: > > * `mzip :: m a -> m b -> m (a, b)`[[br]]This operation has been added by > the recent patch that re-implements ''monad comprehensions'', so we can > reuse it. > * `morelse :: m a -> m a -> m a`[[br]]The operation has the same type as > `mplus` from `MonadPlus`, but we require an operation that is left- > biased. One possible option is to add `MonadOr` type class as suggested > in http://www.haskell.org/haskellwiki/MonadPlus_reform_proposal. > * `malias :: m a -> m (m a)`[[br]]The operation "starts" a computation > and returns a handle for accessing the result. It has been used e.g. by > the authors of the `Orc` monad. For many simpler monads, this can be > implemented as monadic `return`. > > ==Feedback== > > I would appreciate any feedback from GHC users and developers! In > particular, here are some general, as well as more specific questions > that I've heard in the past: > > * What existing monads can implement the interface? (I believe there are > quite a few of them including `Par`, Parsers, `Orc`, CPH, but I'd love to > know about more.) > > * What to do about monads that implement only some operations? > Currently, the `malias` operation has default implementation. If a > `docase` notation has just a single clause, then `morelse` is not > required. If it has multiple clauses, each having just a single ''binding > pattern'' (non `?`) then `mzip` is not required. > > * The laws - the paper includes detailed discussion about laws (e.g. why > `mzip` should be symmetric and why `morelse` should have left-biase). > Does the community agree with the laws, or do you suggest some changes? > > * Syntax seems to be a tricky question - the notation intentionally > resembles `case`, but it takes a list of arguments (of type `m a1`, ..., > `m an`), so it is not using ''tuple syntax''. Is there any better > alternative? > > * Correspondence with ''monad comprehensions'' - the `docase` notation > can express parallel composition in a similar way as ''monad > comprehensions''. I think this parity is a good thing. However, it allows > more expressivity in one direction (by adding choice) and less in another > (no group/order by comprehensions). Do you think this is a good ballance? New description: Many monads provide additional combinators for ''parallel composition'', ''choice'' and ''aliasing''. In our Haskell Symposium 2011 paper (http://www.cl.cam.ac.uk/~tp322/papers/docase.html) we call a monad with these 3 additional combinators a '''joinad'''. The monads that implement (some of) these three operations include: * '''Par monad''' for parallel programming implements ''parallel composition'' (run two computations in parallel) and ''aliasing'' (start computation and access the result in multiple other computations) and can be extended to support (non-deterministic) ''choice'' * '''Parsers''' can implement ''parallel composition'' as an intersection of languages (parse the same input using multiple parsers), which is useful for encoding validation rules and ''choice'' (use the result of a first parser that succeeds). * '''Other monads''' that can be considered include the `Orc` monad (for concurrent orchestration) and the encoding of CHP (Communicating Haskell Processes). The proposal is to implement the a GHC extension that allows the `docase` notation for working with ''joinads''. Using the `Par` monad as an example, the following snippet implements a function `all` which tests whether a predicate holds for all leaves of a tree: {{{ all :: (a -> Bool) -> Tree a -> Par Bool all p (Leaf v) = return (p v) all p (Node left right) = docase all p left, all p right of False, ? -> return False ?, False -> return False allL, allR -> return (allL && allR) }}} The left and right sub-trees are processed in parallel (using ''parllel composition''). The special pattern `?` denotes that the corresponding computation does not have to complete in order for the clause to match. This means that the first two clauses implement short-circuiting behavior (and can match even if the other branch is still being processed). The operations used by the desugaring are expected to have the following types: * `mzip :: m a -> m b -> m (a, b)`[[br]]This operation has been added by the recent patch that re-implements ''monad comprehensions'', so we can reuse it. * `morelse :: m a -> m a -> m a`[[br]]The operation has the same type as `mplus` from `MonadPlus`, but we require an operation that is left-biased. One possible option is to add `MonadOr` type class as suggested in http://www.haskell.org/haskellwiki/MonadPlus_reform_proposal. * `malias :: m a -> m (m a)`[[br]]The operation "starts" a computation and returns a handle for accessing the result. It has been used e.g. by the authors of the `Orc` monad. For many simpler monads, this can be implemented as monadic `return`. == Feedback == I would appreciate any feedback from GHC users and developers! In particular, here are some general, as well as more specific questions that I've heard in the past: * What existing monads can implement the interface? (I believe there are quite a few of them including `Par`, Parsers, `Orc`, CPH, but I'd love to know about more.) * What to do about monads that implement only some operations? Currently, the `malias` operation has default implementation. If a `docase` notation has just a single clause, then `morelse` is not required. If it has multiple clauses, each having just a single ''binding pattern'' (non `?`) then `mzip` is not required. * The laws - the paper includes detailed discussion about laws (e.g. why `mzip` should be symmetric and why `morelse` should have left-biase). Does the community agree with the laws, or do you suggest some changes? * Syntax seems to be a tricky question - the notation intentionally resembles `case`, but it takes a list of arguments (of type `m a1`, ..., `m an`), so it is not using ''tuple syntax''. Is there any better alternative? * Correspondence with ''monad comprehensions'' - the `docase` notation can express parallel composition in a similar way as ''monad comprehensions''. I think this parity is a good thing. However, it allows more expressivity in one direction (by adding choice) and less in another (no group/order by comprehensions). Do you think this is a good balance? -- Comment: tomasp, I'm going to close this due to inactivity but feel free to reopen with a Phabricator Diff if you still want to see this happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 13:50:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 13:50:21 -0000 Subject: [GHC] #5646: Initialise tuples using pragmas In-Reply-To: <043.11d050ff9c9b8cd69039fd49ab15db39@haskell.org> References: <043.11d050ff9c9b8cd69039fd49ab15db39@haskell.org> Message-ID: <058.c79afb1ba3a8e790f26fecc5e0e7b498@haskell.org> #5646: Initialise tuples using pragmas -------------------------------------+------------------------------------- Reporter: chak | Owner: chak Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Data Parallel | Version: 7.3 Haskell | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => low Comment: I suspect this bug now refers to the FIXME in `compiler/vectorise/Vectorise/Builtins/Initialise.hs:initBuiltinVars`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 13:55:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 13:55:19 -0000 Subject: [GHC] #10678: integer-gmp's runS seems unnecessarily expensive In-Reply-To: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> References: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> Message-ID: <062.d23d2c33ef26e1a21af489c7b0e08be8@haskell.org> #10678: integer-gmp's runS seems unnecessarily expensive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 (CodeGen) | 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.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 13:56:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 13:56:31 -0000 Subject: [GHC] #10678: integer-gmp's runS seems unnecessarily expensive In-Reply-To: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> References: <047.1e3027d49179affc6473e88cc8dec51a@haskell.org> Message-ID: <062.4c634ca9332e74fc579102fe1710bb87@haskell.org> #10678: integer-gmp's runS seems unnecessarily expensive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 (CodeGen) | 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:D1103 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1103 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 13:59:14 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 13:59:14 -0000 Subject: [GHC] #8004: Applicative/Monad proposal related warnings (AMP phase 1) In-Reply-To: <045.ee77ea6713da1cec5c3314c4ae999d7f@haskell.org> References: <045.ee77ea6713da1cec5c3314c4ae999d7f@haskell.org> Message-ID: <060.af71b83d3b6fcb6c9ae7fc84a1de8cca@haskell.org> #8004: Applicative/Monad proposal related warnings (AMP phase 1) -------------------------------------+------------------------------------- Reporter: quchen | Owner: quchen Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4834 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by songzh): I am so curious that I want to ask for the second case "You have an instance of Monad, but not Applicative" why cann't we add default implementation to Applicative typeclass? {{{ class Functor f => Applicative f where pure :: a -> f a default pure :: Monad f => a -> f a pure = return (<*>) :: f (a -> b) -> f a -> f b default (<*>) :: Monad f => f (a -> b) -> f a -> f b (<*>) f a = ap }}} Replying to [comment:14 Austin Seipp ]: > In [changeset:75a9664af1c4e6f87794b49a215adb235b20696d/ghc]: > {{{ > #!CommitTicketReference repository="ghc" revision="75a9664af1c4e6f87794b49a215adb235b20696d" > Implement the AMP warning (#8004) > > This patch implements a warning when definitions conflict with the > Applicative-Monad Proposal (AMP), described in #8004. Namely, this will > cause a warning iff: > > * You have an instance of Monad, but not Applicative > * You have an instance of MonadPlus, but not Alternative > * You locally defined a function named join, <*>, or pure. > > In GHC 7.10, these warnings will actually be enforced with superclass > constraints through changes in base, so programs will fail to compile > then. > > This warning is enabled by default. Unfortunately, not all of > our upstream libraries have accepted the appropriate patches. So we > temporarily fix ./validate by ignoring the AMP warning. > > Dan Ros?n made an initial implementation of this change, and the > remaining work was finished off by David Luposchainsky. I finally made > some minor refactorings. > > Authored-by: Dan Ros?n > Authored-by: David Luposchainsky > Signed-off-by: Austin Seipp > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 14:02:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 14:02:25 -0000 Subject: [GHC] #11001: BlockedIndefinitelyOnMVar thrown with live reference in unrelated finalizer Message-ID: <046.2cc9f3eed9ffb6efbcf5550718daab5b@haskell.org> #11001: BlockedIndefinitelyOnMVar thrown with live reference in unrelated finalizer -------------------------------------+------------------------------------- Reporter: exFalso | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | Keywords: | Operating System: Linux BlockedIndefinitelyOnMVar | finalize | Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I am not sure whether this is a bug, but it is certainly unexpected behaviour. The following code throws a BlockedIndefinitelyOnMVar in the forked thread even though the MVar would be eventually written to by an unrelated finalizer: {{{#!hs import Control.Concurrent import Data.IORef main :: IO () main = do mvar <- newEmptyMVar -- _ <- forkIO $ threadDelay 9999999999999 >> isEmptyMVar mvar >> return () ref <- newIORef () -- unrelated IORef _ <- mkWeakIORef ref (putMVar mvar ()) -- register finalizer _ <- forkFinally (takeMVar mvar :: IO ()) print threadDelay 1000000 }}} And indeed, if the forkIO line is uncommented no exception is thrown, as the new thread keeps another live reference to the MVar. Is this intended behaviour? Why does the MVar reference in the finalizer not count for BlockedIndefinitelyOnMVar? (A similar thing happens with STM primitives.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 14:11:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 14:11:33 -0000 Subject: [GHC] #11002: man page incomplete sentences Message-ID: <043.6c07cf1351e9e72cea43c49457e15d1e@haskell.org> #11002: man page incomplete sentences -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- man page multiple entries like this: {{{ Interactive mode - normally used by just running ghci; see for details. be much easier, and faster, than using make; see for details.. Evaluate expr; see for details. }}} `see ... for details` the dotted part is missing. Probably a bug in the man page generator? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 14:18:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 14:18:29 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.5b2dd20aff3dd17db532b1e862693de6@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, Wiki Page: | Phab:D1268 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9cb192ce4b34a472041010df9c30f5d741eb0261/ghc" 9cb192ce/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9cb192ce4b34a472041010df9c30f5d741eb0261" Make stronglyConnCompFromEdgedVertices deterministic This makes it so the result of computing SCC's depends on the order the nodes were passed to it, but not on the order on the user provided key type. The key type is usually `Unique` which is known to be nondeterministic. Test Plan: `text` and `aeson` become deterministic after this ./validate Compare compile time for `text`: ``` $ cabal get text && cd text* && cabal sandbox init && cabal install --dependencies-only && time cabal build real 0m59.459s user 0m57.862s sys 0m1.185s $ cabal clean && time cabal build real 1m0.037s user 0m58.350s sys 0m1.199s $ cabal clean && time cabal build real 0m57.634s user 0m56.118s sys 0m1.202s $ cabal get text && cd text* && cabal sandbox init && cabal install --dependencies-only && time cabal build real 0m59.867s user 0m58.176s sys 0m1.188s $ cabal clean && time cabal build real 1m0.157s user 0m58.622s sys 0m1.177s $ cabal clean && time cabal build real 1m0.950s user 0m59.397s sys 0m1.083s ``` Reviewers: ezyang, simonmar, austin, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1268 GHC Trac Issues: #4012 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 14:27:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 14:27:38 -0000 Subject: [GHC] #4295: Review higher-rank and impredicative types In-Reply-To: <046.deb0cd055a25dd8587cadf865ab4d37f@haskell.org> References: <046.deb0cd055a25dd8587cadf865ab4d37f@haskell.org> Message-ID: <061.bedc47fe6043e2652078949cf29904b7@haskell.org> #4295: Review higher-rank and impredicative types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: task | Status: infoneeded Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 6.12.3 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 simonpj): No I have not looked at this for ages. Impredicativity is simply not a supported feature at the moment. If things are passing, then let them pass. If you have to change expect_broken to pass, then put a comment in the .hs file to point to this ticket and say that it might be wobbly because of impredicativity. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 14:30:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 14:30:21 -0000 Subject: [GHC] #11003: Suggested fix for incorrect directory permissions is wrong Message-ID: <045.25a161e6764c461b83590c7bfbd5412a@haskell.org> #11003: Suggested fix for incorrect directory permissions is wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.3 Component: GHCi | Version: 7.10.2 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: -------------------------------------+------------------------------------- If the current directory is group- or world- writable, I get an error {{{ *** WARNING: /home/blahblah/src/yproj is writable by someone else, IGNORING! Suggested fix: execute 'chmod 644 /home/blahblah/src/yproj' }}} This is extremely bad advice, because `644 = rw-r--r--`, meaning the directory is not executable, so nothing it contains can be accessed, and a user who's insufficiently familiar with Unix permissions will be very confused. The message should instead suggest `755=rwxr-xr-x`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 14:42:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 14:42:39 -0000 Subject: [GHC] #11003: Suggested fix for incorrect directory permissions is wrong In-Reply-To: <045.25a161e6764c461b83590c7bfbd5412a@haskell.org> References: <045.25a161e6764c461b83590c7bfbd5412a@haskell.org> Message-ID: <060.474e9c7a7010dc8b71c162e8c094eca1@haskell.org> #11003: Suggested fix for incorrect directory permissions is wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.3 Component: GHCi | 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: | Differential Rev(s): Phab:D1350 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1350 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 14:50:07 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 14:50:07 -0000 Subject: [GHC] #11003: Suggested fix for incorrect directory permissions is wrong In-Reply-To: <045.25a161e6764c461b83590c7bfbd5412a@haskell.org> References: <045.25a161e6764c461b83590c7bfbd5412a@haskell.org> Message-ID: <060.d333815648f9a4957ee2cac630d744b4@haskell.org> #11003: Suggested fix for incorrect directory permissions is wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.3 Component: GHCi | 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: #8248 | Differential Rev(s): Phab:D1350 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #8248 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 14:57:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 14:57:48 -0000 Subject: [GHC] #11002: man page incomplete sentences In-Reply-To: <043.6c07cf1351e9e72cea43c49457e15d1e@haskell.org> References: <043.6c07cf1351e9e72cea43c49457e15d1e@haskell.org> Message-ID: <058.c2dd087754ff9ba705882646c614f32e@haskell.org> #11002: man page incomplete sentences -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: > man page multiple entries like this: > > {{{ > Interactive mode - normally used by just running ghci; see > for details. > > be much easier, and faster, than using make; see for > details.. > > Evaluate expr; see for details. > > }}} > > `see ... for details` the dotted part is missing. Probably a bug in the > man page generator? New description: man page has multiple entries like this: {{{ ... Interactive mode - normally used by just running ghci; see for details. ... be much easier, and faster, than using make; see for details.. ... Evaluate expr; see for details. }}} `see ... for details` the dotted part is missing. Probably a bug in the man page generator? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 14:58:07 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 14:58:07 -0000 Subject: [GHC] #11002: man page has incomplete sentences (was: man page incomplete sentences) In-Reply-To: <043.6c07cf1351e9e72cea43c49457e15d1e@haskell.org> References: <043.6c07cf1351e9e72cea43c49457e15d1e@haskell.org> Message-ID: <058.1a7dcdccebd376ed81d40897e5dc79ee@haskell.org> #11002: man page has incomplete sentences -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 14:58:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 14:58:42 -0000 Subject: [GHC] #11002: man page incomplete sentences (was: man page has incomplete sentences) In-Reply-To: <043.6c07cf1351e9e72cea43c49457e15d1e@haskell.org> References: <043.6c07cf1351e9e72cea43c49457e15d1e@haskell.org> Message-ID: <058.1b7aa034692c103edc360da1b53b52b4@haskell.org> #11002: man page incomplete sentences -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > man page has multiple entries like this: > > {{{ > ... Interactive mode - normally used by just running ghci; see for > details. > > ... be much easier, and faster, than using make; see for details.. > > ... Evaluate expr; see for details. > }}} > > `see ... for details` the dotted part is missing. Probably a bug in the > man page generator? New description: man page multiple entries like this: {{{ Interactive mode - normally used by just running ghci; see for details. be much easier, and faster, than using make; see for details.. Evaluate expr; see for details. }}} `see ... for details` the dotted part is missing. Probably a bug in the man page generator? -- Comment (by bgamari): What Sphinx version are you using? I'm afraid I can't reproduce this with 1.3.1. I see this, {{{ Modes of operation --help,-? Display help --interactive Interactive mode - normally used by just running ghci; see ghci for details. --make Build a multi-module Haskell program, automatically figuring out dependencies. Likely to be much easier, and faster, than using make; see make-mode for details. }}} The links (e.g. `ghci` and `make-mode`) obviously aren't hyperlinks although I'm not entirely sure how to fix this given that man doesn't support arbitrary hyperlinks. Ideally Sphinx would transform these into somethink like "see the GHCi section of the Users' Guide for details." but this is clearly expecting a lot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 15:01:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 15:01:05 -0000 Subject: [GHC] #11002: man page has incomplete sentences (was: man page incomplete sentences) In-Reply-To: <043.6c07cf1351e9e72cea43c49457e15d1e@haskell.org> References: <043.6c07cf1351e9e72cea43c49457e15d1e@haskell.org> Message-ID: <058.3d712d76d161ff211ba6bb23933ecb63@haskell.org> #11002: man page has incomplete sentences -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: > man page multiple entries like this: > > {{{ > Interactive mode - normally used by just running ghci; see > for details. > > be much easier, and faster, than using make; see for > details.. > > Evaluate expr; see for details. > > }}} > > `see ... for details` the dotted part is missing. Probably a bug in the > man page generator? New description: man page multiple entries like this: {{{ ... Interactive mode - normally used by just running ghci; see for details. ... be much easier, and faster, than using make; see for details.. ... Evaluate expr; see for details. }}} `see ... for details` the dotted part is missing. Probably a bug in the man page generator? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 15:03:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 15:03:57 -0000 Subject: [GHC] #11002: man page has incomplete sentences In-Reply-To: <043.6c07cf1351e9e72cea43c49457e15d1e@haskell.org> References: <043.6c07cf1351e9e72cea43c49457e15d1e@haskell.org> Message-ID: <058.966ab9d915870ea1892ccb319d09e900@haskell.org> #11002: man page has incomplete sentences -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Documentation | Version: 7.10.2 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: Ahh, I had assumed this was on `master` but no, you are looking at 7.10.2 for which the manpage is generated by an XSLT stylesheet. It's no surprise that this is broken, it's always been a bit flaky. That being said, I really don't think it's worth fixing given that the 7.10.3 will be the last release to use it now since we have Sphinx. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 15:10:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 15:10:33 -0000 Subject: [GHC] #3351: Generated ghc man page missing xrefs In-Reply-To: <043.e70675efe6c1e6fb67be6a4568f6dd0d@haskell.org> References: <043.e70675efe6c1e6fb67be6a4568f6dd0d@haskell.org> Message-ID: <058.3d0a2f36f44f6f4075edeaf9a2991b1e@haskell.org> #3351: Generated ghc man page missing xrefs -------------------------------------+------------------------------------- Reporter: kaol | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Documentation | Version: 6.10.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): Things are slightly better now since we generate the manpage via Sphinx, although there is still room for improvement. You now see something like this, {{{ -Wall enable almost all warnings (details in options-sanity) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 15:12:17 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 15:12:17 -0000 Subject: [GHC] #3351: Generated ghc man page missing xrefs In-Reply-To: <043.e70675efe6c1e6fb67be6a4568f6dd0d@haskell.org> References: <043.e70675efe6c1e6fb67be6a4568f6dd0d@haskell.org> Message-ID: <058.c7f8d577d0a8ce249f84c07fd497cacc@haskell.org> #3351: Generated ghc man page missing xrefs -------------------------------------+------------------------------------- Reporter: kaol | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 8.0.1 Component: Documentation | Version: 6.10.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 thomie): * status: new => closed * resolution: => fixed Comment: Good enough, let's close this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 15:13:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 15:13:32 -0000 Subject: [GHC] #10992: Performance regression due to lack of inlining of `foldl` and `foldl'`. In-Reply-To: <046.c9e7f7c6b0bdb50720ba035d3861748a@haskell.org> References: <046.c9e7f7c6b0bdb50720ba035d3861748a@haskell.org> Message-ID: <061.086069c783ba75abfd20acd02f123ae6@haskell.org> #10992: Performance regression due to lack of inlining of `foldl` and `foldl'`. -------------------------------------+------------------------------------- Reporter: aleator | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: performane Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): comment:3 sounds plausible to me. Needs a `Note` to explain! (And a nofib run.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 15:31:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 15:31:33 -0000 Subject: [GHC] #10996: family is treated as keyword in types even without TypeFamilies enabled In-Reply-To: <045.27f49ff532e9a720de796a9ae0ad68ae@haskell.org> References: <045.27f49ff532e9a720de796a9ae0ad68ae@haskell.org> Message-ID: <060.a54017d90b9a87fdb8031fbf756df810@haskell.org> #10996: family is treated as keyword in types even without TypeFamilies enabled -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: type Test valid program | family = family Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by oerjan): I think this would have been so much easier to hack around if there were a way to tell Happy that a rule should resolve all its shift/reduce conflicts by reducing, without assigning precedence to any tokens (which could mess up ''other'' shift/reduce resolutions). Then you'd just declare two tokens `family_kw` and `role_kw`, and two rules {{{ ... family_kw : 'family' %prefer_reduction { ... } ... role_kw : 'role' %prefer_reduction { ... } }}} and use those tokens instead in the keyword-using declarations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 15:32:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 15:32:48 -0000 Subject: [GHC] #11003: Suggested fix for incorrect directory permissions is wrong In-Reply-To: <045.25a161e6764c461b83590c7bfbd5412a@haskell.org> References: <045.25a161e6764c461b83590c7bfbd5412a@haskell.org> Message-ID: <060.f77145e7a8d399ce035233d1b313f2b1@haskell.org> #11003: Suggested fix for incorrect directory permissions is wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.3 Component: GHCi | 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: #8248 | Differential Rev(s): Phab:D1350 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0ae6a43ebccca65c3a6b6172e0513802d303e84e/ghc" 0ae6a43/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0ae6a43ebccca65c3a6b6172e0513802d303e84e" Suggest chmod 755 instead of 644 Previous suggestion would clear executable bit, meaning directory couldn't be entered. Fixes #11003. Test Plan: Read message. Reviewers: austin, thomie, dfeuer Reviewed By: thomie, dfeuer Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1350 GHC Trac Issues: #11003 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 15:33:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 15:33:10 -0000 Subject: [GHC] #11003: Suggested fix for incorrect directory permissions is wrong In-Reply-To: <045.25a161e6764c461b83590c7bfbd5412a@haskell.org> References: <045.25a161e6764c461b83590c7bfbd5412a@haskell.org> Message-ID: <060.f7a6730d54a19a51d21fd36b16daafa4@haskell.org> #11003: Suggested fix for incorrect directory permissions is wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: GHCi | 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: #8248 | Differential Rev(s): Phab:D1350 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 15:33:36 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 15:33:36 -0000 Subject: [GHC] #11003: Suggested fix for incorrect directory permissions is wrong In-Reply-To: <045.25a161e6764c461b83590c7bfbd5412a@haskell.org> References: <045.25a161e6764c461b83590c7bfbd5412a@haskell.org> Message-ID: <060.ac082b81764f04617a832723697c5661@haskell.org> #11003: Suggested fix for incorrect directory permissions is wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.3 Component: GHCi | 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: #8248 | Differential Rev(s): Phab:D1350 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Also merging to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 15:46:35 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 15:46:35 -0000 Subject: [GHC] #10987: -i option requires named module In-Reply-To: <047.1e49d068fee786f184a634b0d96d3438@haskell.org> References: <047.1e49d068fee786f184a634b0d96d3438@haskell.org> Message-ID: <062.1cf325506b0ea3fb5d0e0185f44eac98@haskell.org> #10987: -i option requires named module -------------------------------------+------------------------------------- Reporter: crockeea | Owner: osa1 Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Here's one more thing about this issue. In the same layout: {{{ ? trac10987 ghci -itest Bar.hs GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help : can't find file: Bar.hs Failed, modules loaded: none. }}} I'd think this is OK, but the user manuals says: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/separate- compilation.html#search-path > In --make mode or GHCi, GHC will look for a source file for Foo and arrange > to compile it first. ... > GHC uses the same strategy in each of these cases for finding the appropriate > file. > > This strategy is as follows: GHC keeps a list of directories called the > search path. For each of these directories, it tries appending > basename.extension to the directory, and checks whether the file exists. The > value of basename is the module name with dots replaced by the directory > separator ('/' or '\', depending on the system), and extension is a source > extension (hs, lhs) if we are in --make mode or GHCi, or hisuf otherwise. ... > -idirs > This flag appends a colon-separated list of dirs to the search path. From the user manual is seems like GHC should have looked into directories in `-i`. We should either update the user manual or modify GHC. Personally, I think GHC should never use `-i` when looking for files, and it should never look for files unless the input has a file format. Otherwise there'll always be some confusing when a file is found, but module loder could also find the same file, because file loader makes no assumptions on what module to find in the file but module loader makes an assumption about this, leading to different outcomes depending on which one runs. Also, man page says "finding imports" for `-i` and it doesn't say anything about "search path" or how files are searched etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 16:21:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 16:21:51 -0000 Subject: [GHC] #10987: -i option requires named module In-Reply-To: <047.1e49d068fee786f184a634b0d96d3438@haskell.org> References: <047.1e49d068fee786f184a634b0d96d3438@haskell.org> Message-ID: <062.d0c65dfb0755b2131b95d19c002c9061@haskell.org> #10987: -i option requires named module -------------------------------------+------------------------------------- Reporter: crockeea | Owner: osa1 Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): One more thing, if GHC decides to use `-i` when searching files, then what happens in this case: {{{ Layout: A/Foo.hs B/Foo.hs $ ghci -iA,B Foo }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 16:36:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 16:36:48 -0000 Subject: [GHC] #10800: vector-0.11 compile time increased substantially with 7.10.1 In-Reply-To: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> References: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> Message-ID: <061.76787b6ff543d39db6d540bc0facd57a@haskell.org> #10800: vector-0.11 compile time increased substantially with 7.10.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 thomie): Compiling `vector` master with HEAD using a devel2 build (which means a stage2 compiler built with `-DDEBUG`), results in a low of warnings such as the following: {{{ *** Core Lint warnings : in result of Simplifier *** libraries/vector/Data/Vector/Generic.hs:221:1: warning: [RHS of length :: forall (v_a3hG :: * -> *) a_a3hH. Vector v_a3hG a_a3hH => v_a3hG a_a3hH -> Int] INLINE binder is (non-rule) loop breaker: length libraries/vector/Data/Vector/Generic.hs:1891:1: warning: [RHS of unsafeCopy :: forall (v_a38Q :: * -> *) (m_a38R :: * -> *) a_a38S. (PrimMonad m_a38R, Vector v_a38Q a_a38S) => Mutable v_a38Q (PrimState m_a38R) a_a38S -> v_a38Q a_a38S -> m_a38R ()] INLINE binder is (non-rule) loop breaker: unsafeCopy }}} Maybe this gives a clue to what the problem is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 16:38:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 16:38:13 -0000 Subject: [GHC] #10800: vector-0.11 compile time increased substantially with 7.10.1 In-Reply-To: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> References: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> Message-ID: <061.0980569d7526384b20fecde471c5de3f@haskell.org> #10800: vector-0.11 compile time increased substantially with 7.10.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 thomie): * cc: dolio (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 17:02:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 17:02:56 -0000 Subject: [GHC] #8731: long compilation time for module with large data type and partial record selectors In-Reply-To: <045.6f5d3f3131abc76d740d2ebe2eaf5820@haskell.org> References: <045.6f5d3f3131abc76d740d2ebe2eaf5820@haskell.org> Message-ID: <060.ac3f87fa9ac819224e3d8b828968c551@haskell.org> #8731: long compilation time for module with large data type and partial record selectors -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.1-rc1 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): Looks like this may be related to instance deriving, perhaps a duplicate of #10980. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 17:07:01 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 17:07:01 -0000 Subject: [GHC] #8004: Applicative/Monad proposal related warnings (AMP phase 1) In-Reply-To: <045.ee77ea6713da1cec5c3314c4ae999d7f@haskell.org> References: <045.ee77ea6713da1cec5c3314c4ae999d7f@haskell.org> Message-ID: <060.eb00717ab3553ac6678e186d46c38cf0@haskell.org> #8004: Applicative/Monad proposal related warnings (AMP phase 1) -------------------------------------+------------------------------------- Reporter: quchen | Owner: quchen Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4834 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Replying to [comment:23 songzh]: > I am so curious that I want to ask for the case "You have an instance of Monad, but not Applicative" > why cann't we add default implementation to Applicative typeclass? > {{{ > class Functor f => Applicative f where > pure :: a -> f a > default pure :: Monad f => a -> f a > pure = return At least in the case of `pure` and `return` we have the default definition of `return` in terms of `pure`. That flow the 'right' way through the class hierarchy and doesn't require an extension. Doing both that and this yields a cycle with no way to detect it through `MINIMAL` pragmas and the like, which can't straddle two classes. > (<*>) :: f (a -> b) -> f a -> f b > default (<*>) :: Monad f => f (a -> b) -> f a -> f b > (<*>) f a = ap > }}} This one could be done. It'd require a willingness to have an attempt to implement `Applicative` that doesn't supply a `(<*>)` to be a compile error rather than a warning, however. (A state that can arise as you write incrementally.) It is a fairly minor concern, but given the difficulty of pushing through Prelude related changes one that __may__ be a sufficient blocker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 17:23:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 17:23:44 -0000 Subject: [GHC] #10370: Compile time regression in OpenGLRaw In-Reply-To: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> References: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> Message-ID: <061.0d38fe162f611d17989304f90d3547bc@haskell.org> #10370: Compile time regression in OpenGLRaw -------------------------------------+------------------------------------- Reporter: michalt | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 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: | -------------------------------------+------------------------------------- Comment (by bgamari): I'ved opened Phab:D1352 to add a performance test for this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 17:35:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 17:35:55 -0000 Subject: [GHC] #10289: compiling huge HashSet hogs memory In-Reply-To: <044.7a75381e3cbd52797d1fc50b07f81ee0@haskell.org> References: <044.7a75381e3cbd52797d1fc50b07f81ee0@haskell.org> Message-ID: <059.bbaf6ea48837d79645be4c3c4ed1e200@haskell.org> #10289: compiling huge HashSet hogs memory -------------------------------------+------------------------------------- Reporter: zudov | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: zudov, I'm having trouble reproducing this. With ghc 7.10.2, `unordered- containers-0.2.5.1`, and `text-1.2.1.3` I find the following, {{{ $ ghc -O EntitySet.hs -fforce-recomp -ddump-inlinings +RTS -s [1 of 1] Compiling Text.Html.Entity.Data.EntitySet ( EntitySet.hs, EntitySet.o ) Inlining done: Data.HashSet.fromList Inlining done: Data.HashMap.Base.empty Inlining done: Data.Text.pack Inlining done: GHC.Base.build Inlining done: Data.Text.pack Inlining done: GHC.Base.build ... # goes on for a few thousand lines Inlining done: Data.Text.pack Inlining done: GHC.Base.build Inlining done: GHC.Base.foldr Inlining done: GHC.Base.id 2,541,860,520 bytes allocated in the heap 412,058,088 bytes copied during GC 57,559,000 bytes maximum residency (11 sample(s)) 3,015,736 bytes maximum slop 140 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 776 colls, 0 par 0.405s 0.406s 0.0005s 0.0141s Gen 1 11 colls, 0 par 0.261s 0.261s 0.0237s 0.0615s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.003s ( 0.003s elapsed) MUT time 1.533s ( 1.660s elapsed) GC time 0.666s ( 0.667s elapsed) EXIT time 0.018s ( 0.018s elapsed) Total time 2.232s ( 2.349s elapsed) Alloc rate 1,658,595,906 bytes per MUT second Productivity 70.0% of total user, 66.5% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 }}} The inlinings you are observing sounds quite reminiscent of #10528, which should be fixed with `text-1.2.1.3`. Could you test this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 19:13:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 19:13:52 -0000 Subject: [GHC] #11004: hsc2hs does not handle single quotes properly Message-ID: <044.0bda8c5df856d596df18293a23a5f521@haskell.org> #11004: hsc2hs does not handle single quotes properly -------------------------------------+------------------------------------- Reporter: sergv | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The tool gets confused by quotes for promoted constructors (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/promotion.html #promotion-syntax). Here's an example: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} data Foo = Foo | Bar data Indexed ix where Indexed :: Indexed 'Foo main :: IO () main = print $ #size int }}} gets translated into {{{#!hs {-# LINE 1 "Test.hsc" #-} {-# LANGUAGE DataKinds #-} {-# LINE 2 "Test.hsc" #-} {-# LANGUAGE GADTs #-} data Foo = Foo | Bar data Indexed ix where Indexed :: Indexed 'Foo main :: IO () main = print $ #size int }}} Then GHC complains about `#size`: {{{ Test.hsc:10:16: parse error on input ?#? }}} Judging from the source of utils/hsc2hs/HSCParser.hs, the tool treats single quotes the same way as double quotes. I.e. it looks for balanced, possibly multiline, strings delimited by '. At least, it seems unnecessary to expect newlines in that string-like structure, because character literals cannot contain newlines, AFAIK. It's interesting to note that this problem looks like a bit of an edge case, since highlighting in the ticket seems to be confused as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 19:14:30 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 19:14:30 -0000 Subject: [GHC] #11004: hsc2hs does not handle single quotes properly In-Reply-To: <044.0bda8c5df856d596df18293a23a5f521@haskell.org> References: <044.0bda8c5df856d596df18293a23a5f521@haskell.org> Message-ID: <059.ba8100d594a929213f2a02c514d1b207@haskell.org> #11004: hsc2hs does not handle single quotes properly -------------------------------------+------------------------------------- Reporter: sergv | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sergv): * Attachment "Test.hsc" added. Sample that triggers the bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 19:32:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 19:32:00 -0000 Subject: [GHC] #11004: hsc2hs does not handle single quotes properly In-Reply-To: <044.0bda8c5df856d596df18293a23a5f521@haskell.org> References: <044.0bda8c5df856d596df18293a23a5f521@haskell.org> Message-ID: <059.b72296b1a66d047b80358e2baaa889e6@haskell.org> #11004: hsc2hs does not handle single quotes properly -------------------------------------+------------------------------------- Reporter: sergv | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.10.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: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer Comment: Thank you for the report. Since you looked at the code already: would you like to submit a patch? See [wiki:Newcomers] and [wiki:WorkingConventions/FixingBugs]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 19:34:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 19:34:29 -0000 Subject: [GHC] #10997: Pattern synonym causes Iface error. In-Reply-To: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> References: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> Message-ID: <064.f8c40eb15b0b6ed03e496f5ad0bb88ce@haskell.org> #10997: Pattern synonym causes Iface error. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10997 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): I am also affected by this bug when using `-fobject-code`. Given {{{ #!haskell {-# LANGUAGE GADTs, PatternSynonyms #-} module Foo where data Exp ty where LitB :: Bool -> Exp Bool pattern Tru :: b ~ Bool => Exp b pattern Tru = LitB True }}} and {{{ #!haskell module Bar where import Foo foo :: Exp a -> String foo Tru = "True" }}} results in the following session: {{{ % ghci -ignore-dot-ghci GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> :load Bar [1 of 2] Compiling Foo ( Foo.hs, interpreted ) [2 of 2] Compiling Bar ( Bar.hs, interpreted ) Ok, modules loaded: Bar, Foo. *Bar> :set -fobject-code *Bar> :load Foo [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Ok, modules loaded: Foo. Prelude Foo> :load Bar [2 of 2] Compiling Bar ( Bar.hs, Bar.o ) The interface for ?Foo? Declaration for Tru Pattern synonym Tru: Iface type variable out of scope: k Cannot continue after interface file error > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 19:34:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 19:34:56 -0000 Subject: [GHC] #11004: hsc2hs does not handle single quotes properly In-Reply-To: <044.0bda8c5df856d596df18293a23a5f521@haskell.org> References: <044.0bda8c5df856d596df18293a23a5f521@haskell.org> Message-ID: <059.025bb69d71a862b0cc096fca4ef0c0ec@haskell.org> #11004: hsc2hs does not handle single quotes properly -------------------------------------+------------------------------------- Reporter: sergv | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.10.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 sergv): Yes, I'd like to fix this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 19:36:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 19:36:05 -0000 Subject: [GHC] #10997: Pattern synonym causes Iface error. In-Reply-To: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> References: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> Message-ID: <064.9852cbb5175813f5dddde495035c9ba8@haskell.org> #10997: Pattern synonym causes Iface error. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10997 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Also triggered by: {{{ % ghc Foo [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) % ghc Bar [2 of 2] Compiling Bar ( Bar.hs, Bar.o ) The interface for ?Foo? Declaration for Tru Pattern synonym Tru: Iface type variable out of scope: k Cannot continue after interface file error }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 19:39:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 19:39:08 -0000 Subject: [GHC] #11004: hsc2hs does not handle single quotes properly In-Reply-To: <044.0bda8c5df856d596df18293a23a5f521@haskell.org> References: <044.0bda8c5df856d596df18293a23a5f521@haskell.org> Message-ID: <059.b91a011e2d8ecfaab12e1c4204914b35@haskell.org> #11004: hsc2hs does not handle single quotes properly -------------------------------------+------------------------------------- Reporter: sergv | Owner: sergv Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.10.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: | -------------------------------------+------------------------------------- Changes (by sergv): * owner: => sergv -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 20:44:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 20:44:23 -0000 Subject: [GHC] #11005: GHC's build system can't deal with ghc install path with multiple spaces in it Message-ID: <045.0d928970c6a7b251f3729849ff0cfe3e@haskell.org> #11005: GHC's build system can't deal with ghc install path with multiple spaces in it -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: lowest | Milestone: ? Component: Build System | Version: 7.11 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: -------------------------------------+------------------------------------- Essentially, there are a bunch of places in the build system where we forget to quote paths, and so the spaces collapse into a single space and the paths fail. I fixed a few low hanging instances of this but I got hsc2hs to fail: {{{ "inplace/bin/hsc2hs" '--cc=/bin/gcc' '--ld=/bin/gcc' --cross-safe --cflag=-Wall --cflag=-fno-stack-protector --cflag=-Dx86_64_HOST_ARCH=1 --cflag=-Dlinux_HOST_OS=1 --cflag=-D__GLASGOW_HASKELL__=711 '--cflag=-fno- stack-protector' '--cflag=-Wall' '--cflag=-Icompiler/stage1/build/autogen' '--cflag=-Icompiler/.' '--cflag=-Icompiler/parser' '-- cflag=-Icompiler/utils' '--cflag=-Icompiler/stage1' '-- cflag=-I/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/process-1.2.3.0/include' '-- cflag=-I/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/directory-1.2.2.0/include' '-- cflag=-I/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/unix-2.7.1.0/include' '-- cflag=-I/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/time-1.5.0.1/include' '-- cflag=-I/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/bytestring-0.10.6.0/include' '-- cflag=-I/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/base-4.8.2.0/include' '-- cflag=-I/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/integer-gmp-1.0.0.0/include' '-- cflag=-I/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/include' '--cflag=-Werror=unused-but-set- variable' '--cflag=-Wno-error=inline' '--lflag=-L/home/hs01/ezyang/ghc- bootstrap/libraries/transformers/dist-boot/build' '-- lflag=-L/home/hs01/ezyang/ghc-bootstrap/libraries/template-haskell/dist- boot/build' '--lflag=-L/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/process-1.2.3.0' '--lflag=-L/home/hs01/ezyang /ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/pretty-1.1.2.0' '--lflag=-L/home/hs01/ezyang /ghc-bootstrap/libraries/hpc/dist-boot/build' '--lflag=-L/home/hs01/ezyang /ghc-bootstrap/libraries/hoopl/dist-boot/build' '-- lflag=-L/home/hs01/ezyang/ghc-bootstrap/libraries/ghc-boot/dist- boot/build' '--lflag=-L/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/directory-1.2.2.0' '--lflag=-L/home/hs01/ezyang /ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/unix-2.7.1.0' '--lflag=-L/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/time-1.5.0.1' '--lflag=-L/home/hs01/ezyang/ghc- validate/bindisttest/install dir/lib/ghc-7.11.20151022/filepath-1.4.0.0' ' --lflag=-L/home/hs01/ezyang/ghc-bootstrap/libraries/binary/dist- boot/build' '--lflag=-L/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/containers-0.5.6.2' '--lflag=-L/home/hs01/ezyang /ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/bytestring-0.10.6.0' '-- lflag=-L/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/deepseq-1.4.1.1' '--lflag=-L/home/hs01/ezyang /ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/array-0.5.1.0' '--lflag=-L/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/base-4.8.2.0' '--lflag=-L/home/hs01/ezyang/ghc- validate/bindisttest/install dir/lib/ghc-7.11.20151022/integer- gmp-1.0.0.0' '--lflag=-L/home/hs01/ezyang/ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/ghc-prim-0.4.0.0' '--lflag=-L/home/hs01/ezyang /ghc-validate/bindisttest/install dir/lib/ghc-7.11.20151022/rts' '-- lflag=-lrt' '--lflag=-lutil' '--lflag=-ldl' '--lflag=-lpthread' '-- lflag=-lgmp' '--lflag=-lm' '--lflag=-lrt' '--lflag=-ldl' '--lflag=-lelf' ' --lflag=-ldw' --cflag=-Icompiler/stage1/build/autogen --cflag=-include --cflag=compiler/stage1/build/autogen/cabal_macros.h compiler/utils/Fingerprint.hsc -o compiler/stage1/build/Fingerprint.hs }}} Notice that there is only a single space in the `include` path passed to hsc2hs. I didn't feel like tracking down where we didn't quote enough. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 20:53:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 20:53:48 -0000 Subject: [GHC] #11006: Warning: Glomming in Main Message-ID: <045.7166ee4256f525a9bdeeeecfa550ca07@haskell.org> #11006: Warning: Glomming in Main -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 Travis build bot is reporting a test failure with debugging on, relating to glomming: {{{ Actual stderr output differs from expected: --- /dev/null 2015-01-28 16:31:58.000000000 +0000 +++ ./lib/integer/integerConstantFolding.run.stderr.normalised 2015-10-22 20:31:03.287376925 +0000 @@ -0,0 +1,2 @@ +WARNING: file compiler/simplCore/OccurAnal.hs, line 66 + Glomming in Main: [s3k0 :->, s3kc :->, s3kq :->, s3kr :->] \ No newline at end of file *** unexpected failure for integerConstantFolding(normal) }}} Full log https://s3.amazonaws.com/archive.travis- ci.org/jobs/86899099/log.txt -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 21:05:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 21:05:05 -0000 Subject: [GHC] #11007: Type family injectivity annotations ignored in hs-boot files Message-ID: <047.26e4b74bfa5db1c5fbbc0697a9084694@haskell.org> #11007: Type family injectivity annotations ignored in hs-boot files -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's the test case: {{{ -- A.hs-boot {-# LANGUAGE TypeFamilies #-} module A where type family Id x = r | r -> x where .. }}} {{{ -- needed to avoid illegal self-import module B where import {-# SOURCE #-} A }}} {{{ {-# LANGUAGE TypeFamilies #-} module A where import B type family Id x = r | r -> x where Id a = a }}} I get {{{ A.hs-boot:6:1: error: Type constructor ?Id? has conflicting definitions in the module and its hs-boot file Main module: type family Id x = r :: * | r -> x where Id a = a Boot file: type family Id x :: * }}} Even when declaring an abstract closed type family, it should still be able to be injective. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 21:06:09 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 21:06:09 -0000 Subject: [GHC] #11007: Type family injectivity annotations ignored in hs-boot files In-Reply-To: <047.26e4b74bfa5db1c5fbbc0697a9084694@haskell.org> References: <047.26e4b74bfa5db1c5fbbc0697a9084694@haskell.org> Message-ID: <062.9d9e60505e52e0fb71ee8063bd24822f@haskell.org> #11007: Type family injectivity annotations ignored in hs-boot files -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * Attachment "T11007.tar.gz" added. test case -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 21:22:37 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 21:22:37 -0000 Subject: [GHC] #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" In-Reply-To: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> References: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> Message-ID: <060.f771d3f0f06360e4459b0b372a91eca0@haskell.org> #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by olsner): * cc: olsner (added) Comment: I started getting this error when running validate today (I last ran validate sometime before the doc changes). This is with sphinx 1.2.2 from Ubuntu's python3-sphinx package. If you retry once or twice with `./validate --no-clean`, that usually gets past it though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 21:33:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 21:33:45 -0000 Subject: [GHC] #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" In-Reply-To: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> References: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> Message-ID: <060.df661303107d976f104a38c197eff433@haskell.org> #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: closed => new * resolution: fixed => Comment: Yeah, I've seen it too. Reopening. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 22:04:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 22:04:54 -0000 Subject: [GHC] #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" In-Reply-To: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> References: <045.b7ff2fee2d349a84d2c8d45876ef033b@haskell.org> Message-ID: <060.1522f449ffa8087df37e4e11977217d0@haskell.org> #10950: Sphinx "RecursionError: maximum recursion depth exceeded while pickling an object" -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by olsner): Adding the `-E` option to sphinx ("don't use a saved environment, always read all files") seems to work around it for me, presumably because it disables the code that is trying to pickle stuff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 22:11:20 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 22:11:20 -0000 Subject: [GHC] #11008: GND with Type Families Message-ID: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> #11008: GND with Type Families -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the following code: {{{ {-# LANGUAGE TypeFamilies, FlexibleContexts, UndecidableInstances #-} class C r type family F r newtype Foo r = Foo r instance (C (F r), Eq r) => Eq (Foo r) newtype Bar r = Bar (Foo r) deriving (Eq) }}} GHC produces the error {{{ No instance for (C (F r)) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Eq (Bar r)) }}} If I enable `StandaloneDeriving`, I am able to derive the instance: `deriving instance (Eq (Foo r)) => Eq (Bar r)` [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/deriving.html #newtype-deriving The docs] indicate that this is exactly the instance that should be generated by GND for `newtype T v1..vn = MkT (t vk+1..vn) deriving (C t1..tj)`, where my code uses the following parameters: {{{ T = Bar v1 = r n = 1 MkT = Bar t = Foo r k= 1 C = Eq j = 0 }}} and all of the conditions enumerated in the docs seem to be met. Furthermore, `Bar` seems to fit squarely into the format of `data T1` in section 7.5.1 of the same documentation, which indicates it should not need `StandaloneDeriving`. It seems that the type family constraint on the `Eq` instance for `Foo` is causing the problem, but it's not clear why I'm forced to write a standalone instance that is identical to the one that should be generated by GND. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 22:32:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 22:32:05 -0000 Subject: [GHC] #9646: Simplifer non-determinism leading to 8 fold difference in run time performance In-Reply-To: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> References: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> Message-ID: <059.6f42dbae058ce9ecf3bddaf2dfa6c5b1@haskell.org> #9646: Simplifer non-determinism leading to 8 fold difference in run time performance -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Really close to having this pared down enough to add to the test suite. Since this issue was actually fixed before the 7.10.2 release its not a problem that the test doesn't get added to 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 22 22:41:04 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Oct 2015 22:41:04 -0000 Subject: [GHC] #10506: SourceNotes are not applied to all identifiers In-Reply-To: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> References: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> Message-ID: <064.24513327c762fec9e6ce6b473da3eaf1@haskell.org> #10506: SourceNotes are not applied to all identifiers -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 gridaphobe): GHC HEAD as of bbad4f6b5894c3deb417a056e0fd3fd75da7f593 (the latest commit I have built locally) still only produces a tick for the entire application expression (missing the `(+)` occurrence), so I suspect it's still an issue. It would be really nice to fix this in time for 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 23 00:13:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 00:13:35 -0000 Subject: [GHC] #11001: BlockedIndefinitelyOnMVar thrown with live reference in unrelated finalizer In-Reply-To: <046.2cc9f3eed9ffb6efbcf5550718daab5b@haskell.org> References: <046.2cc9f3eed9ffb6efbcf5550718daab5b@haskell.org> Message-ID: <061.d8336aeabdf2c0f02b9ab79721ace0bc@haskell.org> #11001: BlockedIndefinitelyOnMVar thrown with live reference in unrelated finalizer -------------------------------------+------------------------------------- Reporter: exFalso | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: | BlockedIndefinitelyOnMVar finalize Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | 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 Fri Oct 23 00:40:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 00:40:07 -0000 Subject: [GHC] #11009: Errors reading stdin on Windows Message-ID: <045.6536b0b9909b2bd209cff5be9e0bf17c@haskell.org> #11009: Errors reading stdin on Windows -------------------------------------+------------------------------------- Reporter: ncreep | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.2 libraries/base | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, I'm running GHC 7.10.2 on Windows 7 x64. Given this code that reads bytes of `stdin`: {{{#!hs import Foreign.C import Foreign import System.Posix.Internals import qualified GHC.IO.FD as FD readStdin bytes = allocaBytes bytes $ \p -> throwErrnoIfMinus1 "" $ c_safe_read (FD.fdFD FD.stdin) p (fromIntegral bytes) }}} Running {{{#!hs readStdin (32 * 1024) }}} Throws the following {{{ *** Exception: resource exhausted (Not enough space) }}} Taking less bytes, e.g. `readStdin (30 * 1024)`, runs as expected. This code is motivated by [[https://github.com/haskell/bytestring/issues/35|this]] issue in the `bytestring` library. This is essentially a minimization of the error case [[https://github.com/haskell/bytestring/issues/35#issuecomment-148954406|here]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 23 01:25:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 01:25:59 -0000 Subject: [GHC] #4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64# In-Reply-To: <045.5cc829a852152f43b89d9843483d1a41@haskell.org> References: <045.5cc829a852152f43b89d9843483d1a41@haskell.org> Message-ID: <060.adb736d7ef90ad6b6f305a9d81be73f8@haskell.org> #4092: Floating point manipulation : ulp and coerce IEEE-754 Double# into Word64# -------------------------------------+------------------------------------- Reporter: malosh | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 6.12.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 akio): * cc: tkn.akio@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 23 01:50:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 01:50:25 -0000 Subject: [GHC] #10896: BadSock triggers failing ASSERT In-Reply-To: <045.e2606f0aace406a963850215a356a8ed@haskell.org> References: <045.e2606f0aace406a963850215a356a8ed@haskell.org> Message-ID: <060.6bc3aa9ecc4639ab149610fc1af058be@haskell.org> #10896: BadSock triggers failing ASSERT -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_fail/BadSock Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1260 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Simon, I remember you suggesting a better approach here. But I'm afraid I didn't note it down nor implement it. Do you remember what it was? Was it to protect all calls to `checkValidType` from !TcTyClsDecls? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 23 02:47:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 02:47:34 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.8fa4cb8f43685a4b05dd7bb7a7815b75@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by erikd): The test `( cd testsuite && make TEST=ado001 stage=1 )` passes on arm64. Running the whole test suite like that and I get a number of failures due to the fact that its only the stage1 compiler (ie all ghci, TH and annoations tests), but I also get this one failing: {{{ make test stage=1 TEST="T5435_v_asm" }}} but that passes on x86_64. Sure enough, looking at `rts/Linker.c` there is no `aarch64_ HOST_ARCH` section. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 23 03:12:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 03:12:41 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.ec154d816d6c0a9e0200b12794dd12ff@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by erikd): Have a simple Make script that passes on x86_64/linux and fails on arm64/linux: {{{ #!/usr/bin/make -f GHC = inplace/bin/ghc-stage1 GHCFLAGS = -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output \ -no-user-package-db -rtsopts -fno-warn-tabs \ -fno-warn-missed-specialisations -optc-Dlinux_HOST_OS=1 -v0 TESTDIR = testsuite/tests/rts all : rm -f *.o $(GHC) $(GHCFLAGS) -c $(TESTDIR)/T5435_asm.c -o T5435_load_v_asm.o $(GHC) $(GHCFLAGS) $(TESTDIR)/T5435.hs -o T5435_v_asm ./T5435_v_asm v ./T5435_load_v_asm.o }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 23 04:48:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 04:48:43 -0000 Subject: [GHC] #11010: Untouchable type, pattern synonyms Message-ID: <051.ac3dbe8ba403159d004fffbd87da4f52@haskell.org> #11010: Untouchable type, pattern synonyms ------------------------------------+--------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------------+--------------------------------- GHC panicked while experimenting {{{#!hs {-# LANGUAGE PatternSynonyms, ExistentialQuantification, GADTSyntax #-} module Test where data Expr a where Fun :: String -> (a -> b) -> (Expr a -> Expr b) pattern IntFun :: () => (a ~ Int) => String -> (a -> b) -> (Expr a -> Expr b) pattern IntFun str f x = Fun str f x pattern Suc :: () => (a ~ Int) => Expr a -> Expr Int pattern Suc n <- IntFun _ _ n where Suc n = IntFun "suc" (+ 1) n }}} {{{ % ghc Test.hs [1 of 1] Compiling Test ( Test.hs, Test.o ) Test.hs:12:18: Couldn't match expected type ?Int? with actual type ?a1? ?a1? is untouchable inside the constraints (a ~ Int) bound by the type signature for Suc :: Expr a -> Expr Int at Test.hs:12:9-11ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for i386-unknown-linux): No skolem info: a1_anA[ssk] 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 Oct 23 04:49:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 04:49:48 -0000 Subject: [GHC] #11010: Untouchable type, pattern synonyms In-Reply-To: <051.ac3dbe8ba403159d004fffbd87da4f52@haskell.org> References: <051.ac3dbe8ba403159d004fffbd87da4f52@haskell.org> Message-ID: <066.888e99f883b2935744a471b411fa4e0b@haskell.org> #11010: Untouchable type, pattern synonyms ---------------------------------+------------------------------ Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Description changed by Iceland_jack: Old description: > GHC panicked while experimenting > > {{{#!hs > {-# LANGUAGE PatternSynonyms, ExistentialQuantification, GADTSyntax #-} > > module Test where > > data Expr a where > Fun :: String -> (a -> b) -> (Expr a -> Expr b) > > pattern IntFun :: () => (a ~ Int) => String -> (a -> b) -> (Expr a -> > Expr b) > pattern IntFun str f x = Fun str f x > > pattern Suc :: () => (a ~ Int) => Expr a -> Expr Int > pattern Suc n <- IntFun _ _ n where > Suc n = IntFun "suc" (+ 1) n > }}} > > {{{ > % ghc Test.hs > [1 of 1] Compiling Test ( Test.hs, Test.o ) > > Test.hs:12:18: > Couldn't match expected type ?Int? with actual type ?a1? > ?a1? is untouchable > inside the constraints (a ~ Int) > bound by the type signature for Suc :: Expr a -> Expr Int > at Test.hs:12:9-11ghc: panic! (the 'impossible' happened) > (GHC version 7.10.2 for i386-unknown-linux): > No skolem info: a1_anA[ssk] > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} New description: GHC panicked while experimenting {{{#!hs {-# LANGUAGE PatternSynonyms, ExistentialQuantification, GADTSyntax #-} module Test where data Expr a where Fun :: String -> (a -> b) -> (Expr a -> Expr b) pattern IntFun :: () => (a ~ Int) => String -> (a -> b) -> (Expr a -> Expr b) pattern IntFun str f x = Fun str f x pattern Suc :: () => (a ~ Int) => Expr a -> Expr Int pattern Suc n <- IntFun _ _ n where Suc n = IntFun "suc" (+ 1) n }}} {{{ % ghc Test.hs [1 of 1] Compiling Test ( Test.hs, Test.o ) Test.hs:12:18: Couldn't match expected type ?Int? with actual type ?a1? ?a1? is untouchable inside the constraints (a ~ Int) bound by the type signature for Suc :: Expr a -> Expr Int at Test.hs:12:9-11ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for i386-unknown-linux): No skolem info: a1_anA[ssk] 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 Oct 23 04:52:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 04:52:35 -0000 Subject: [GHC] #11010: Untouchable type, pattern synonyms In-Reply-To: <051.ac3dbe8ba403159d004fffbd87da4f52@haskell.org> References: <051.ac3dbe8ba403159d004fffbd87da4f52@haskell.org> Message-ID: <066.4cda1c62d9f14027e4f6c7574e56678c@haskell.org> #11010: Untouchable type, pattern synonyms ---------------------------------+------------------------------ Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Description changed by Iceland_jack: Old description: > GHC panicked while experimenting > > {{{#!hs > {-# LANGUAGE PatternSynonyms, ExistentialQuantification, GADTSyntax #-} > > module Test where > > data Expr a where > Fun :: String -> (a -> b) -> (Expr a -> Expr b) > > pattern IntFun :: () => (a ~ Int) => String -> (a -> b) -> (Expr a -> > Expr b) > pattern IntFun str f x = Fun str f x > > pattern Suc :: () => (a ~ Int) => Expr a -> Expr Int > pattern Suc n <- IntFun _ _ n where > Suc n = IntFun "suc" (+ 1) n > }}} > > {{{ > % ghc Test.hs > [1 of 1] Compiling Test ( Test.hs, Test.o ) > > Test.hs:12:18: > Couldn't match expected type ?Int? with actual type ?a1? > ?a1? is untouchable > inside the constraints (a ~ Int) > bound by the type signature for Suc :: Expr a -> Expr Int > at Test.hs:12:9-11ghc: panic! (the 'impossible' happened) > (GHC version 7.10.2 for i386-unknown-linux): > No skolem info: a1_anA[ssk] > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} New description: GHC panicked while experimenting {{{#!hs {-# LANGUAGE PatternSynonyms, ExistentialQuantification, GADTSyntax #-} module Test where data Expr a where Fun :: String -> (a -> b) -> (Expr a -> Expr b) pattern IntFun :: () => (a ~ Int) => String -> (a -> b) -> (Expr a -> Expr b) pattern IntFun str f x = Fun str f x -- Alternative syntax for pattern synonyms: -- pattern -- Suc :: () => (a ~ Int) => Expr a -> Expr Int -- Suc n <- IntFun _ _ n where -- Suc n = IntFun "suc" (+ 1) n pattern Suc :: () => (a ~ Int) => Expr a -> Expr Int pattern Suc n <- IntFun _ _ n where Suc n = IntFun "suc" (+ 1) n }}} {{{ % ghc Test.hs [1 of 1] Compiling Test ( Test.hs, Test.o ) Test.hs:12:18: Couldn't match expected type ?Int? with actual type ?a1? ?a1? is untouchable inside the constraints (a ~ Int) bound by the type signature for Suc :: Expr a -> Expr Int at Test.hs:12:9-11ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for i386-unknown-linux): No skolem info: a1_anA[ssk] 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 Oct 23 05:50:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 05:50:43 -0000 Subject: [GHC] #10996: family is treated as keyword in types even without TypeFamilies enabled In-Reply-To: <045.27f49ff532e9a720de796a9ae0ad68ae@haskell.org> References: <045.27f49ff532e9a720de796a9ae0ad68ae@haskell.org> Message-ID: <060.6fca353a3634572321902a9afd30f283@haskell.org> #10996: family is treated as keyword in types even without TypeFamilies enabled -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: type Test valid program | family = family Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by oerjan): I note this quote in [https://raw.githubusercontent.com/ghc/ghc/master/compiler/parser/Lexer.x lexer.x]: > One might think that we wish to treat 'family' and 'role' as regular old > varids whenever -XTypeFamilies and -XRoleAnnotations are off, respectively. > But, there is no need to do so. These pseudo-keywords are not stolen syntax: > they are only used after the keyword 'type' at the top-level, where varids are > not allowed. Furthermore, checks further downstream (TcTyClsDecls) ensure that > type families and role annotations are never declared without their extensions > on. In fact, by unconditionally lexing these pseudo-keywords as special, we > can get better error messages. > > Also, note that these are included in the `varid` production in the parser -- > a key detail to make all this work. So clearly it was ''intended'' that they not be stolen, but something got messed up, perhaps when declaring types with `TypeOperators` were allowed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 23 05:55:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 05:55:46 -0000 Subject: [GHC] #10954: Add class/context information to typed hole relevant bindings In-Reply-To: <045.32f5d1e1940c448cdbb57da9612bf97b@haskell.org> References: <045.32f5d1e1940c448cdbb57da9612bf97b@haskell.org> Message-ID: <060.355da31db21d69818988f483ba23e46a@haskell.org> #10954: Add class/context information to typed hole relevant bindings -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9479, #9091 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => duplicate * related: #9479 => #9479, #9091 Comment: Duplicate of #9091 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 23 06:52:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 06:52:10 -0000 Subject: [GHC] #9091: print and/or apply constraints when showing info for typed holes In-Reply-To: <047.d95c0766523b082befd3b58cd013d678@haskell.org> References: <047.d95c0766523b082befd3b58cd013d678@haskell.org> Message-ID: <062.f29d771eaa29586bb6990a95c2e3b62c@haskell.org> #9091: print and/or apply constraints when showing info for typed holes -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.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 chak): I agree with Andres that ?in the presence of local constraints? the value of holes messages would be significantly higher with constraint information included. As for the verbosity, the terms "given constraints" and "wanted constraints" are probably not immediately clear for people who haven't read one of the relevant papers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 23 07:29:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 07:29:08 -0000 Subject: [GHC] #10896: BadSock triggers failing ASSERT In-Reply-To: <045.e2606f0aace406a963850215a356a8ed@haskell.org> References: <045.e2606f0aace406a963850215a356a8ed@haskell.org> Message-ID: <060.e1e6bca3ba55f30e6e34f7f6d83a1b7b@haskell.org> #10896: BadSock triggers failing ASSERT -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_fail/BadSock Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1260 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ug. This is all paged out, so I can't remember. I think I have something in my tree... The current situation it not terrible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 23 08:19:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 08:19:46 -0000 Subject: [GHC] #11010: Untouchable type, pattern synonyms In-Reply-To: <051.ac3dbe8ba403159d004fffbd87da4f52@haskell.org> References: <051.ac3dbe8ba403159d004fffbd87da4f52@haskell.org> Message-ID: <066.017978700b0aeab0fb75a3fb746e5c0f@haskell.org> #11010: Untouchable type, pattern synonyms ---------------------------------+------------------------------ Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Changes (by mpickering): * cc: mpickering (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 23 08:23:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 08:23:05 -0000 Subject: [GHC] #10997: Pattern synonym causes Iface error. In-Reply-To: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> References: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> Message-ID: <064.d8e6610b3a97f423ab0d96bbd72300d2@haskell.org> #10997: Pattern synonym causes Iface error. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10997 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 23 14:22:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 14:22:35 -0000 Subject: [GHC] #11008: Difficulties around inferring exotic contexts (was: GND with Type Families) In-Reply-To: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> References: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> Message-ID: <062.1755bc7565ff982b6cc8aff97583c5fa@haskell.org> #11008: Difficulties around inferring exotic contexts -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This is by design. GHC refuses to infer so-called exotic contexts, believing that sufficiently exotic contexts should be written by the user. This behavior is independent of whether GND or other `deriving` features are used. Here is an extreme example: {{{ data X a b = MkX (a -> b) deriving Eq }}} This fails, complaining about a missing `Eq (a -> b)` instance. (My choice of `data` vs. `newtype` is utterly irrelevant here.) But I can write this: {{{ deriving instance Eq (a -> b) => Eq (X a b) }}} Should GHC infer the context automatically here? I think not -- it masks a deeper problem. Now, returning to the original post: should GHC infer that context? It looks just like the example I just gave, where the context requires an `Eq` constraint on some other type constructor. It all boils down to yet another knob we can turn in the internals of GHC. It's a very easy knob to turn, with no interactions throughout the code. See the relevant function [https://github.com/ghc/ghc/blob/8f5ad1a009eddd05447ff8057792b4d03983cd35/compiler/typecheck/TcValidity.hs#L949 here], with a Note directly above. If you can suggest a better setting for the knob, go right ahead. :) Regardless, we should document this in the manual somewhere, as it is all user-facing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 23 15:11:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 15:11:12 -0000 Subject: [GHC] #7316: GHC segfaults on ARM In-Reply-To: <044.80d09029baede03deac2ad7b7fbe42af@haskell.org> References: <044.80d09029baede03deac2ad7b7fbe42af@haskell.org> Message-ID: <059.6e9783fc07293ad849c35d5c79f6cbc0@haskell.org> #7316: GHC segfaults on ARM -------------------------------------+------------------------------- Reporter: laney | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: 7623 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: laney, as of 7.10.3 ARM support should be reasonable stable (with the exception of distributions using Thumb binaries) as #10375 is resolved. Given that we don't really know what happened in this particular bug I'm going to close this. Feel free to open another ticket if you are still having trouble with 7.10.3 or later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 23 16:04:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 16:04:26 -0000 Subject: [GHC] #10426: matchGroupArity panic with PatternSynonyms In-Reply-To: <051.7a688bba15de9645a47ca046eb2525fe@haskell.org> References: <051.7a688bba15de9645a47ca046eb2525fe@haskell.org> Message-ID: <066.70f77ebfeb3e99a14ff193e92524949c@haskell.org> #10426: matchGroupArity panic with PatternSynonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fdb08e2abccf1e02dc2ef91531aebe062d8af82d/ghc" fdb08e2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fdb08e2abccf1e02dc2ef91531aebe062d8af82d" Add testcase for #10426 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 23 16:04:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 16:04:26 -0000 Subject: [GHC] #10979: Phab linter trips on ReStructuredText formatting In-Reply-To: <048.cf2d4e0a4200f704b93b86b6983cd451@haskell.org> References: <048.cf2d4e0a4200f704b93b86b6983cd451@haskell.org> Message-ID: <063.bd1f89d745307b4dc1d8d956094fc06e@haskell.org> #10979: Phab linter trips on ReStructuredText formatting -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.11 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 Ben Gamari ): In [changeset:"0afba67f703ab0ba8cd041167144169d67e14501/ghc" 0afba67/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0afba67f703ab0ba8cd041167144169d67e14501" arclint: ReST doesn't need ArcanistMergeConflictLinter The section heading syntax trips up this linter. Fixes #10979. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 23 16:04:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 16:04:26 -0000 Subject: [GHC] #10736: threadWaitRead/registerFd unusable In-Reply-To: <044.a96ce04f26395251bc71867625bc2939@haskell.org> References: <044.a96ce04f26395251bc71867625bc2939@haskell.org> Message-ID: <059.bb636caaf9a162924f7dc9311a19571e@haskell.org> #10736: threadWaitRead/registerFd unusable -------------------------------------+------------------------------------- Reporter: mboes | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.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): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fd63ea5686fe5b856c3ebdc5f28bf7a2547bd96f/ghc" fd63ea5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fd63ea5686fe5b856c3ebdc5f28bf7a2547bd96f" base: Note platform dependence of registerFd Just a documentation change. Fixes #10736. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 23 16:05:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 16:05:08 -0000 Subject: [GHC] #10979: Phab linter trips on ReStructuredText formatting In-Reply-To: <048.cf2d4e0a4200f704b93b86b6983cd451@haskell.org> References: <048.cf2d4e0a4200f704b93b86b6983cd451@haskell.org> Message-ID: <063.85f26f43afc60aa92b2abda1cc57ca0a@haskell.org> #10979: Phab linter trips on ReStructuredText formatting -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: 7.11 Resolution: fixed | 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 bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 23 16:24:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 16:24:41 -0000 Subject: [GHC] #11008: Difficulties around inferring exotic contexts In-Reply-To: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> References: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> Message-ID: <062.af325300707ed905f88255f76e0befbd@haskell.org> #11008: Difficulties around inferring exotic contexts -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): With the deriving clause, which instance does GHC try to create? 1. instance (Eq (Foo r)) => Eq (Bar r) 2. instance (C (F r), Eq r) => Eq (Bar r) If option 1, GHC has no business inspecting the constraints on the `Foo r` instance. If option 2, why? Is it due to [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/deriving.html #newtype-deriving slower instances]? In either case, since I *have* a matching `Eq` instance for `Foo`, GHC should assume that I knew what I was doing when I wrote it, and just use it. This doesn't change the behavior when no matching instance is found, like in your example. Whatever the result, the docs definitely need to be clearer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 23 18:40:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 18:40:59 -0000 Subject: [GHC] #11008: Difficulties around inferring exotic contexts In-Reply-To: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> References: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> Message-ID: <062.7c75165c5693bd9daea6e19a09d09937@haskell.org> #11008: Difficulties around inferring exotic contexts -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:2 crockeea]: > With the deriving clause, which instance does GHC try to create? > > 1. `instance (Eq (Foo r)) => Eq (Bar r)` > 2. `instance (C (F r), Eq r) => Eq (Bar r)` > Option 1. But it then tries to simplify the constraint, finding the minimal set of constraints that imply `Eq (Foo r)`. Here, minimal does not mean smallest, but instead minimal in a logical sense -- as in, the minimum set of assumptions that proves the desired constraint. So, option 1 very quickly becomes option 2. Note that if we didn't try to simplify, then you'd end up with constraints like `Eq (Maybe a)` a lot, and these would be rejected. > In either case, since I *have* a matching `Eq` instance for `Foo`, GHC should assume that I knew what I was doing when I wrote it, and just use it. This doesn't change the behavior when no matching instance is found, like in your example. But you have no matching instance for `C (F r)`. So I'm not sure how GHC should recognize the difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 23 19:03:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Oct 2015 19:03:08 -0000 Subject: [GHC] #11008: Difficulties around inferring exotic contexts In-Reply-To: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> References: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> Message-ID: <062.9381e98ff635db6919c3cee67547933e@haskell.org> #11008: Difficulties around inferring exotic contexts -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): Without knowing anything about the internals of GHC, it seems there are two ways to simplify instance contexts: either we "simplify and reject" if they are "exotic" (in the case of GND instances), or just "simplify and typecheck" (in the case of hand-written instances of any variety). So if an instance head matches (Eq (Foo r)), trigger the "simplify and typecheck" rather than "simplify and reject exotic constraints" behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 24 00:14:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Oct 2015 00:14:52 -0000 Subject: [GHC] #11011: Type-indexed TypeReps, Static Pointers and Distributed Closures Message-ID: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> #11011: Type-indexed TypeReps, Static Pointers and Distributed Closures -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There is a mock-up of a new API for type indexed type representations, basic Dynamic functionality, static pointers and distributed closures (https://github.com/brprice/typeableT), based on https://ghc.haskell.org/trac/ghc/wiki/TypeableT. We would like to invite comments and discussion from the community using this ticket as a more permenant home that email. One particular point that would benefit from more eyes is the polymorphic static pointers support. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 24 00:18:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Oct 2015 00:18:38 -0000 Subject: [GHC] #11011: Type-indexed TypeReps, Static Pointers and Distributed Closures In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.308496ecf54b8330c583ef6f8b247c56@haskell.org> #11011: Type-indexed TypeReps, Static Pointers and Distributed Closures -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bjmprice): To record a couple of my thoughts: - When RAE's nokinds branch merges, we can have kind-hetrogenous type equalitys, which would find good use in comparing `TypeRep`s - When Injective Type Families is implemented, it ''may'' be useful for reducing passing `PolyTag`s around (currently they are not used in the code, but needed, else GHC complains about not necessarily injective type families) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 24 01:06:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Oct 2015 01:06:20 -0000 Subject: [GHC] #11011: Type-indexed TypeReps, Static Pointers and Distributed Closures In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.bdb60849c8e29b6e1cda44b7a3cc0c0e@haskell.org> #11011: Type-indexed TypeReps, Static Pointers and Distributed Closures -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rodlogic): * cc: rodlogic (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 24 04:49:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Oct 2015 04:49:38 -0000 Subject: [GHC] #11012: Support for unicode primes on identifiers. Message-ID: <048.363b1ce44ead0d11a6975760504f792b@haskell.org> #11012: Support for unicode primes on identifiers. -------------------------------------+------------------------------------- Reporter: ghartshaw | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (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: -------------------------------------+------------------------------------- GHC should allow the (single/double/triple/quadruple) prime characters in Unicode to be allowed in identifiers. This would make them consistent with the ASCII apostrophe, which is usually used in place of a single prime. The current workaround for primes (using one or more apostrophes) is unwieldy for higher primes (e.g. {{{a'''}}} and {{{a''''}}}). All of the following identifiers should be valid. {{{ a' // U+0027 APOSTROPHE a? // U+2032 PRIME a? // U+2033 DOUBLE PRIME a? // U+2034 TRIPLE PRIME a? // U+2057 QUADRUPLE PRIME }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 24 07:26:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Oct 2015 07:26:55 -0000 Subject: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space In-Reply-To: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> References: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> Message-ID: <064.639838da0aec87f2c8a47f4ceedd5380@haskell.org> #5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by basvandijk): Another user of aeson also [https://github.com/bos/aeson/issues/309 ran into this] (or something which looks like this). However, instead of a big sum type he has a big product type. The other interesting thing is that the issue only seems to appear with aeson-0.10.0.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 24 07:54:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Oct 2015 07:54:01 -0000 Subject: [GHC] #11013: GHC sometimes forgets to test for hs-boot consistency Message-ID: <045.728964e4952015da2de47ca14cc36513@haskell.org> #11013: GHC sometimes forgets to test for hs-boot consistency -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- Steps to reproduce: create your classic circular dependency: {{{ -- A.hs-boot module A where }}} {{{ -- B.hs module B where import {-# SOURCE #-} A }}} {{{ -- A.hs module A where import B }}} Now run this: {{{ ghc -c A.hs-boot ghc -c B.hs ghc -c A.hs echo "module A where x :: Bool" > A.hs-boot ghc -c A.hs-boot ghc -c B.hs ghc -c A.hs }}} Expected result: A.hs recompiles and gives us an error that we don't implement enough. Actual result: compilation IS NOT required. (Obviously, if you force recomp you do get an error now.) I think the problem is `checkOldIface` doesn't also look for an hi-boot file, and even if it did, we don't record the hashes from the hi-boot file in the hi file proper (they're not an immediate dependency). Related #10333 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 24 07:54:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Oct 2015 07:54:10 -0000 Subject: [GHC] #10333: hs-boot modification doesn't induce recompilation In-Reply-To: <045.b2a6545e2380bf06a403c64b9db0df81@haskell.org> References: <045.b2a6545e2380bf06a403c64b9db0df81@haskell.org> Message-ID: <060.e92e26d7059aa2b584120ed86f876fb1@haskell.org> #10333: hs-boot modification doesn't induce recompilation -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 ezyang): Related: #11013 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 24 08:38:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Oct 2015 08:38:09 -0000 Subject: [GHC] #10196: Regression regarding Unicode subscript characters in identifiers In-Reply-To: <045.6ee5899f7586f6a7c7c268a3fffc6086@haskell.org> References: <045.6ee5899f7586f6a7c7c268a3fffc6086@haskell.org> Message-ID: <060.0760ed27804b9738ae926ce771400607@haskell.org> #10196: Regression regarding Unicode subscript characters in identifiers -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #5108 | Differential Rev(s): Phab:D969 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: closed => new * resolution: fixed => Comment: Sorry, to bring this up late, but the report specifies ?Haskell compilers are expected to make use of new versions of Unicode as they are made available.? So if we deviate from that, we should make sure that * the user?s guide explicitly lists all deviations from the report [in this section](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide /bugs-and-infelicities.html#infelicities-lexical), and * that the Haskell prime committee is going to be aware of these (sensible) deviations, so that they can become official. This is also important for, e.g. #11012. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 24 08:41:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Oct 2015 08:41:49 -0000 Subject: [GHC] #11012: Support for unicode primes on identifiers. In-Reply-To: <048.363b1ce44ead0d11a6975760504f792b@haskell.org> References: <048.363b1ce44ead0d11a6975760504f792b@haskell.org> Message-ID: <063.d09856904df3c8810f035ee2ce4699ba@haskell.org> #11012: Support for unicode primes on identifiers. -------------------------------------+------------------------------------- Reporter: ghartshaw | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (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 nomeata): Hi ghartshaw, I?m very sympathetic towards making good use of Unicode. On the other hand, it is also important to follow the language specification, and that is pretty clear about what Unicode symbols are allowed as part of identifiers, etc. Currently, these primes are ?Other Punctuation? according to the Unicode standard, any maybe someone uses them as such, e.g. as an operator. Would you mind precisely stating what modification you?d like to make to https://www.haskell.org/report/mono/2010#x7-160002.2 This is a bit related to #10196, where we deviated from the report to allow subscripted symbols, so there is precedent. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 24 09:54:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Oct 2015 09:54:58 -0000 Subject: [GHC] #10426: matchGroupArity panic with PatternSynonyms In-Reply-To: <051.7a688bba15de9645a47ca046eb2525fe@haskell.org> References: <051.7a688bba15de9645a47ca046eb2525fe@haskell.org> Message-ID: <066.94280cedee9f00a106de23fd578d5cab@haskell.org> #10426: matchGroupArity panic with PatternSynonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10426 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => T10426 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 24 19:11:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Oct 2015 19:11:20 -0000 Subject: [GHC] #7169: Warning for incomplete record field label used as function In-Reply-To: <047.31629c8fe32b813e38c132e8d4305995@haskell.org> References: <047.31629c8fe32b813e38c132e8d4305995@haskell.org> Message-ID: <062.70be0c0a075a89649177ae843c4dbe72@haskell.org> #7169: Warning for incomplete record field label used as function -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Warnings, | 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 mpickering): * keywords: Warnings => Warnings, newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 24 20:04:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Oct 2015 20:04:30 -0000 Subject: [GHC] #11014: re-order GHC type errors for clarity Message-ID: <047.63b2ee64fbc0e8cf4ea8e84a14f0ce30@haskell.org> #11014: re-order GHC type errors for clarity -------------------------------------+------------------------------------- Reporter: elaforge | Owner: elaforge Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- Here's a typical simple type error from GHC: {{{#!hs Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ?Text? with ?(a1, Syllable)? Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) In the second argument of ?mapMaybe?, namely ?all_bols? In the second argument of ?($)?, namely ?mapMaybe (match_bols syllables) all_bols? }}} The order of sections is "couldn't match", "expected actual", "relevant bindings", "context" (in the second argument etc.). I think it would be easier to read as "couldn't match", "expected actual", "context", "bindings", and with a * to mark each section: {{{#!hs Derive/Call/India/Pakhawaj.hs:142:62: * Couldn't match type ?Text? with ?(a1, Syllable)? Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] * In the second argument of ?mapMaybe?, namely ?all_bols? In the second argument of ?($)?, namely ?mapMaybe (match_bols syllables) all_bols? * Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) }}} I'm sure there are plenty of other sections that don't show up in this simple example, in any case they should go from most to least critical and be marked off with a *. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 24 20:21:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Oct 2015 20:21:11 -0000 Subject: [GHC] #10462: GHCi doesn't work Any and missing RealWorld foreign prim imports In-Reply-To: <045.272515eb6529b0f69e6fb29bb854188b@haskell.org> References: <045.272515eb6529b0f69e6fb29bb854188b@haskell.org> Message-ID: <060.b1ec409d2f374664b99f55ea54ad4e47@haskell.org> #10462: GHCi doesn't work Any and missing RealWorld foreign prim imports -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * cc: hsyl20 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 25 04:54:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Oct 2015 04:54:07 -0000 Subject: [GHC] #10848: GHC/GHCi should optionally print errors in reversed order In-Reply-To: <043.346863bae2dced560ac8325c22b2fccb@haskell.org> References: <043.346863bae2dced560ac8325c22b2fccb@haskell.org> Message-ID: <058.c0d7216763f81e2ab20e48b6dbc6fade@haskell.org> #10848: GHC/GHCi should optionally print errors in reversed order -------------------------------------+------------------------------------- Reporter: osa1 | Owner: siddhanathan Type: feature request | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 7.11 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:D1367 Wiki Page: | -------------------------------------+------------------------------------- Changes (by siddhanathan): * differential: => Phab:D1367 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 25 12:15:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Oct 2015 12:15:19 -0000 Subject: [GHC] #10917: Provide a utility to check API Annotations In-Reply-To: <044.180158552b685611f17d6b8a8773714f@haskell.org> References: <044.180158552b685611f17d6b8a8773714f@haskell.org> Message-ID: <059.3230d13d8e024a5ea7867b20256aff30@haskell.org> #10917: Provide a utility to check API Annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1368 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D1368 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 25 12:49:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Oct 2015 12:49:54 -0000 Subject: [GHC] #10917: Provide a utility to check API Annotations In-Reply-To: <044.180158552b685611f17d6b8a8773714f@haskell.org> References: <044.180158552b685611f17d6b8a8773714f@haskell.org> Message-ID: <059.551af76700d4202f7be1afb9ae9438e9@haskell.org> #10917: Provide a utility to check API Annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1368 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 25 13:31:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Oct 2015 13:31:13 -0000 Subject: [GHC] #10061: Remove fun_infix from Funbind, as it is now in Match In-Reply-To: <044.5c8cbdfae3d19825dd1ca995401c55be@haskell.org> References: <044.5c8cbdfae3d19825dd1ca995401c55be@haskell.org> Message-ID: <059.1115601a8fabf39781496151566d3e4b@haskell.org> #10061: Remove fun_infix from Funbind, as it is now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9988 | Differential Rev(s): Phab:D1285 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * owner: alanz => * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 25 13:31:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Oct 2015 13:31:29 -0000 Subject: [GHC] #10061: Remove fun_infix from Funbind, as it is now in Match In-Reply-To: <044.5c8cbdfae3d19825dd1ca995401c55be@haskell.org> References: <044.5c8cbdfae3d19825dd1ca995401c55be@haskell.org> Message-ID: <059.7dfa5a648f8a5e435a308f337f7eab2b@haskell.org> #10061: Remove fun_infix from Funbind, as it is now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9988 | Differential Rev(s): Phab:D1285 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * owner: => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 25 14:04:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Oct 2015 14:04:23 -0000 Subject: [GHC] #11015: Add note describing unit ids, unit keys, package ids, and package keys, Message-ID: <046.ad3e9e67c90d3d94ed19c8b0a6b3f499@haskell.org> #11015: Add note describing unit ids, unit keys, package ids, and package keys, -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It would be great if there were a nice comprehensive Note (perhaps in `Module.hs`) describing the various identifiers which we have for modules, packages, units, etc. These might include, * `Package` * `PkgName` * `PkgKey` * `PkgId` * `UnitId` * `UnitKey` * Component? After writing this I found [[Commentary/Packages/Concepts]] but it would be great if this information found its way into a nice, central Note. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 25 15:09:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Oct 2015 15:09:15 -0000 Subject: [GHC] #10289: compiling huge HashSet hogs memory In-Reply-To: <044.7a75381e3cbd52797d1fc50b07f81ee0@haskell.org> References: <044.7a75381e3cbd52797d1fc50b07f81ee0@haskell.org> Message-ID: <059.7d02bf7c087145e03ad55299a407a057@haskell.org> #10289: compiling huge HashSet hogs memory -------------------------------------+------------------------------------- Reporter: zudov | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by zudov): bgamari, great I've just tested it on my local machine with latest text and unordered-containers and the problem is gone. Additionally, here is a travis build report https://travis- ci.org/zudov/html5-entity/builds/87314690 It still runs out of memory on ghc-7.10.1, but on ghc-7.10.2 everything is good. (compare with the previous build which used older text https://travis- ci.org/zudov/html5-entity/builds/69424551) Thanks a lot. I think we can close this issue now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 25 15:10:59 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Oct 2015 15:10:59 -0000 Subject: [GHC] #10289: compiling huge HashSet hogs memory In-Reply-To: <044.7a75381e3cbd52797d1fc50b07f81ee0@haskell.org> References: <044.7a75381e3cbd52797d1fc50b07f81ee0@haskell.org> Message-ID: <059.492f3680a6dfdcc796439d8366871438@haskell.org> #10289: compiling huge HashSet hogs memory -------------------------------------+------------------------------------- Reporter: zudov | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by zudov): * status: infoneeded => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 25 17:28:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Oct 2015 17:28:39 -0000 Subject: [GHC] #11012: Support for unicode primes on identifiers. In-Reply-To: <048.363b1ce44ead0d11a6975760504f792b@haskell.org> References: <048.363b1ce44ead0d11a6975760504f792b@haskell.org> Message-ID: <063.3d48078da6fcfaefe1640f254cf5b6d1@haskell.org> #11012: Support for unicode primes on identifiers. -------------------------------------+------------------------------------- Reporter: ghartshaw | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (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 ghartshaw): I would like the characters U+2032, U+2033, U+2034, and U+2057 to be excluded from uniSymbol in the rule for symbol, added to the rule for graphic, and added to the rules for varid and conid. These rules currently are {{{ graphic ? small | large | symbol | digit | special | " | ' symbol ? ascSymbol | uniSymbol varid ? (small {small | large | digit | '}) conid ? large {small | large | digit | '} }}} With this proposal they would become {{{ prime ? ' | ? | ? | ? | ? // U+0027,U+2032,U+2033,U+2034,U+2057 graphic ? small | large | symbol | digit | special | " | prime symbol ? ascSymbol | uniSymbol varid ? (small {small | large | digit | prime}) conid ? large {small | large | digit | prime} }}} These rules treat the Unicode primes exactly the same as an apostrophe when found in identifiers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 25 18:31:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Oct 2015 18:31:14 -0000 Subject: [GHC] #11015: Add note describing unit ids, unit keys, package ids, and package keys, In-Reply-To: <046.ad3e9e67c90d3d94ed19c8b0a6b3f499@haskell.org> References: <046.ad3e9e67c90d3d94ed19c8b0a6b3f499@haskell.org> Message-ID: <061.eafaae886e4dc6e9ae169f5270ce4f9e@haskell.org> #11015: Add note describing unit ids, unit keys, package ids, and package keys, -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): I'm all for it. Where would you like this note to live? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 25 19:55:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Oct 2015 19:55:56 -0000 Subject: [GHC] #10917: Provide a utility to check API Annotations In-Reply-To: <044.180158552b685611f17d6b8a8773714f@haskell.org> References: <044.180158552b685611f17d6b8a8773714f@haskell.org> Message-ID: <059.58c5811b9689b6b1bb6808b5c9e1c29e@haskell.org> #10917: Provide a utility to check API Annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1368 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"43751b2436f370d956d8021b3cdd3eb77801470b/ghc" 43751b2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="43751b2436f370d956d8021b3cdd3eb77801470b" Provide a utility to check API Annotations It is difficult for GHC developers to know if they have broken the API Annotations. This patch provides a utility that can be used as a test to show up errors in the API Annotations. It is based on the current tests for ghc-api/annotations which can parse a file using the just-built GHC API, and check that no annotations are disconnected from the ParsedSource in the output. In addition, it should be able to dump the annotations to a file, so a new feature developer can check that all changes to the parser do provide annotations. Trac ticket: #10917 Test Plan: ./validate Reviewers: hvr, thomie, austin, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1368 GHC Trac Issues: #10917 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 25 20:20:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Oct 2015 20:20:00 -0000 Subject: [GHC] #11014: re-order GHC type errors for clarity In-Reply-To: <047.63b2ee64fbc0e8cf4ea8e84a14f0ce30@haskell.org> References: <047.63b2ee64fbc0e8cf4ea8e84a14f0ce30@haskell.org> Message-ID: <062.8858e9003b318fd83ed7b56be7d7c1ea@haskell.org> #11014: re-order GHC type errors for clarity -------------------------------------+------------------------------------- Reporter: elaforge | Owner: elaforge Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Just checking: Is this something you?d like to work on yourself, and turn into a patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 25 21:20:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Oct 2015 21:20:16 -0000 Subject: [GHC] #10250: API Annotations : add Locations in hsSyn were layout occurs In-Reply-To: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> References: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> Message-ID: <059.776c1aa298e3d497da8268dd293bed03@haskell.org> #10250: API Annotations : add Locations in hsSyn were layout occurs -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | Phab:D815,Phab:D1370 -------------------------------------+------------------------------------- Changes (by alanz): * differential: Phab:D815 => Phab:D815,Phab:D1370 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 25 21:58:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Oct 2015 21:58:24 -0000 Subject: [GHC] #10250: API Annotations : add Locations in hsSyn were layout occurs In-Reply-To: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> References: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> Message-ID: <059.003883668b4d23cfebdc7d105a134593@haskell.org> #10250: API Annotations : add Locations in hsSyn were layout occurs -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | Phab:D815,Phab:D1370 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 25 23:56:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Oct 2015 23:56:40 -0000 Subject: [GHC] #11016: PartialTypeSignatures trigger bogus "unbound implicit parameter" error Message-ID: <049.a519660a2de244dbc0d846e81c340bc1@haskell.org> #11016: PartialTypeSignatures trigger bogus "unbound implicit parameter" error -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #10846 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC seems to forget about in-scope implicit parameters when there's a hole in the type signature. Given {{{#!haskell {-# LANGUAGE ImplicitParams, PartialTypeSignatures #-} module Bad where f1 :: (?loc :: Int, _) => Int f1 = ?loc f2 :: (?loc :: Int) => _ f2 = ?loc }}} GHC incorrectly reports the following errors. {{{ % ghc -fforce-recomp Bad.hs [1 of 1] Compiling Bad ( Bad.hs, Bad.o ) Bad.hs:8:6: Unbound implicit parameter (?loc::Int) arising from a use of implicit parameter ??loc? In the expression: ?loc In an equation for ?f1?: f1 = ?loc Bad.hs:11:1: Occurs check: cannot construct the infinite type: _ ~ (?loc::Int) => _ When checking that ?f2? has the specified type f2 :: (?loc::Int) => _ Probable cause: the inferred type is ambiguous Bad.hs:11:6: Unbound implicit parameter (?loc::_) arising from a use of implicit parameter ??loc? Relevant bindings include f2 :: _ (bound at Bad.hs:11:1) In the expression: ?loc In an equation for ?f2?: f2 = ?loc }}} `?loc` is very clearly bound by both `f1` and `f2`'s signature. `f2` additionally reports what looks to me to be a bogus occurs-check error; we know from the theta that `?loc :: Int` so the hole should be solved for `Int`. I suspect this is all related to the fact that PartialTypeSignatures triggers `tcPolyInfer` instead of `tcPolyCheck`. I think this is the same underlying bug as #10846. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 06:32:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 06:32:04 -0000 Subject: [GHC] #10845: Incorrect behavior when let binding implicit CallStack object In-Reply-To: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> References: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> Message-ID: <068.8e8eb8b0d3a36b0c170ab6f16debb37a@haskell.org> #10845: Incorrect behavior when let binding implicit CallStack object -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): Alas, we can't simply remove the no-given solver for CallStacks, what about {{{ f :: CallStack f = ?callStack }}} Here we're given a type signature, so we won't pass through `simplifyInfer`. In general, I'm pretty sure we need the no-given solver for CallStacks at levels 1 and 3. Unfortunately that doesn't cut it either, consider our friend `fail` {{{ class Monad m where fail :: String -> m a fail s = error s }}} `fail` gives rise to an implication {{{ Implic { TcLevel = 3 Skolems = (m_anr[ssk] :: * -> *) No-eqs = False Status = Unsolved Given = $dMonad_aon :: T10845.Monad m_anr[ssk] Wanted = WC {wc_impl = Implic { TcLevel = 5 Skolems = a_aop[sk] No-eqs = False Status = Unsolved Given = Wanted = WC {wc_simple = [W] $dIP_aot :: ?callStack::CallStack (CNonCanonical)} Binds = EvBindsVar the type signature for: T10845.fail :: String -> m_anr[ssk] a_aop[sk] }} Binds = EvBindsVar the class declaration for ?T10845.Monad? } }}} which has the CallStack wanted stuck back at level 5! Ugh.. Perhaps what we really want is to move the no-given solver to `simplifyTop`, not `simplifyInfer`. I see that `simplifyTop` handles type- class defaulting, which feels similar in spirit to the no-given solver (ie we're defaulting the insoluble CallStacks to contain just the current source location). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 08:40:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 08:40:12 -0000 Subject: [GHC] #10370: Compile time regression in OpenGLRaw In-Reply-To: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> References: <046.b5611952e9220b8c84d8acb198aa41d9@haskell.org> Message-ID: <061.b83e54233e2dd1ebd6046db94aa7b06c@haskell.org> #10370: Compile time regression in OpenGLRaw -------------------------------------+------------------------------------- Reporter: michalt | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c2fab84239299176a8e72aa26ae894019d677bd9/ghc" c2fab842/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c2fab84239299176a8e72aa26ae894019d677bd9" Add testcase for #10370 Test Plan: Validate. Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1352 GHC Trac Issues: #10370 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 08:41:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 08:41:33 -0000 Subject: [GHC] #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> References: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> Message-ID: <065.1379e8e10e57a1b648209b553d43275e@haskell.org> #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #10682 | Differential Rev(s): Phab:D1354 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1354 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 09:00:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 09:00:07 -0000 Subject: [GHC] #10250: API Annotations : add Locations in hsSyn where layout occurs (was: API Annotations : add Locations in hsSyn were layout occurs) In-Reply-To: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> References: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> Message-ID: <059.646e85aa51cdc6249143a40c1f1e3dc3@haskell.org> #10250: API Annotations : add Locations in hsSyn where layout occurs -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | Phab:D815,Phab:D1370 -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 09:31:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 09:31:06 -0000 Subject: [GHC] #11017: ApiAnnotations: BooleanFormula is not properly Located Message-ID: <044.8a6c3bf330a4eb35f37df8711068c35c@haskell.org> #11017: ApiAnnotations: BooleanFormula is not properly Located -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment `BooleanFormula` is defined as {{{#!hs data BooleanFormula a = Var a | And [BooleanFormula a] | Or [BooleanFormula a] deriving (Eq, Data, Typeable, Functor, Foldable, Traversable) }}} An API Annotation can only be attached to an item of the form `Located a`. Replace this with a properly `Located` version, and attach the appropriate API Annotations to it -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 10:02:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 10:02:03 -0000 Subject: [GHC] #11018: ApiAnnotations: Add SourceText for unicode tokens Message-ID: <044.b2f994e490e36bcbf86a1f576ead0ae0@haskell.org> #11018: ApiAnnotations: Add SourceText for unicode tokens -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment there is no way to tell if a given token used its unicode variant or its normal one, except to look at the length of the token. This fails for the unicode '*'. Expose the original source text for unicode variants so that API Annotations can capture them specifically. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 10:32:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 10:32:30 -0000 Subject: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern checking In-Reply-To: <047.bea78f01cbb904765ad77c751bc8d3af@haskell.org> References: <047.bea78f01cbb904765ad77c751bc8d3af@haskell.org> Message-ID: <062.61db9250d6f4d67c8cf3a190fb222f18@haskell.org> #595: Overhaul GHC's overlapping/non-exhaustive pattern checking -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 10:42:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 10:42:17 -0000 Subject: [GHC] #11019: ApiAnnotations: Make all RdrName occurences Located Message-ID: <044.6f9b0661f882f5c32756a32bbf81653d@haskell.org> #11019: ApiAnnotations: Make all RdrName occurences Located -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment the API Annotations can only be used on the `ParsedSource`, as there are changes made to the `RenamedSource` that prevent it from being used to round trip source code. It is possible to build a map from every `Located Name` in the `RenamedSource` from its location to the `Name`, which can then be used when resolved names are required when changing the `ParsedSource`. However, there are instances where the identifier is not located, specifically {{{#!hs (GHC.VarPat name) (GHC.HsVar name) (GHC.UserTyVar name) (GHC.HsTyVar name) }}} Replace each of the `name` types above with `(Located name)` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 11:25:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 11:25:36 -0000 Subject: [GHC] #10845: Incorrect behavior when let binding implicit CallStack object In-Reply-To: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> References: <053.cff44270042de7bde1a56c8d798b5b0a@haskell.org> Message-ID: <068.de8ce17ed945e7a5cc3fcf05f2549de8@haskell.org> #10845: Incorrect behavior when let binding implicit CallStack object -------------------------------------+------------------------------------- Reporter: nitromaster101 | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, making it part of defaulting sounds just right! Can you try that? Simion -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 11:49:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 11:49:13 -0000 Subject: [GHC] #11013: GHC sometimes forgets to test for hs-boot consistency In-Reply-To: <045.728964e4952015da2de47ca14cc36513@haskell.org> References: <045.728964e4952015da2de47ca14cc36513@haskell.org> Message-ID: <060.e83b8058cc65232e59aeef9745d497c3@haskell.org> #11013: GHC sometimes forgets to test for hs-boot consistency -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 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 simonpj): Thanks Edward: might you also manage to fix it in due course? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 12:11:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 12:11:05 -0000 Subject: [GHC] #11019: ApiAnnotations: Make all RdrName occurences Located In-Reply-To: <044.6f9b0661f882f5c32756a32bbf81653d@haskell.org> References: <044.6f9b0661f882f5c32756a32bbf81653d@haskell.org> Message-ID: <059.c44acc9d4bd85a32e3a536f879025df8@haskell.org> #11019: ApiAnnotations: Make all RdrName occurences Located -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | ApiAnnotations Operating System: 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 I'm missing something very simple, but if you have a, for example, `LHsExpr Name` which matches the pattern `(L loc (HsVar name))`, the `loc` should apply just as well to the `name` as to the overall expression. My understanding of each of the cases above is that they all have this property, so adding another `Located` wrapper would be redundant. Or am I missing something? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 12:54:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 12:54:15 -0000 Subject: [GHC] #10998: Parser should suggest -XMagicHash In-Reply-To: <043.3df6745fc43649973c9f6cd84b47f3f2@haskell.org> References: <043.3df6745fc43649973c9f6cd84b47f3f2@haskell.org> Message-ID: <058.d49a9d5c38ee0fc150796c93f2a42b27@haskell.org> #10998: Parser should suggest -XMagicHash -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (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 rwbarton): Probably rather more common is the case `unsafeCoerce# foo`, and now this is not a parse error but rather an out-of-scope variable error (for both `unsafeCoerce` and `#`). Would be nice to catch this case too, perhaps by checking, when raising an out-of-scope error for `#`, whether it immediately follows a letter-type identifier? Also be sure not to suggest `-XMagicHash` if it is on already (e.g. `:t foo #`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 13:24:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 13:24:28 -0000 Subject: [GHC] #11011: Type-indexed TypeReps, Static Pointers and Distributed Closures In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.b39bffbf5ade5948d3880439d30b1d5e@haskell.org> #11011: Type-indexed TypeReps, Static Pointers and Distributed Closures -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): From the wiki: > To ease the transition we will provide both > * The old API via a (deprecated) new module `Data.Typeable710`. > * The old API via the exiting module `Data.Typeable` but with new names for (deprecated) old types and functions. This doesn't appear to ease the transition to me. It means forcing users to make a choice: 1) be lazy and change your import, or 2) educate themselves about our new interface, which involves a non-trivial amount of whiz-bang new features. Many will choose (1), because many people are lazy, especially in the face of type theory. Then those people will have to change again. Furthermore, this violates the "3-year no-warning maintenance window" policy being formulated on the libraries@ list. And, with a little type-level hackery, I think we can have our cake and eat it to: use just 1 set of names for both APIs. To wit: {{{#!hs data TypeRep710 = forall a. TypeRep710 (TypeRep80 a) data TypeRep80 :: k -> * type family TypeRep :: k where TypeRep = TypeRep710 TypeRep = TypeRep80 class Typeable (a :: k) where typeRep# :: Proxy# a -> TypeRep80 a type family TypeRepKind res where TypeRepKind (proxy (a :: k) -> b) = k TypeRepKind (TypeRep80 (a :: k)) = k class TypeRepResult res where type TypeRepIndex res :: TypeRepKind res typeRep :: Typeable (TypeRepIndex res) => res instance (b ~ TypeRep710) => TypeRepResult (proxy a -> b) where type TypeRepIndex (proxy a -> b) = a typeRep (_ :: proxy a) = TypeRep710 (typeRep :: TypeRep80 a) instance TypeRepResult (TypeRep80 a) where type TypeRepIndex (TypeRep80 a) = a typeRep = undefined }}} This works on my branch. The following definitions also work: {{{#!hs foo :: TypeRep -> () foo = undefined bar :: TypeRep Int -> () bar = undefined }}} where the first gets `TypeRep710` and the second gets `TypeRep80`. We also conveniently have `typeRep :: Typeable a => proxy a -> TypeRep` (where that's the `TypeRep710`) and `typeRep :: Typeable a => TypeRep a` (where that's the `TypeRep80`). In a few years, we just remove the compatibility shim. :) Do I honestly think this is a good idea? I'm not sure. But I don't have a better one that will keep everyone happy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 13:28:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 13:28:42 -0000 Subject: [GHC] #10462: GHCi doesn't work Any and missing RealWorld foreign prim imports In-Reply-To: <045.272515eb6529b0f69e6fb29bb854188b@haskell.org> References: <045.272515eb6529b0f69e6fb29bb854188b@haskell.org> Message-ID: <060.9295f24c6e0119037a518ee1955586b7@haskell.org> #10462: GHCi doesn't work Any and missing RealWorld foreign prim imports -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): I don't think your first example works as expected. It type checks but the calling convention is silently ignored and replaced by the default CCall one (see #3336 and "convToABI" in compiler/ghci/LibFFI.hsc). The other examples fail because "generateCCall" from compiler/ghci/ByteCodeGen.hs shouldn't be called at all for primops and there are errors when parameters are pushed (your first case) or when parameters are converted into types understandable by libffi (second case). I attach a patch with an additional check which fails sooner and in a nicer way (similarily to #1257). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 13:29:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 13:29:27 -0000 Subject: [GHC] #10462: GHCi doesn't work Any and missing RealWorld foreign prim imports In-Reply-To: <045.272515eb6529b0f69e6fb29bb854188b@haskell.org> References: <045.272515eb6529b0f69e6fb29bb854188b@haskell.org> Message-ID: <060.20fb8df2f6ec2ffa8d70084657abdf28@haskell.org> #10462: GHCi doesn't work Any and missing RealWorld foreign prim imports -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * Attachment "0001-ghci-indicate-that-foreign-primops-are-not- supported.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 13:31:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 13:31:41 -0000 Subject: [GHC] #10462: GHCi doesn't work Any and missing RealWorld foreign prim imports In-Reply-To: <045.272515eb6529b0f69e6fb29bb854188b@haskell.org> References: <045.272515eb6529b0f69e6fb29bb854188b@haskell.org> Message-ID: <060.dc491c23d9b799d40775e1acd33c0025@haskell.org> #10462: GHCi doesn't work Any and missing RealWorld foreign prim imports -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 13:47:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 13:47:16 -0000 Subject: [GHC] #11011: Type-indexed TypeReps, Static Pointers and Distributed Closures In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.57cab00b1aeb55983bcd6cc93686e175@haskell.org> #11011: Type-indexed TypeReps, Static Pointers and Distributed Closures -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Remember: * Most things that use `Typeable` will continue to work un-modified. The class has not changed its kind; and the functions `cast`, `gcast` etc continue to work with the same signatures. * I believe that only a relatively small number of packages (mostly Edward K's) decompose `TypeRep`; in fact, Richard I think you did a small study that discovered this. The story is already quite complicated. Making it more complicated still with a back-compat shim is undesirable unless it is absolutely necessary. First thing is to nail the API etc; then we must discuss transition. None of this is going to land until after 8.0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 13:50:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 13:50:44 -0000 Subject: [GHC] #11020: Make worker-wrapper transformation optional. Message-ID: <046.af56752a88fefa3cca6c1cc155378f63@haskell.org> #11020: Make worker-wrapper transformation optional. -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 would like the worker-wrapper transformation to be optional, so I can disable it in my very specific use case. I propose to add a {{{-fworker- wrapper}}} flag, which enables the worker-wrapper transformation, and is implied by {{{-O}}} The expected users of this flag, which includes myself, are GHC API users. In my Haskell-to-Hardware compiler [1], which uses the GHC API, I have seen no benifits of the worker-wrapper transformation. It does however induce longer compilation times. Further discussion can be seen here: https://mail.haskell.org/pipermail /ghc-devs/2015-October/010096.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 13:55:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 13:55:11 -0000 Subject: [GHC] #11020: Make worker-wrapper transformation optional. In-Reply-To: <046.af56752a88fefa3cca6c1cc155378f63@haskell.org> References: <046.af56752a88fefa3cca6c1cc155378f63@haskell.org> Message-ID: <061.0e0264bea6392f0e0f86b90e8ee3a88b@haskell.org> #11020: Make worker-wrapper transformation optional. -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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:D1372 Wiki Page: | -------------------------------------+------------------------------------- Changes (by darchon): * differential: => Phab:D1372 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 14:09:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 14:09:13 -0000 Subject: [GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth In-Reply-To: <045.4946614216cb9413670db0e02815dfbc@haskell.org> References: <045.4946614216cb9413670db0e02815dfbc@haskell.org> Message-ID: <060.eabde586ffe138db0089be1f74e14c51@haskell.org> #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): (By the way, slyfox's numbers are for 7.10. GHC 7.8.4 ran for 3 times as long and produced 5 times as much code as 7.10.1 on `M_200_manual`. I wonder why?) So there is some interesting code generation problem here, where a program of size O(n) involving nested lambdas/closures incurs a quadratic code size cost, due to repeatedly copying all the free variables of one closure into the next closure. I'm not sure whether this problem is solvable in general (or, perhaps, whether it is solvable without building rather fancy data structures into the code generator). (That's not to say it's hard necessarily, I just haven't thought about it at all.) In this case, however, I think we can avoid the quadratic blowup in code size by restructuring the input code. Basically, since the values bound by `<-` are never used except to build the final result, just use the ApplicativeDo desugaring to avoid writing any lambdas at all. I don't have a GHC with ApplicativeDo handy yet so I manually rewrote slyfox's {{{ a1 <- reset readPrec; a2 <- comma_field_eq_read "a1"; a3 <- comma_field_eq_read "a2"; ... a201 <- comma_field_eq_read "a200"; expectP (Punc "}"); return (D a1 ...) }}} to {{{ res <- D <$> reset readPrec <*&> comma_field_eq_read "a1" <*&> comma_field_eq_read "a2" ... <*&> comma_field_eq_read "a200"; expectP (Punc "}"); return res }}} Here `<*&>` is just a NOINLINE copy of `<*>`. That's important, otherwise `<*>` will be inlined, creating a lambda and defeating the purpose of the rewrite. Now the final code size is {{{ text data bss dec hex filename 101839 24008 0 125847 1eb97 M_200_applicative.o }}} and reading through the assembly there isn't anything obviously quadratic left (just a linear number of small functions, and one linearly-sized function to build the result--which should just be the constructor for D anyways, and probably shouldn't really count against the size of the Read instance). Presumably factoring out the "`<*&> comma_field_eq_read`" and `unpackCString#` pattern would reduce code size a bit more. Unfortunately the compile time is still quadratic, because type-checking `D <$> x1 <*> x2 <*> ... <*> xn` results in a Core program with a quadratic number of types (`D` has type `(Int ->)^n -> D`, and then `D <$> x1` has type `(Int ->)^(n-1) -> f D`, and `D <$> x1 <*> x2` has type `(Int ->)^(n-2) -> f D`, etc.) It's still decently faster than building slyfox's manual version (about 2/3 the compile time). Obviously this may affect runtime performance too, but my position is that `deriving Read` is not intended to be (and is not in practice either) a high-performance parser, so I don't really care if it happens to get a bit slower. As long as `read` doesn't become asymptotically slower, which seems unlikely considering the generated code was originally asymptotically larger in size, I think it's fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 14:18:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 14:18:37 -0000 Subject: [GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth In-Reply-To: <045.4946614216cb9413670db0e02815dfbc@haskell.org> References: <045.4946614216cb9413670db0e02815dfbc@haskell.org> Message-ID: <060.a222e78f629685737d85764e3f9e3f36@haskell.org> #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Reid, interesting! So you think it's all in the code generation and closure construction. Can you give a simple test case, separate from `deriving Read` that demonstrates the phenomenon, with the monadic and applicative versions side by side, but with very different perf? That would help to focus our attention. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 14:47:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 14:47:17 -0000 Subject: [GHC] #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth In-Reply-To: <045.4946614216cb9413670db0e02815dfbc@haskell.org> References: <045.4946614216cb9413670db0e02815dfbc@haskell.org> Message-ID: <060.800e0d6d918cffa6996d50f28c753cc3@haskell.org> #10980: Deriving Read instance from datatype with N fields leads to N^2 code size growth -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 rwbarton): * failure: None/Unknown => Compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 15:16:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 15:16:09 -0000 Subject: [GHC] #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name In-Reply-To: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> References: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> Message-ID: <057.5c267a30cd8ff0c9265d74fe24a053e9@haskell.org> #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name -------------------------------------+------------------------------------- Reporter: ony | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | driver/recomp011 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1326 Wiki Page: | Phab:D1335 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 7.10.3 => 8.0.1 Comment: Merged Phab:D1335 (updated for consistency with existing tools autoconf usage) to 7.10.3. Still need to merge to `master`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 15:24:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 15:24:45 -0000 Subject: [GHC] #10462: GHCi doesn't work Any and missing RealWorld foreign prim imports In-Reply-To: <045.272515eb6529b0f69e6fb29bb854188b@haskell.org> References: <045.272515eb6529b0f69e6fb29bb854188b@haskell.org> Message-ID: <060.9104b3b65a139b946785894f5f04f703@haskell.org> #10462: GHCi doesn't work Any and missing RealWorld foreign prim imports -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: low | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 15:40:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 15:40:06 -0000 Subject: [GHC] #910: --make should have a -j flag for parallel building In-Reply-To: <044.71389d84cf1d08cc9be1b6b2f82c78b7@haskell.org> References: <044.71389d84cf1d08cc9be1b6b2f82c78b7@haskell.org> Message-ID: <059.3dc727d0ddc3d1b1afcf13c070797c33@haskell.org> #910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: closed Priority: normal | Milestone: ? Component: Compiler | Version: 6.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: 8184, 8235 | Blocking: Related Tickets: #9221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Wearing my GHC developer's hat: I don't like environment flags controlling the compiler's behavior, since they make it harder to reproduce or identify issues. It's very helpful if I can tell the user to run `cabal build -v` and extract the ghc command line and know that everything that affects ghc's operation is specified on that command line or in the input files. Implicit global state is bad, right? Of course, in reality there is already implicit global state (versions of installed packages, versions of C compiler/CPP/LLVM/etc.), but the less the better. Compare for example [https://gcc.gnu.org/onlinedocs/gcc /Environment-Variables.html Environment Variables Affecting GCC], which roughly amounts to LANG, TMPDIR and where to look for headers and libraries. In principle `-jN` should not affect ghc's behavior, and then I would not really be against adding an environment variable for it, but in practice it does: see #9370, which I think is still unfixed, not to mention the possibility of bugs in `-jN` itself. Wearing my GHC user's hat: I don't really see the need for an environment variable here. Doesn't the `stack build --ghc-options="-j4"` that nh2 mentioned solve your immediate problem? And using this environment variable doesn't strike me as the Right Solution to any problem: if you are invoking ghc directly then you don't need the environment variable, while if you are invoking it from a larger build system then ideally you would make the build system aware of the amount of parallelism ghc is using, and at that point you might as well make the build system aware of the `-jN` flag as well. In summary, I don't think there is a good case for adding such an environment variable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 15:40:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 15:40:38 -0000 Subject: [GHC] #11020: Make worker-wrapper transformation optional. In-Reply-To: <046.af56752a88fefa3cca6c1cc155378f63@haskell.org> References: <046.af56752a88fefa3cca6c1cc155378f63@haskell.org> Message-ID: <061.35178161679584768c1cf068786cc5df@haskell.org> #11020: Make worker-wrapper transformation optional. -------------------------------------+------------------------------------- Reporter: darchon | Owner: darchon Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1372 Wiki Page: | -------------------------------------+------------------------------------- Changes (by darchon): * owner: => darchon * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 16:00:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 16:00:10 -0000 Subject: [GHC] #11021: Document best practices for bringing up Sphinx on Windows Message-ID: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> #11021: Document best practices for bringing up Sphinx on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 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 Sphinx documentation tool that we now use to generate the users guide is unfortunately a bit tricky to get working on Windows. See, for instance, https://mail.haskell.org/pipermail/ghc- devs/2015-October/010199.html We need to improve this situation or at very least document how users can build documentation on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 17:00:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 17:00:58 -0000 Subject: [GHC] #11022: Invalid ELF "note" section format Message-ID: <045.8f29382f96dd0bd7affe58790341c9d8@haskell.org> #11022: Invalid ELF "note" section format ----------------------------------------+--------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.10.2 Keywords: | Operating System: POSIX Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------- GHC adds a section called ".debug-ghc-link-info" to ELF binaries (see compiler/main/DriverPipeline.hs:1660). The section type is "note" (SHT_NOTE) but the format is not compliant with the ELF specification (see http://refspecs.linuxbase.org/elf/elf.pdf section 2 "Note section"). It makes tools reading sections with "note" type fail. I think we should change the section type to "progbits". Is there any problem with that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 17:05:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 17:05:07 -0000 Subject: [GHC] #11022: Invalid ELF "note" section format In-Reply-To: <045.8f29382f96dd0bd7affe58790341c9d8@haskell.org> References: <045.8f29382f96dd0bd7affe58790341c9d8@haskell.org> Message-ID: <060.e9267b0c3b06a847f907b19f14623772@haskell.org> #11022: Invalid ELF "note" section format ---------------------------+---------------------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Driver | Version: 7.10.2 Resolution: | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------+---------------------------------------- Changes (by bgamari): * milestone: => 8.0.1 Comment: Sounds like the right thing to do. Are you offering a patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 17:21:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 17:21:24 -0000 Subject: [GHC] #11022: Invalid ELF "note" section format In-Reply-To: <045.8f29382f96dd0bd7affe58790341c9d8@haskell.org> References: <045.8f29382f96dd0bd7affe58790341c9d8@haskell.org> Message-ID: <060.f12c3db374f2735253df76a73c4f7d6f@haskell.org> #11022: Invalid ELF "note" section format ---------------------------+---------------------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Driver | Version: 7.10.2 Resolution: | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------+---------------------------------------- Changes (by hsyl20): * Attachment "0001-driver-use-PROGBITS-type-for-.debug-ghc-link-info- se.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 18:03:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 18:03:19 -0000 Subject: [GHC] #11022: Invalid ELF "note" section format In-Reply-To: <045.8f29382f96dd0bd7affe58790341c9d8@haskell.org> References: <045.8f29382f96dd0bd7affe58790341c9d8@haskell.org> Message-ID: <060.7c561bfa76296da11095e0294a8028f1@haskell.org> #11022: Invalid ELF "note" section format ---------------------------+---------------------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Driver | Version: 7.10.2 Resolution: | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------+---------------------------------------- Changes (by hsyl20): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 18:16:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 18:16:00 -0000 Subject: [GHC] #11013: GHC sometimes forgets to test for hs-boot consistency In-Reply-To: <045.728964e4952015da2de47ca14cc36513@haskell.org> References: <045.728964e4952015da2de47ca14cc36513@haskell.org> Message-ID: <060.47faa2f1079fe5cf81b1409dd0c3a7c2@haskell.org> #11013: GHC sometimes forgets to test for hs-boot consistency -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 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: | -------------------------------------+------------------------------------- Changes (by ezyang): * owner: => ezyang Comment: Yes, when I switch to working on recomp avoidance proper for Backpack I'll deal with these bugs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 18:16:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 18:16:20 -0000 Subject: [GHC] #10333: hs-boot modification doesn't induce recompilation In-Reply-To: <045.b2a6545e2380bf06a403c64b9db0df81@haskell.org> References: <045.b2a6545e2380bf06a403c64b9db0df81@haskell.org> Message-ID: <060.769bdb00cc162ce258affe35138c0b2a@haskell.org> #10333: hs-boot modification doesn't induce recompilation -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: | -------------------------------------+------------------------------------- Changes (by ezyang): * owner: => ezyang -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 19:12:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 19:12:31 -0000 Subject: [GHC] #11021: Document best practices for bringing up Sphinx on Windows In-Reply-To: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> References: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> Message-ID: <061.2d987c37aa72380a3d3c39f8ddf67fc6@haskell.org> #11021: Document best practices for bringing up Sphinx on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 Resolution: | Keywords: 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 awson): * Attachment "mkUserGuidePart_fix_writeFile.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 19:23:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 19:23:00 -0000 Subject: [GHC] #11022: Invalid ELF "note" section format In-Reply-To: <045.8f29382f96dd0bd7affe58790341c9d8@haskell.org> References: <045.8f29382f96dd0bd7affe58790341c9d8@haskell.org> Message-ID: <060.779636f015e0ae5c58bc6430cd1cbb52@haskell.org> #11022: Invalid ELF "note" section format ---------------------------+---------------------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Driver | Version: 7.10.2 Resolution: | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1375 Wiki Page: | ---------------------------+---------------------------------------- Changes (by bgamari): * differential: => Phab:D1375 Comment: I've pushed this patch up to Phabricator as Phab:D1375 and written a bit more descriptive commit message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 19:32:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 19:32:45 -0000 Subject: [GHC] #11021: Document best practices for bringing up Sphinx on Windows In-Reply-To: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> References: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> Message-ID: <061.b8149d2c00f14bcae702f76995a189da@haskell.org> #11021: Document best practices for bringing up Sphinx on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): To clarify what is written in the cited (my) e-mail: the problem with Windows console codepage 65001 is not Sphinx-specific but pervades the whole Python ecosystem. And Python people won't fix it. Thus the only way to happily build GHC documentation with Sphinx on Windows is to modify `mkUserGuidePart`. I've attached the cited patch as a separate file for convenience. Patch is very simple and basically tells handle I/O functions to expect `utf8`-encoded content. I didn't guard the changes to be Windows-specific because I think it is at least harmless on other systems and, perhaps, can help in some other peculiar configurations. Regarding Sphinx installation I believe the most "automated" way would be to add MSys2/MINGW Sphinx package as another MSys2/MINGW dependency, but this requires not only `configure.ac` modification but (most important) fixing MSys2/MINGW Sphinx package itself, which should better be upstreamed to MSys2/MINGW, and I have no time to do this ATM, sorry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 20:02:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 20:02:34 -0000 Subject: [GHC] #11015: Add note describing unit ids, unit keys, package ids, and package keys, In-Reply-To: <046.ad3e9e67c90d3d94ed19c8b0a6b3f499@haskell.org> References: <046.ad3e9e67c90d3d94ed19c8b0a6b3f499@haskell.org> Message-ID: <061.9ef294e8f45a5301e910f9227a4cf7f6@haskell.org> #11015: Add note describing unit ids, unit keys, package ids, and package keys, -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: 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): Perhaps `Packages.hs` or `Modules.hs`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 20:40:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 20:40:24 -0000 Subject: [GHC] #10848: GHC/GHCi should optionally print errors in reversed order In-Reply-To: <043.346863bae2dced560ac8325c22b2fccb@haskell.org> References: <043.346863bae2dced560ac8325c22b2fccb@haskell.org> Message-ID: <058.444a0be84aa54830d638dc0964a2e81c@haskell.org> #10848: GHC/GHCi should optionally print errors in reversed order -------------------------------------+------------------------------------- Reporter: osa1 | Owner: siddhanathan Type: feature request | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 7.11 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:D1367 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"499ce291b6bab252c63f0791276c38012280f0b4/ghc" 499ce291/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="499ce291b6bab252c63f0791276c38012280f0b4" Add flag to reverse errors in GHC/GHCi Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1367 GHC Trac Issues: #10848 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 20:40:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 20:40:24 -0000 Subject: [GHC] #10970: Built in MIN_VERSION macro support In-Reply-To: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> References: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> Message-ID: <060.42d95d0f26cd383c1b6a1c8fec27a7fc@haskell.org> #10970: Built in MIN_VERSION macro support -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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:D1349 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a9c93bdd8b027d6de09a3eada7721e7fd2d3e050/ghc" a9c93bdd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a9c93bdd8b027d6de09a3eada7721e7fd2d3e050" Implement MIN_VERSION and VERSION macros natively in GHC. Test Plan: validate Reviewers: austin, thomie, bgamari Reviewed By: thomie Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1349 GHC Trac Issues: #10970 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 22:21:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 22:21:31 -0000 Subject: [GHC] #11014: re-order GHC type errors for clarity In-Reply-To: <047.63b2ee64fbc0e8cf4ea8e84a14f0ce30@haskell.org> References: <047.63b2ee64fbc0e8cf4ea8e84a14f0ce30@haskell.org> Message-ID: <062.a2e8e4316dafe93c22c4d71aa10f09f7@haskell.org> #11014: re-order GHC type errors for clarity -------------------------------------+------------------------------------- Reporter: elaforge | Owner: elaforge Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 thomie): * failure: None/Unknown => Incorrect warning at compile-time Comment: Also discussed in this thread: https://mail.haskell.org/pipermail/glasgow- haskell-users/2015-October/026066.html. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 22:45:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 22:45:16 -0000 Subject: [GHC] #11021: Document best practices for bringing up Sphinx on Windows In-Reply-To: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> References: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> Message-ID: <061.a699a47ca56627c837652e9a02813b60@haskell.org> #11021: Document best practices for bringing up Sphinx on Windows ----------------------------------+---------------------------------------- Reporter: bgamari | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Changes (by thomie): * status: new => patch * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 23:47:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 23:47:40 -0000 Subject: [GHC] #11010: Untouchable type, pattern synonyms In-Reply-To: <051.ac3dbe8ba403159d004fffbd87da4f52@haskell.org> References: <051.ac3dbe8ba403159d004fffbd87da4f52@haskell.org> Message-ID: <066.8e8932fd6128a50c4c13aa84162707d3@haskell.org> #11010: Untouchable type, pattern synonyms ---------------------------------+------------------------------ Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Comment (by simonpj): The signatures are plain wrong. See comment:5 of #10928. In both signatures, the response should be 'a' is not in scope in the constraint `(a ~ Int)`. It's in the "required" position but mentions an existential variable. I think we should reverse the provided/required order, as descried in #10928, and do it for 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 23:49:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 23:49:42 -0000 Subject: [GHC] #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name In-Reply-To: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> References: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> Message-ID: <057.13725946966f8ffb06fc5e64c86d70a4@haskell.org> #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name -------------------------------------+------------------------------------- Reporter: ony | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | driver/recomp011 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1326 Wiki Page: | Phab:D1335 -------------------------------------+------------------------------------- Comment (by hsyl20): Is there a way to use Data.Binary.Get in Systools? We could totally avoid using readelf and it should be faster too (no fork, no parsing, no need to use String). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 23:54:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 23:54:03 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.7a99c3edce8908230863874f1f4877ed@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => highest Comment: I think we should get on and reverse the order for 8.0. And make sure that in {{{ pattern P :: req => prov => t1 -> ... -> tn -> T s1 .. sm }}} then * The "universal" tyvars are fv(s1..sm) * The "existential" tyvars are fv(t1..tn) minus the universals and the fvs of req must be all universal! Since this is breaking change, we'd better get it done asap. Agreed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 23:54:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 23:54:53 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.6ecd410bfae6626355af9f06d5cc5b27@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): PS: this would fix #11010, by rejecting both the (bogus) examples given there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 26 23:59:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Oct 2015 23:59:46 -0000 Subject: [GHC] #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name In-Reply-To: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> References: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> Message-ID: <057.bd0e16313759876e331426ac4801c84d@haskell.org> #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name -------------------------------------+------------------------------------- Reporter: ony | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | driver/recomp011 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1326 Wiki Page: | Phab:D1335 -------------------------------------+------------------------------------- Comment (by thomie): Add `binary` to `Build-Depends` in `compiler/ghc.cabal.in` (and `compiler/ghc.cabal`, so you don't have to rerun configure). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 00:16:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 00:16:45 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.bd8263f9910cc9c4b38d67c1b34aeba9@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I agree with Simon. Are we changing to either (1) or (2) from the original description as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 00:57:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 00:57:02 -0000 Subject: [GHC] #11023: ghci and ghc-pkg disagree about what's exposed Message-ID: <044.ef36fd7d1a67594e7e4f6b601e531b2a@haskell.org> #11023: ghci and ghc-pkg disagree about what's exposed -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 7.10.2 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: -------------------------------------+------------------------------------- I have installed vector-0.10.12.3 and vector-0.11.0.0. At some point, I had hidden both from the package database; however, I later used ghc-pkg expose to mark one as visible again. Now I seem to be in a strange state where ghci and ghc-pkg disagree about what is hidden: {{{ % ghci-7.10.2 GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> :m +Data.Vector.Unboxed : Could not find module ?Data.Vector.Unboxed? It is a member of the hidden package ?vector-0.11.0.0 at vecto_3jMaUrldidp1bqsrn0qsS2?. It is a member of the hidden package ?vector-0.10.12.3 at vecto_1COyUuV1LrA1IjYnWfJnbs?. Prelude> Leaving GHCi. % ghc-pkg-7.10.2 list vector | cat /usr/local/lib/ghc-7.10.2/package.conf.d: (no packages) /home/dmwit/.ghc/x86_64-linux-7.10.2/package.conf.d: vector-0.10.12.3 (vector-0.11.0.0) % ghc-pkg-7.10.2 describe vector-0.10.12.3 | grep 'key:\|exposed:' key: vecto_1COyUuV1LrA1IjYnWfJnbs exposed: True }}} I have tried reproducing this with other packages in a handful of ways and failed; so I can't give instructions for reproducing. But I am happy to perform any diagnostics you can think of. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 01:02:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 01:02:20 -0000 Subject: [GHC] #11023: ghci and ghc-pkg disagree about what's exposed In-Reply-To: <044.ef36fd7d1a67594e7e4f6b601e531b2a@haskell.org> References: <044.ef36fd7d1a67594e7e4f6b601e531b2a@haskell.org> Message-ID: <059.264b87accd87194dfb9ea0773e31ecf5@haskell.org> #11023: ghci and ghc-pkg disagree about what's exposed -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): So ghci calls vector-0.10.12.3 hidden while ghc-pkg calls it exposed. I think this will happen when one of the dependencies of vector-0.10.12.3 is hidden. Not confident though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 01:02:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 01:02:30 -0000 Subject: [GHC] #6119: complain when ghc-pkg doesn't find any matching packages in a given database In-Reply-To: <044.cc2d10883421d984b74d5645a20dd07c@haskell.org> References: <044.cc2d10883421d984b74d5645a20dd07c@haskell.org> Message-ID: <059.9d68b2670d5d7102e7e5ed49bbd50505@haskell.org> #6119: complain when ghc-pkg doesn't find any matching packages in a given database -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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 dmwit): * status: closed => new * resolution: fixed => Comment: GHC has since grown a colored version of ghc-pkg, which did not inherit this nice feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 01:19:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 01:19:50 -0000 Subject: [GHC] #6119: complain when ghc-pkg doesn't find any matching packages in a given database In-Reply-To: <044.cc2d10883421d984b74d5645a20dd07c@haskell.org> References: <044.cc2d10883421d984b74d5645a20dd07c@haskell.org> Message-ID: <059.ceb3145ff07b9499fe18f40e67246a47@haskell.org> #6119: complain when ghc-pkg doesn't find any matching packages in a given database -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10785 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => ghc-pkg * related: => #10785 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 02:10:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 02:10:05 -0000 Subject: [GHC] #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name In-Reply-To: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> References: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> Message-ID: <057.429c8b30f6d1c697d60d652fd0afb14e@haskell.org> #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name -------------------------------------+------------------------------------- Reporter: ony | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | driver/recomp011 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1326 Wiki Page: | Phab:D1335 -------------------------------------+------------------------------------- Comment (by ony): Replying to [comment:7 hsyl20]: > Is there a way to use Data.Binary.Get in Systools? We could totally avoid using readelf and it should be faster too (no fork, no parsing, no need to use String). `Data.Binary.Get` is also monad parser library but for bytestrings. Writing yet another ELF-file parser but pure sounds interesting, but ineffective (better to spend that effort on something else). I do agree that using `libelf` might be faster. But I also like idea that `ghc` requires only `binutils`. Adding more dependency on something while we can get the same functionality with existing dependency looks bad for me. Replying to [comment:8 thomie]: > Add `binary` to `Build-Depends` in `compiler/ghc.cabal.in` (and `compiler/ghc.cabal`, so you don't have to rerun configure). This might be true for release tar-balls, but not for source code repository which should always go through `autoreconf` (`perl boot`) and `configure` to generate from files from their `.in`. And that's described in both `README.md` and `HACKING.md`. Note that `compiler/ghc.cabal` is in ignores where it should be. Though file is committed into repo - which is wrong. Probably some-one did that by mistake and/or when .gitignore entry were added no-one removed it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 03:26:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 03:26:21 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.6cb39d66181286dab7a30a06e3bbd0ee@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): I'd be happy with whatever resolution you want to make here. My code will adapt. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 03:44:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 03:44:58 -0000 Subject: [GHC] #10998: Parser should suggest -XMagicHash In-Reply-To: <043.3df6745fc43649973c9f6cd84b47f3f2@haskell.org> References: <043.3df6745fc43649973c9f6cd84b47f3f2@haskell.org> Message-ID: <058.3be5f5e2f6249250d834b4fca2043229@haskell.org> #10998: Parser should suggest -XMagicHash -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (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 osa1): I'll work on this once I'm done with Phab:D1342. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 07:44:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 07:44:04 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.d9d9e67a55f1bf3b8f256fc4a547acf4@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think (1), that is: * Only specifying one constraint corresponds to the required constraints, with empty provided constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 11:54:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 11:54:32 -0000 Subject: [GHC] #11008: Difficulties around inferring exotic contexts In-Reply-To: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> References: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> Message-ID: <062.8d81f54f9c08c39c2bc6cff5dcb8b6d9@haskell.org> #11008: Difficulties around inferring exotic contexts -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm sorry -- I'm afraid I don't understand your last comment. Or, rather, my understanding leads me directly to the behavior we currently have: check derived instances for exotic contexts and reject if exotic, but skip the exotic-check for hand-written instances (including standalone- deriving). (Note that there is no GND in sight here -- just normal `deriving`.) Perhaps illustrate your idea with a few examples? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 13:25:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 13:25:11 -0000 Subject: [GHC] #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name In-Reply-To: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> References: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> Message-ID: <057.bc8d4b33fb732d82d61fb71029823d5a@haskell.org> #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name -------------------------------------+------------------------------------- Reporter: ony | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | driver/recomp011 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1326 Wiki Page: | Phab:D1335 -------------------------------------+------------------------------------- Comment (by hsyl20): I have recently written my own ELF parser (https://github.com/hsyl20/ViperVM/tree/master/src/lib/ViperVM/Format/Elf) so it is still fresh in my head. I have adapted it to GHC by removing intermediate data structures and everything that is not strictly required to extract a section. https://phabricator.haskell.org/D1381 I'm not an expert of lazy IO, so reviews are welcome. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 13:25:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 13:25:13 -0000 Subject: [GHC] #10999: ghc: panic! (the 'impossible' happened) In-Reply-To: <042.e700677e826396486b3741ddf6f847b0@haskell.org> References: <042.e700677e826396486b3741ddf6f847b0@haskell.org> Message-ID: <057.38fc985e7169d226870a5b4543634a6b@haskell.org> #10999: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: res | Owner: Type: bug | Status: new 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: | Blocking: Related Tickets: #10045 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f86fb5e5a0694ea57cace824bbc0dce06bdf0698/ghc" f86fb5e5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f86fb5e5a0694ea57cace824bbc0dce06bdf0698" Add regression tests for #10045, #10999 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 13:25:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 13:25:13 -0000 Subject: [GHC] #10045: type holes related ghc panic In-Reply-To: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> References: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> Message-ID: <059.58d61a69e2404055059d7e525acbd7a9@haskell.org> #10045: type holes related ghc panic -------------------------------------+------------------------------------- Reporter: pacak | Owner: thoughtpolice Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D646 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f86fb5e5a0694ea57cace824bbc0dce06bdf0698/ghc" f86fb5e5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f86fb5e5a0694ea57cace824bbc0dce06bdf0698" Add regression tests for #10045, #10999 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 13:25:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 13:25:13 -0000 Subject: [GHC] #10997: Pattern synonym causes Iface error. In-Reply-To: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> References: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> Message-ID: <064.5c98e3d1c68f8de2efedb636ed2f3f9a@haskell.org> #10997: Pattern synonym causes Iface error. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10997 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0ce858e571f0f8f378f2b04f8d924d1fafeafdd1/ghc" 0ce858e5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0ce858e571f0f8f378f2b04f8d924d1fafeafdd1" Zonk properly when checkig pattern synonyms Fixes Trac #10997 Merge to stable branch }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 13:42:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 13:42:32 -0000 Subject: [GHC] #11008: Difficulties around inferring exotic contexts In-Reply-To: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> References: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> Message-ID: <062.d6982912950d002fd4171572263300bd@haskell.org> #11008: Difficulties around inferring exotic contexts -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): All I'm suggesting is that rather than the iterative process of 1. GHC writes an instance 2. GHC checks for a (single?) matching instance head for all constraints 3. GHC simplifies those constraints 4. Go to step 1 until minimal constraints found (which I refer to as the "simplify and reject" method), GHC could get to step 3, and then just continue to simplify the constraints ''without'' checking for matching instances on all ''simplified'' constraints (i.e. more like how a function (presumably) simplifies constraints, which I refer to as the "simplify and typecheck" method, where no rejection occurs if no matching instance is found). Thus GHC would still require a standalone instance for `data X a b = MkX (a -> b) deriving Eq` because step (in the first round) would fail. The idea is that the above process would allow auto-deriving when a single matching instance is found for the unsimplified context. In the case of overlapping or missing instances, I have no opinion on the behavior. Maybe this approach is too ad-hoc, but I think it would result in expected behavior. My main reasons for this are that 1. If there's a single instance in scope, GHC should assume I know how to use it. 2. Writing the standalone instance `deriving instance (Eq (Foo r)) => Eq (Bar r)` does ''nothing'' to help me understand the exotic nature of the instance. [Not that I feel like I want advice in this area, mind you. I want GHC to assume I know what I'm doing.] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 13:59:42 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 13:59:42 -0000 Subject: [GHC] #10997: Pattern synonym causes Iface error. In-Reply-To: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> References: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> Message-ID: <064.50a5b169451f0ca38b0d196c6d719fe2@haskell.org> #10997: Pattern synonym causes Iface error. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: merge Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyn/should_compile/T10997, | T10997_1 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: typecheck/should_compile/T10997 => patsyn/should_compile/T10997, T10997_1 * status: new => merge Comment: Thanks for reporting this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 14:02:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 14:02:59 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.6b496c615a90655d4b6d2f4d274799a7@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): While we're changing the parser, we should make sure that explicit quantification is allowed. For example, {{{ pattern P :: forall a b. ... => forall c d. ... => .... }}} should introduce `a` and `b` as universals, and `c` and `d` as existentials. The existentials should scope over the provided constraints and the arguments, but not the result. The universals scope over the whole shebang. These should also be made available as scoped type variables in the pattern definition. There are four places where these variables might be in scope, labeled below: {{{ pattern P = (1) pattern P <- (2) pattern P (3) ... ... where P = (4) }}} The universals should be in scope everywhere. The existentials should be in scope only in `(3)` and `(4)`, I believe, but I'm really quite unsure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 14:06:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 14:06:17 -0000 Subject: [GHC] #10848: GHC/GHCi should optionally print errors in reversed order In-Reply-To: <043.346863bae2dced560ac8325c22b2fccb@haskell.org> References: <043.346863bae2dced560ac8325c22b2fccb@haskell.org> Message-ID: <058.46decc955021e5a91986cf0d5f18652c@haskell.org> #10848: GHC/GHCi should optionally print errors in reversed order -------------------------------------+------------------------------------- Reporter: osa1 | Owner: siddhanathan Type: feature request | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 7.11 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:D1367 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d1d8704cb3d003315177fad1394fce49f98fb1a2/ghc" d1d8704c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d1d8704cb3d003315177fad1394fce49f98fb1a2" Use correct documentation flag for freverse-errors Reviewers: austin, thomie, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1376 GHC Trac Issues: #10848 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 14:13:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 14:13:41 -0000 Subject: [GHC] #10045: type holes related ghc panic In-Reply-To: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> References: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> Message-ID: <059.6dbe78be9d1f14c5ce097e0d5a89c396@haskell.org> #10045: type holes related ghc panic -------------------------------------+------------------------------------- Reporter: pacak | Owner: thoughtpolice Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D646 Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): Can #10946 be in any way related to this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 14:17:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 14:17:56 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.fb7df2fbdece22a2c761887cc41aba0b@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, Wiki Page: | Phab:D1268 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"158d2a91581d82dc1690a858b474eaab3a02e43e/ghc" 158d2a9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="158d2a91581d82dc1690a858b474eaab3a02e43e" Make it possible to have different UniqSupply strategies To get reproducible/deterministic builds, the way that the Uniques are assigned shouldn't matter. This allows to test for that. It add 2 new flags: * `-dinitial-unique` * `-dunique-increment` And by varying these you can get interesting effects: * `-dinitial-unique=0 -dunique-increment 1` - current sequential UniqSupply * `-dinitial-unique=16777215 -dunique-increment -1` - UniqSupply that generates in decreasing order * `-dinitial-unique=1 -dunique-increment PRIME` - where PRIME big enough to overflow often - nonsequential order I haven't proven the usefullness of the last one yet and it's the reason why we have to mask the bits with `0xFFFFFF` in `genSym`, so I can remove it if it becomes contentious. Test Plan: validate on harbormaster Reviewers: simonmar, austin, ezyang, bgamari Reviewed By: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1360 GHC Trac Issues: #4012 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 14:33:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 14:33:26 -0000 Subject: [GHC] #11008: Difficulties around inferring exotic contexts In-Reply-To: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> References: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> Message-ID: <062.88568bc52b994794c9d8a7fbe8d74225@haskell.org> #11008: Difficulties around inferring exotic contexts -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:6 crockeea]: > 1. GHC writes an instance > 2. GHC checks for a (single?) matching instance head for all constraints > 3. GHC simplifies those constraints > 4. Go to step 1 until minimal constraints found > I'm afraid I still don't understand. (I really don't! I'm not trying to be obtuse. It comes naturally.) Do you mean to go back to step 2? Then I think I understand. > (which I refer to as the "simplify and reject" method), GHC could get to step 3, But now I'm lost again. How could we jump to step 3 without going through step 2? Step 2, as I understand it, is the step that actually finds a matching instance head, from which we can simplify. Step 3 would require the output of step 2 as its input. To be concrete, suppose we have a constraint `Eq [(a, Int)]`. I understand step 2 as identifying the instance head `Eq [b]`, which then, in step 3, uses its constraint `Eq b` to simplify the original constraint to `Eq (a, Int)`. So step 2 seems vital. > and then just continue to simplify the constraints ''without'' checking for matching instances on all ''simplified'' constraints (i.e. more like how a function (presumably) simplifies constraints, which I refer to as the "simplify and typecheck" method, where no rejection occurs if no matching instance is found). This seems to suggest just omitting the "exotic constraint" check. Because functions don't have that check. Otherwise, I don't see a difference between what goes on with `deriving` and what goes on with functions. The simplification algorithm looks the same to me. > > Thus GHC would still require a standalone instance for `data X a b = MkX (a -> b) deriving Eq` because step (in the first round) would fail. Which step did you mean? > The idea is that the above process would allow auto-deriving when a single matching instance is found for the unsimplified context. In the case of overlapping or missing instances, I have no opinion on the behavior. > > > Maybe this approach is too ad-hoc, but I think it would result in expected behavior. > > My main reasons for this are that > 1. If there's a single instance in scope, GHC should assume I know how to use it. > 2. Writing the standalone instance `deriving instance (Eq (Foo r)) => Eq (Bar r)` does ''nothing'' to help me understand the exotic nature of the instance. [Not that I feel like I want advice in this area, mind you. I want GHC to assume I know what I'm doing.] This part makes more sense to me. But then, consider the following: {{{ data X a b = MkX (a -> b) deriving instance Eq (a -> b) => Eq (X a b) data Y a b = MkY (X a b) deriving Eq }}} My understanding tells me that this should work under your proposal. This is because `Y` uses `X`'s instance, which GHC assumes is appropriate. Maybe I can paraphrase your idea: 1. GHC generates a set of constraints appropriate for deriving a given class. (That is, for `deriving (Eq X)`, this would be `Eq (a -> b)`.) These are all considered "unsimplified" constraints. 2. GHC tries to simplify all constraints. Any constraint produced as an output of simplification is considered "simplified". This step repeats until it can make no more progress. 3. GHC checks the "unsimplified" constraints, if there are any left, to make sure they are not exotic. It does ''not'' check "simplified" constraints. 4. If there are no exotic "unsimplified" constraints, accept the declaration. Is that about right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 14:56:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 14:56:34 -0000 Subject: [GHC] #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name In-Reply-To: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> References: <042.e244cf8dc95faa52bdcffe7336aa317f@haskell.org> Message-ID: <057.edeb0b1ac6e701ea1718699b0de0709f@haskell.org> #10974: Fix SysTools.readElfSection on platforms where "readelf" have different name -------------------------------------+------------------------------------- Reporter: ony | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | driver/recomp011 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1326 Wiki Page: | Phab:D1335 Phab:D1381 -------------------------------------+------------------------------------- Changes (by hsyl20): * differential: Phab:D1326 Phab:D1335 => Phab:D1326 Phab:D1335 Phab:D1381 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 15:08:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 15:08:33 -0000 Subject: [GHC] #11008: Difficulties around inferring exotic contexts In-Reply-To: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> References: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> Message-ID: <062.46061fb1825a716f2a0472e9f5a3adc7@haskell.org> #11008: Difficulties around inferring exotic contexts -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): Replying to [comment:7 goldfire]: > I'm afraid I still don't understand. (I really don't! I'm not trying to be obtuse. It comes naturally.) I'm quite sure your confusion is my fault. It's hard for me to talk reasonably about this since I know so little about how it works. > Do you mean to go back to step 2? Then I think I understand. Yes, I did mean step 2. > But now I'm lost again. How could we jump to step 3 without going through step 2? Step 2, as I understand it, is the step that actually finds a matching instance head, from which we can simplify. Ah, that makes sense. (Told you I don't know what I'm saying!) So GHC doesn't simplify constraints in functions? This is where the confusion arises for me. I can write: `foo a@(Foo _) = a == a` and GHC is perfectly happy to infer the context. > This seems to suggest just omitting the "exotic constraint" check. Because functions don't have that check. Right! This is what I'm trying to get at. > Which step did you mean? Step 2, where we check for a matching instance head. > But then, consider the following: > > {{{ > data X a b = MkX (a -> b) > deriving instance Eq (a -> b) => Eq (X a b) > > data Y a b = MkY (X a b) > deriving Eq > }}} > > My understanding tells me that this should work under your proposal. This is because `Y` uses `X`'s instance, which GHC assumes is appropriate. Under my proposal, GHC would accept your example. And this makes sense to me: GHC has (rightly) forced me to write an "explicit" instance for `X` (a standalone instance instead of an auto-derived one) which should tip me off that I'm doing something weird. At that point GHC has done its due diligence to warn me, it should then accept the instance for `Y` without question. > Maybe I can paraphrase your idea: > > 1. GHC generates a set of constraints appropriate for deriving a given class. (That is, for `deriving (Eq X)`, this would be `Eq (a -> b)`.) These are all considered "unsimplified" constraints. > 2. GHC tries to simplify all constraints. Any constraint produced as an output of simplification is considered "simplified". This step repeats until it can make no more progress. > 3. GHC checks the "unsimplified" constraints, if there are any left, to make sure they are not exotic. It does ''not'' check "simplified" constraints. > 4. If there are no exotic "unsimplified" constraints, accept the declaration. > > Is that about right? Well, almost. It seems that my original example would not be accepted with this algorithm because `C (F r)` can't be simplified, but also doesn't have a matching instance. I'll try one more time: 1. GHC generates a set of constraints for deriving a given class. (For example, `deriving (Eq X)` would generate the context `Eq (a -> b)`. For the purposes of this algorithm, let's just use this example. 2. GHC tries to simplify the constraint `Eq (a -> b)`. If it can, go to step 3. Otherwise, throw an error and require StandaloneDeriving. 3. GHC found a matching instance for `Eq (a -> b)` (is this equivalent to "GHC was able to simplify the constraint `Eq (a -> b)`"?). Assume that the instance `Eq (a -> b)` has already been simplified to something like `(C a b) => Eq (a -> b)`. Then rewrite the auto-generated instance `(Eq (a -> b)) => Eq (X a b)` to the ''already simplified'' instance `(C a b) => Eq (X a b)`, without doing **any** checks on constraints `(C a b)` at all. (They already typecheck, and since there is a matching instance, GHC will ignore anything exotic about it.) Thanks for your patience while I try to figure out what I mean! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 15:17:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 15:17:58 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.4d120215c02f7f3018bc2720953741fe@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, Wiki Page: | Phab:D1268 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"ffcdd84f86727c1621be0a0e522eb6a3a64e479f/ghc" ffcdd84/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ffcdd84f86727c1621be0a0e522eb6a3a64e479f" Sort field labels before fingerprint hashing `fsEnvElts :: FastStringEnv a -> [a]` returns a list of `[a]` in the order of `Unique`s which is arbitrary. In this case it gives a list of record fields in arbitrary order, from which we then extract the field labels to contribute to the record fingerprint. The arbitrary ordering of field labels introduces unnecessary nondeterminism in interface files as demonstrated by the test case. We sort `FastString` here. It's safe, because the only way that the `Unique` associated with the `FastString` is used in comparison is for equality. If the `Unique`s are different it fallbacks to comparing the actual `ByteString`. Reviewed By: ezyang, thomie, bgamari, austin Differential Revision: https://phabricator.haskell.org/D1373 GHC Trac Issues: #4012 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 15:32:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 15:32:30 -0000 Subject: [GHC] #11008: Difficulties around inferring exotic contexts In-Reply-To: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> References: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> Message-ID: <062.d6d5d663b211868d467457e0d9558ae9@haskell.org> #11008: Difficulties around inferring exotic contexts -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think our algorithms are the same. Mine accepts your original example, because it simplifies `Eq (Foo r)` to get `C (F r)`, so in my terminology, `C (F r)` is considered "simplified". Now that we have an idea of what we're talking about, we can think about whether or not it is actually a good idea. I'm inclined to think it is. One tiny, easily-surmountable wrinkle is that we'd need to check for `FlexibleContexts` and/or `UndecidableInstances` and/or ... before accepting the constraint. But that's fairly routine. I'd want Simon's opinion on this before rubber stamping it. And then there's the matter of implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 16:56:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 16:56:46 -0000 Subject: [GHC] #10997: Pattern synonym causes Iface error. In-Reply-To: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> References: <049.dc8e40260dd5587e1caf4aff1723e027@haskell.org> Message-ID: <064.fcc3dbdcaf22ee24cab5d8981622dd72@haskell.org> #10997: Pattern synonym causes Iface error. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyn/should_compile/T10997, | T10997_1 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: => 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 17:17:42 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 17:17:42 -0000 Subject: [GHC] #10999: ghc: panic! (the 'impossible' happened) In-Reply-To: <042.e700677e826396486b3741ddf6f847b0@haskell.org> References: <042.e700677e826396486b3741ddf6f847b0@haskell.org> Message-ID: <057.08adb29f77d8bc6c2053956f80869928@haskell.org> #10999: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: res | Owner: Type: bug | Status: new 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: | Blocking: Related Tickets: #10045 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This is still broken in 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 17:23:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 17:23:28 -0000 Subject: [GHC] #10999: ghc: panic! (the 'impossible' happened) In-Reply-To: <042.e700677e826396486b3741ddf6f847b0@haskell.org> References: <042.e700677e826396486b3741ddf6f847b0@haskell.org> Message-ID: <057.574c52fe72f88a7f6c9def4a25a873b8@haskell.org> #10999: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: res | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10045 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: It appears that the fix for #10045 isn't entirely trivial to merge for 7.10.3. It looks like we'll need to punt on this. Sorry! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 17:25:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 17:25:13 -0000 Subject: [GHC] #11020: Make worker-wrapper transformation optional. In-Reply-To: <046.af56752a88fefa3cca6c1cc155378f63@haskell.org> References: <046.af56752a88fefa3cca6c1cc155378f63@haskell.org> Message-ID: <061.1260e0eac72827b52d2acf03be822902@haskell.org> #11020: Make worker-wrapper transformation optional. -------------------------------------+------------------------------------- Reporter: darchon | Owner: darchon Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1372 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"31704adc82c3a1e48ac05c51f02933fd996b642a/ghc" 31704ad/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="31704adc82c3a1e48ac05c51f02933fd996b642a" Make worker-wrapper optional Add -fworker-wrapper flag which enables the worker-wrapper transformation. It is implied by -O. The expected users of this flag, which includes myself, are GHC API users. In my Haskell-to-Hardware compiler, which uses the GHC API, I have seen no benifits of the worker-wrapper transformation. It does however induce longer compilation times. Further discussion can be seen here: https://mail.haskell.org/pipermail/ghc-devs/2015-October/010096.html Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1372 GHC Trac Issues: #11020 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 17:28:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 17:28:41 -0000 Subject: [GHC] #11008: Difficulties around inferring exotic contexts In-Reply-To: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> References: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> Message-ID: <062.ae49880b6271430389a11ba823cc57fd@haskell.org> #11008: Difficulties around inferring exotic contexts -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): If you want an opinion, and you propose something different than what currently happens, can you write the wiki page? Selfishly I don't want to wade through the long thread to find out what you are discussing. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 17:41:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 17:41:34 -0000 Subject: [GHC] #10970: Built in MIN_VERSION macro support In-Reply-To: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> References: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> Message-ID: <060.695205ce451bd5a98fb8407a18c3f990@haskell.org> #10970: Built in MIN_VERSION macro support -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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:D1349 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I think I may have unwittingly argued for this in the discussion on that mailing list thread, but I don't understand any more why it should be the case that we only create these macros for packages explicitly specified with `-package` or equivalent. Can't we treat the latest version of each package (or more generally, whichever one ghc(i) would pick by default for satisfying an import of one of its modules) as specified, since as I learned ghc's choice is not dependent on the contents of the source files? In its current form this patch doesn't do a lot to address developer- friendliness, since I might have to use a lot of `-package` flags to load a source file into ghci. Granted there might be other flags (like `-i`, or `-package` to pick versions of packages that are different from the ones ghc would pick by default) needed to load a source file from a Cabal package into ghci, but it seems like we could completely remove `MIN_VERSION_*` macros being a source of additional such flags. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 17:51:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 17:51:43 -0000 Subject: [GHC] #10970: Built in MIN_VERSION macro support In-Reply-To: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> References: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> Message-ID: <060.f97f3ef75908141bb48fe78916731269@haskell.org> #10970: Built in MIN_VERSION macro support -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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:D1349 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): The big problem is that, if you do this, you effectively force GHC to dump the ENTIRE package database into a giant header file, which defines each of the macros. The bigger the database, the bigger the file. I'm not fundamentally opposed, but this was the reason this draft didn't do it that way. I think Duncan also has some ulterior motives for not enabling it by default, mostly to get people to use proper setup dependencies on their Cabal files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 18:16:22 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 18:16:22 -0000 Subject: [GHC] #11017: ApiAnnotations: BooleanFormula is not properly Located In-Reply-To: <044.8a6c3bf330a4eb35f37df8711068c35c@haskell.org> References: <044.8a6c3bf330a4eb35f37df8711068c35c@haskell.org> Message-ID: <059.c63227479001c3e7bb01477ab06963e5@haskell.org> #11017: ApiAnnotations: BooleanFormula is not properly Located -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1384 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D1384 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 18:22:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 18:22:35 -0000 Subject: [GHC] #9637: Type level programming needs an error function In-Reply-To: <047.3309ef9af8755e67dc24602c9e6ec77f@haskell.org> References: <047.3309ef9af8755e67dc24602c9e6ec77f@haskell.org> Message-ID: <062.0cbdb1070f009f62dd2b0b0d1b57b8af@haskell.org> #9637: Type level programming needs an error function -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9180, #9636 | Differential Rev(s): Phab:D1236 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.1 Old description: > When doing type level programming you often need a way to report errors. > I suggest a closed type family called Error with special semantics. > It is kinded like this Error :: Symbol -> k1 -> k2 > > If this function has to be reduced during constraint solving it will > simply generate a type error with the given string and printing the type > as extra information (this kind can be generalized a lot if we want to). > > I've found that having this function gives more accurate and earlier > error messages. > > Wiki design page: [wiki:CustomTypeErros] New description: When doing type level programming you often need a way to report errors. I suggest a closed type family called Error with special semantics. It is kinded like this Error :: Symbol -> k1 -> k2 If this function has to be reduced during constraint solving it will simply generate a type error with the given string and printing the type as extra information (this kind can be generalized a lot if we want to). I've found that having this function gives more accurate and earlier error messages. Wiki design page: [wiki:Proposal/CustomTypeErrors] -- Comment: It sounds like this will make it in for 8.0.1 with an implementation by Iavor Diatchki. Thanks Iavor! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 18:28:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 18:28:20 -0000 Subject: [GHC] #11024: Fix strange parsing of BooleanFormula Message-ID: <049.1026878f17212bef28601e22c8ebf782@haskell.org> #11024: Fix strange parsing of BooleanFormula -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | 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: -------------------------------------+------------------------------------- Consider the following program. {{{ module Foo where class Meh a where foo :: a -> String foo1 :: a -> String foo2 :: a -> String {-# MINIMAL foo, foo1, foo2 #-} }}} The minimal pragma is parsed quite weirdly. {{{ (MinimalSig "{-# MINIMAL" (And [ (Var ({ test.hs:8:15-17 } (Unqual {OccName: foo}))), (And [ (Var ({ test.hs:8:20-23 } (Unqual {OccName: foo1}))), (Var ({ test.hs:8:26-29 } (Unqual {OccName: foo2})))])])))] {Bag(Located (HsBind RdrName)):}}} To be clear, it is parsed as `And [foo, [And [foo1, foo2]]` rather than `And [foo, foo1, foo2]`. Either the datatype should be change to be more like a binary tree or the parser should be changed to handle this properly. I think the second option would be easiest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 18:28:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 18:28:41 -0000 Subject: [GHC] #11024: Fix strange parsing of BooleanFormula In-Reply-To: <049.1026878f17212bef28601e22c8ebf782@haskell.org> References: <049.1026878f17212bef28601e22c8ebf782@haskell.org> Message-ID: <064.98183f2613735e46cc0b27f365f7b301@haskell.org> #11024: Fix strange parsing of BooleanFormula -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new 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: | -------------------------------------+------------------------------------- Description changed by mpickering: Old description: > Consider the following program. > > {{{ > module Foo where > > class Meh a where > foo :: a -> String > foo1 :: a -> String > foo2 :: a -> String > > {-# MINIMAL foo, foo1, foo2 #-} > }}} > > The minimal pragma is parsed quite weirdly. > > {{{ > (MinimalSig "{-# MINIMAL" > (And > [ > (Var > ({ test.hs:8:15-17 } > (Unqual {OccName: foo}))), > (And > [ > (Var > ({ test.hs:8:20-23 } > (Unqual {OccName: foo1}))), > (Var > ({ test.hs:8:26-29 } > (Unqual {OccName: foo2})))])])))] {Bag(Located (HsBind > RdrName)):}}} > > To be clear, it is parsed as `And [foo, [And [foo1, foo2]]` rather than > `And [foo, foo1, foo2]`. > > Either the datatype should be change to be more like a binary tree or the > parser should be changed to handle this properly. I think the second > option would be easiest. New description: Consider the following program. {{{ module Foo where class Meh a where foo :: a -> String foo1 :: a -> String foo2 :: a -> String {-# MINIMAL foo, foo1, foo2 #-} }}} The minimal pragma is parsed quite weirdly. {{{ (MinimalSig "{-# MINIMAL" (And [ (Var ({ test.hs:8:15-17 } (Unqual {OccName: foo}))), (And [ (Var ({ test.hs:8:20-23 } (Unqual {OccName: foo1}))), (Var ({ test.hs:8:26-29 } (Unqual {OccName: foo2})))])])))] {Bag(Located (HsBind RdrName)): }}} To be clear, it is parsed as `And [foo, [And [foo1, foo2]]` rather than `And [foo, foo1, foo2]`. Either the datatype should be change to be more like a binary tree or the parser should be changed to handle this properly. I think the second option would be easiest. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 18:30:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 18:30:48 -0000 Subject: [GHC] #11025: Per-database shadowing Message-ID: <045.d3e5eba6f5850281f113a1da5a4f0541@haskell.org> #11025: Per-database shadowing -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Package | Version: 7.11 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: -------------------------------------+------------------------------------- In `5b0191f74ab05b187f81ea037623338a615b1619`, I eliminated shadowing, on the justification that we should never pick the same component ID (previously installed package ID) for two distinct packages unless the ABIs of the packages were the same, so we could just globally assume that component IDs are unique. However, I've recently come across some cases where we can't easily actually make this be the case. Here are a few of them: 1. GHC's build system assumes that the ghc package will always be a library name of the form HSghc-7.11.a (i.e. that its component ID is ghc-7.11). It's a bit nontrivial to change this assumption, because there are stage1 shenanigans which are rewriting the version number to one without the date. But obviously if you are bootstrapping GHC with itself, the component ID of the GHC you are building will conflict with the component ID of the host GHC. 2. A similar situation exist for bootstrapping packages. When compiling GHC, we want to pick fairly deterministic component IDs for it in order to avoid needless rebuilding. But then if you turn around and use one of these builds to bootstrap GHC, if you use the same deterministic scheme you will end up with conflicting component IDs. 3. More generally, if you are building a package which is already in the global database (and thus not easily removable), it is sometimes VERY CONVENIENT to be able to pick whatever component ID you want, even if it's in the global database. (1) and (2) are cases of this. So I think what we want to do is bring back shadowing, but have it operate on a PER-DATABASE basis. For example, if we have the following databases: {{{ pkg.conf.1 foo-0.1-XXX bar-0.2-YYY (depends on foo-0.1-XXX) pkg.conf.2 foo-0.1-XXX baz-0.3-ZZZ (depends on foo-0.1-XXX) }}} If we stack pkg.conf.2 on top of pkg.conf.1, we invalidate foo-0.1-XXX FROM pkg.conf.1 (which simply means any packages from pkg.conf.1 which refer to it.) It also occurs to me that we should also be recording the ABIs of packages we depend on, to ensure consistency. Consider: {{{ pkg.conf.1 foo-0.1-XXX (abi is AAA) pkg.conf.2 foo-0.1-XXX (abi is BBB) pkg.conf.3 bar-0.1-YYY (depends on foo-0.1-XXX) }}} Which is the correct database to use `pkg.conf.3` with? We have no way of telling today! Sure, `pkg.conf.3` is incomplete, but this is a supported mode of operation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 20:30:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 20:30:33 -0000 Subject: [GHC] #10999: ghc: panic! (the 'impossible' happened) In-Reply-To: <042.e700677e826396486b3741ddf6f847b0@haskell.org> References: <042.e700677e826396486b3741ddf6f847b0@haskell.org> Message-ID: <057.637bf79dfab756f19a4907a034ed1525@haskell.org> #10999: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: res | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10045 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"7c2ab6fb41464ace21fcae885ae8dc5354014a25/ghc" 7c2ab6fb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7c2ab6fb41464ace21fcae885ae8dc5354014a25" Testsuite: accept output for T10999 (#10999) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 20:42:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 20:42:24 -0000 Subject: [GHC] #10667: '-g' option generates invalid assembly when '*/*' operator is used In-Reply-To: <045.7de7e3e8915f886ced608adea09f7f67@haskell.org> References: <045.7de7e3e8915f886ced608adea09f7f67@haskell.org> Message-ID: <060.f01af3487c8de8147b1dd555383e805a@haskell.org> #10667: '-g' option generates invalid assembly when '*/*' operator is used -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2-rc2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mjmrotek): Similar thing happens when compiling HMatrix with -g: {{{ [16 of 33] Compiling Numeric.LinearAlgebra.Algorithms ( src/Numeric/LinearAlgebra/Algorithms.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Numeric/LinearAlgebra/Algorithms.o ) /tmp/ghc31909_0/ghc_110.s: Assembler messages: /tmp/ghc31909_0/ghc_110.s:60657:0: Error: bad expression /tmp/ghc31909_0/ghc_110.s:60664:0: Error: bad expression ... etc }}} and in the offending .s file: {{{ 60657: .loc 3 805 33 /* expGolub.*/ */ 60664: .loc 3 805 33 /* expGolub.*/ */ ... etc }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 21:17:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 21:17:38 -0000 Subject: [GHC] #11024: Fix strange parsing of BooleanFormula In-Reply-To: <049.1026878f17212bef28601e22c8ebf782@haskell.org> References: <049.1026878f17212bef28601e22c8ebf782@haskell.org> Message-ID: <064.4c7aa80b4ca1314790c3ce4e434fad55@haskell.org> #11024: Fix strange parsing of BooleanFormula -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new 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: | -------------------------------------+------------------------------------- Description changed by mpickering: Old description: > Consider the following program. > > {{{ > module Foo where > > class Meh a where > foo :: a -> String > foo1 :: a -> String > foo2 :: a -> String > > {-# MINIMAL foo, foo1, foo2 #-} > }}} > > The minimal pragma is parsed quite weirdly. > > {{{ > (MinimalSig "{-# MINIMAL" > (And > [ > (Var > ({ test.hs:8:15-17 } > (Unqual {OccName: foo}))), > (And > [ > (Var > ({ test.hs:8:20-23 } > (Unqual {OccName: foo1}))), > (Var > ({ test.hs:8:26-29 } > (Unqual {OccName: foo2})))])])))] {Bag(Located (HsBind > RdrName)): > }}} > > To be clear, it is parsed as `And [foo, [And [foo1, foo2]]` rather than > `And [foo, foo1, foo2]`. > > Either the datatype should be change to be more like a binary tree or the > parser should be changed to handle this properly. I think the second > option would be easiest. New description: Consider the following program. {{{ module Foo where class Meh a where foo :: a -> String foo1 :: a -> String foo2 :: a -> String {-# MINIMAL foo, foo1, foo2 #-} }}} The minimal pragma is parsed quite weirdly. {{{ (MinimalSig "{-# MINIMAL" (And [ (Var ({ test.hs:8:15-17 } (Unqual {OccName: foo}))), (And [ (Var ({ test.hs:8:20-23 } (Unqual {OccName: foo1}))), (Var ({ test.hs:8:26-29 } (Unqual {OccName: foo2})))])])))] {Bag(Located (HsBind RdrName)): }}} To be clear, it is parsed as `And [foo, And [foo1, foo2]]` rather than `And [foo, foo1, foo2]`. Either the datatype should be change to be more like a binary tree or the parser should be changed to handle this properly. I think the second option would be easiest. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 27 23:05:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Oct 2015 23:05:05 -0000 Subject: [GHC] #10667: '-g' option generates invalid assembly when '*/*' operator is used In-Reply-To: <045.7de7e3e8915f886ced608adea09f7f67@haskell.org> References: <045.7de7e3e8915f886ced608adea09f7f67@haskell.org> Message-ID: <060.472b2ac5befdcbcda280379bd18ee63d@haskell.org> #10667: '-g' option generates invalid assembly when '*/*' operator is used -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1386 Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * status: new => patch * differential: => Phab:D1386 * architecture: Unknown/Multiple => x86_64 (amd64) * milestone: => 7.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 06:06:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 06:06:08 -0000 Subject: [GHC] #11025: Per-database shadowing In-Reply-To: <045.d3e5eba6f5850281f113a1da5a4f0541@haskell.org> References: <045.d3e5eba6f5850281f113a1da5a4f0541@haskell.org> Message-ID: <060.86484b17c7cb2065fee26429756722ae@haskell.org> #11025: Per-database shadowing -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Package system | Version: 7.11 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:D1385 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * differential: => Phab:D1385 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 07:29:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 07:29:13 -0000 Subject: [GHC] #11026: Bump `base` version to 4.9.0.0 Message-ID: <042.f747c2b78427a306bca14268108fcb46@haskell.org> #11026: Bump `base` version to 4.9.0.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: | Version: libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 08:56:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 08:56:21 -0000 Subject: [GHC] #11027: GHC API panic (evaluated the place holder for a PostTcType) Message-ID: <044.163606e1ba38af8685764930a428d14a@haskell.org> #11027: GHC API panic (evaluated the place holder for a PostTcType) -------------------------------------+------------------------------------- Reporter: rubik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.4 Keywords: undefined, | Operating System: Linux place holder, posttctype | Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The same code that works for GHC 7.10.2 blows up on GHC 7.8.4, with errors like {{{ test/ArgonSpec.hs:104: (best-effort) 6) Argon.analyze accounts for && operator uncaught exception: GhcException (argon-test: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): fixity Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ) test/ArgonSpec.hs:106: (best-effort) 7) Argon.analyze counts everything in a real example uncaught exception: GhcException (argon-test: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): Evaluated the place holder for a PostTcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ) }}} The responsible module is [https://github.com/rubik/argon/blob/master/src/Argon/Visitor.hs] and in particular (I think): {{{ visitExp :: Exp -> Int visitExp (GHC.HsIf {}) = 1 visitExp (GHC.HsMultiIf _ alts) = length alts - 1 visitExp (GHC.HsLamCase _ alts) = length (GHC.mg_alts alts) - 1 visitExp (GHC.HsCase _ alts) = length (GHC.mg_alts alts) - 1 visitExp _ = 0 visitOp :: Exp -> Int visitOp (GHC.OpApp _ (GHC.L _ (GHC.HsVar op)) _ _) = case getName op of "||" -> 1 "&&" -> 1 _ -> 0 visitOp _ = 0 }}} somehow, even if I use wildcards, the first arguments of the type constructors gets evaluated and since it's undefined GHC crashes. What am I supposed to do? The documentation does not say anything on the matter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 08:57:20 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 08:57:20 -0000 Subject: [GHC] #11027: GHC API panic (evaluated the place holder for a PostTcType) In-Reply-To: <044.163606e1ba38af8685764930a428d14a@haskell.org> References: <044.163606e1ba38af8685764930a428d14a@haskell.org> Message-ID: <059.0e39d179782226fddab3c20eb6011327@haskell.org> #11027: GHC API panic (evaluated the place holder for a PostTcType) -------------------------------------+------------------------------------- Reporter: rubik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.4 Resolution: | Keywords: undefined, | place holder, posttctype 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 rubik): * cc: simonpj (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 09:07:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 09:07:18 -0000 Subject: [GHC] #11027: GHC API panic (evaluated the place holder for a PostTcType) In-Reply-To: <044.163606e1ba38af8685764930a428d14a@haskell.org> References: <044.163606e1ba38af8685764930a428d14a@haskell.org> Message-ID: <059.d0f834151ed3fb822ac357db32ebbbd8@haskell.org> #11027: GHC API panic (evaluated the place holder for a PostTcType) -------------------------------------+------------------------------------- Reporter: rubik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.4 Resolution: | Keywords: undefined, | place holder, posttctype 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 simonpj): I'd ask Alan Zimmerman. Certainly if you write a wildcard in a pattern match GHC won't evaluate that field in a pattern match: {{{ f (C _ x) = ... }}} the `_` argument of `C` will not be evaluated by `f`. (It might be evaluated for some other reason.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 09:13:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 09:13:33 -0000 Subject: [GHC] #11027: GHC API panic (evaluated the place holder for a PostTcType) In-Reply-To: <044.163606e1ba38af8685764930a428d14a@haskell.org> References: <044.163606e1ba38af8685764930a428d14a@haskell.org> Message-ID: <059.1ce9ebf0a1601ebe0a8f68f39be5a77a@haskell.org> #11027: GHC API panic (evaluated the place holder for a PostTcType) -------------------------------------+------------------------------------- Reporter: rubik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.4 Resolution: | Keywords: undefined, | place holder, posttctype Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by rubik: Old description: > The same code that works for GHC 7.10.2 blows up on GHC 7.8.4, with > errors like > {{{ > test/ArgonSpec.hs:104: (best-effort) > 6) Argon.analyze accounts for && operator > uncaught exception: GhcException (argon-test: panic! (the > 'impossible' happened) > (GHC version 7.8.4 for x86_64-unknown-linux): > fixity > > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > ) > > test/ArgonSpec.hs:106: (best-effort) > 7) Argon.analyze counts everything in a real example > uncaught exception: GhcException (argon-test: panic! (the > 'impossible' happened) > (GHC version 7.8.4 for x86_64-unknown-linux): > Evaluated the place holder for a PostTcType > > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > ) > }}} > > The responsible module is > [https://github.com/rubik/argon/blob/master/src/Argon/Visitor.hs] > and in particular (I think): > {{{ > visitExp :: Exp -> Int > visitExp (GHC.HsIf {}) = 1 > visitExp (GHC.HsMultiIf _ alts) = length alts - 1 > visitExp (GHC.HsLamCase _ alts) = length (GHC.mg_alts alts) - 1 > visitExp (GHC.HsCase _ alts) = length (GHC.mg_alts alts) - 1 > visitExp _ = 0 > > visitOp :: Exp -> Int > visitOp (GHC.OpApp _ (GHC.L _ (GHC.HsVar op)) _ _) = > case getName op of > "||" -> 1 > "&&" -> 1 > _ -> 0 > visitOp _ = 0 > }}} > somehow, even if I use wildcards, the first arguments of the type > constructors gets evaluated and since it's undefined GHC crashes. > What am I supposed to do? > The documentation does not say anything on the matter. New description: The same code that works for GHC 7.10.2 blows up on GHC 7.8.4, with errors like {{{ test/ArgonSpec.hs:104: (best-effort) 6) Argon.analyze accounts for && operator uncaught exception: GhcException (argon-test: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): fixity Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ) test/ArgonSpec.hs:106: (best-effort) 7) Argon.analyze counts everything in a real example uncaught exception: GhcException (argon-test: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): Evaluated the place holder for a PostTcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ) }}} The responsible module is [https://github.com/rubik/argon/blob/ghc-7.8/src/Argon/Visitor.hs] and in particular (I think): {{{ visitExp :: Exp -> Int visitExp (GHC.HsIf {}) = 1 visitExp (GHC.HsMultiIf _ alts) = length alts - 1 visitExp (GHC.HsLamCase _ alts) = length (GHC.mg_alts alts) - 1 visitExp (GHC.HsCase _ alts) = length (GHC.mg_alts alts) - 1 visitExp _ = 0 visitOp :: Exp -> Int visitOp (GHC.OpApp _ (GHC.L _ (GHC.HsVar op)) _ _) = case getName op of "||" -> 1 "&&" -> 1 _ -> 0 visitOp _ = 0 }}} somehow, even if I use wildcards, the first arguments of the type constructors gets evaluated and since it's undefined GHC crashes. What am I supposed to do? The documentation does not say anything on the matter. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 09:13:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 09:13:53 -0000 Subject: [GHC] #11027: GHC API panic (evaluated the place holder for a PostTcType) In-Reply-To: <044.163606e1ba38af8685764930a428d14a@haskell.org> References: <044.163606e1ba38af8685764930a428d14a@haskell.org> Message-ID: <059.c85600d284b750582c847872e00aa8e6@haskell.org> #11027: GHC API panic (evaluated the place holder for a PostTcType) -------------------------------------+------------------------------------- Reporter: rubik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.4 Resolution: | Keywords: undefined, | place holder, posttctype 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 rubik): * cc: alanz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 09:18:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 09:18:53 -0000 Subject: [GHC] #11028: Refactor ConDecl Message-ID: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `ConDecl` type in `HsDecls` is an uneasy compromise. For the most part, `HsSyn` directly reflects the syntax written by the programmer; and that gives just the right "pegs" on which to hang Alan's [wiki:ApiAnnotations API annotations]. But `ConDecl` doesn't properly reflect the syntax of Haskell-98 and GADT-style data type declarations. To be concrete, here's a draft new data type {{{ data ConDecl name | ConDeclGADT { con_names :: [Located name] , con_type :: LHsSigType name -- The type after the ?::? , con_doc :: Maybe LHsDocString , con_old_rec :: Bool } | ConDeclH98 { con_name :: Located name , con_implict :: HsImplicitBndrs () -- ^ Implicit binders, added by renamer , con_qvars :: Maybe [LHsTyVarBndr name] -- User-written foralls (if any) , con_cxt :: Maybe (LHsContext name) -- ^ User-written context (if any) , con_details :: HsConDeclDetails name -- ^ Arguments , con_doc :: Maybe LHsDocString -- ^ A possible Haddock comment. } deriving (Typeable) }}} Note that * For GADTs, just keep a type. That's what the user writes. (NB: `HsType` can represent records on the LHS of an arrow: `{ x:Int,y:Bool } -> T` * `con_qvars` and `con_cxt` are both `Maybe` because they are both optional (the `forall` and the context of an existential data type) * The `con_old_rec` is a warning thing for GADTs (see current source code) This ticket is just to track the thought and invite feedback. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 09:57:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 09:57:02 -0000 Subject: [GHC] #11027: GHC API panic (evaluated the place holder for a PostTcType) In-Reply-To: <044.163606e1ba38af8685764930a428d14a@haskell.org> References: <044.163606e1ba38af8685764930a428d14a@haskell.org> Message-ID: <059.91f737d12a01bcf66f55480b8a13e99a@haskell.org> #11027: GHC API panic (evaluated the place holder for a PostTcType) -------------------------------------+------------------------------------- Reporter: rubik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.4 Resolution: | Keywords: undefined, | place holder, posttctype 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 mpickering): I think the problem is the generic traversal on line 27. {{{ getBinds :: (Data from, Typeable from) => from -> [Function] getBinds = everything (++) $ mkQ [] visit where visit fun@(GHC.FunBind {}) = [fun] visit _ = [] }}} It is not safe to do generic traversals on the GHC 7.8 AST due to the reason you encountered! There are landmines. You can use ghc-syb-utils if you want to also support 7.8. In future, triggering panics when using the API isn't usually a bug in GHC. Alan and I will be happy to help you on #haskell-refactorer if you have any more questions. https://hackage.haskell.org/package/ghc-syb-utils-0.2.3/docs/GHC-SYB- Utils.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 10:33:48 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 10:33:48 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.75c47c3a45d47b0e0dc694715135c323@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"04b0a73a2a418e1ca9c282ab3f2b4fe216911fdd/ghc" 04b0a73/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="04b0a73a2a418e1ca9c282ab3f2b4fe216911fdd" Pattern synonyms: swap provided/required This patch swaps the order of provided and required constraints in a pattern signature, so it now goes pattern P :: req => prov => t1 -> ... tn -> res_ty See the long discussion in Trac #10928. I think I have found all the places, but I could have missed something particularly in comments. There is a Haddock changes; so a submodule update. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 10:34:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 10:34:27 -0000 Subject: [GHC] #11027: GHC API panic (evaluated the place holder for a PostTcType) In-Reply-To: <044.163606e1ba38af8685764930a428d14a@haskell.org> References: <044.163606e1ba38af8685764930a428d14a@haskell.org> Message-ID: <059.d976fd164799b562f7234e82569a50f6@haskell.org> #11027: GHC API panic (evaluated the place holder for a PostTcType) -------------------------------------+------------------------------------- Reporter: rubik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.4 Resolution: | Keywords: undefined, | place holder, posttctype 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 rubik): Wonderful, thank you! Using {{{everythingStaged}}} solves the problem. I'll check out #haskell-refactorer. In the future I won't open bugs for these things. But being the first time it happened, and because the error message was telling me to file a bug, I opened a ticket. Now I know better :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 10:35:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 10:35:02 -0000 Subject: [GHC] #11027: GHC API panic (evaluated the place holder for a PostTcType) In-Reply-To: <044.163606e1ba38af8685764930a428d14a@haskell.org> References: <044.163606e1ba38af8685764930a428d14a@haskell.org> Message-ID: <059.1ef9315e4dfe5927fb9cfa8c70c89bc6@haskell.org> #11027: GHC API panic (evaluated the place holder for a PostTcType) -------------------------------------+------------------------------------- Reporter: rubik | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHC API | Version: 7.8.4 Resolution: fixed | Keywords: undefined, | place holder, posttctype 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 rubik): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 10:35:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 10:35:35 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.79867ddefc76369304c997cbdeac4a4e@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | 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 simonpj): * status: new => closed * resolution: => fixed Comment: OK I've done the provided/required swap. Please look out for any inconsistencies where I've missed something Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 10:36:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 10:36:14 -0000 Subject: [GHC] #11010: Untouchable type, pattern synonyms In-Reply-To: <051.ac3dbe8ba403159d004fffbd87da4f52@haskell.org> References: <051.ac3dbe8ba403159d004fffbd87da4f52@haskell.org> Message-ID: <066.b46dda9fedd472bf2c5f66098e35c248@haskell.org> #11010: Untouchable type, pattern synonyms ---------------------------------+------------------------------ Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+------------------------------ Comment (by simonpj): In [changeset:"04b0a73a2a418e1ca9c282ab3f2b4fe216911fdd/ghc" 04b0a73/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="04b0a73a2a418e1ca9c282ab3f2b4fe216911fdd" Pattern synonyms: swap provided/required This patch swaps the order of provided and required constraints in a pattern signature, so it now goes pattern P :: req => prov => t1 -> ... tn -> res_ty See the long discussion in Trac #10928. I think I have found all the places, but I could have missed something particularly in comments. There is a Haddock changes; so a submodule update. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 10:43:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 10:43:52 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.6a087c5d0b724883632046ecaa33cd23@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | 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 mpickering): Simon, should you maybe change the parser so that prov/req refer to the right things in parsing. I admit I had a much simpler patch in mind which just made the change in the parser and pretty printer! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 11:21:07 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 11:21:07 -0000 Subject: [GHC] #11029: Performance loss due to eta expansion Message-ID: <051.577c9e6d06531141cacd9cd4438f8d07@haskell.org> #11029: Performance loss due to eta expansion -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- Given the attached file, at both {{{-O2}}} and {{{-O0}}}, GHC translates the function: {{{#!hs test1 [1,2,3,4,5,6,7,8,9,10] = \x -> x test1 _ = \x -> negate x }}} To be equivalent to: {{{#!hs test0 [1,2,3,4,5,6,7,8,9,10] x = x test0 _ x = negate x }}} When applied in a loop with something like: {{{#!hs map (test1 [1..]) [1..1000] }}} The eta-expanded variant is 3x slower. Adding a trace breaks that transformation, and then the code goes 3x faster. Specifically: {noformat} test2 [1,2,3,4,5,6,7,8,9,10] = \x -> x test2 _ = trace "here" $ \x -> negate x {noformat} Timings, as reported by Criterion under O2 with GHC 7.10.2, are: {{{ benchmarking test0 = 40.99 ns (40.96 ns .. 41.02 ns) benchmarking test1 = 41.09 ns (41.06 ns .. 41.14 ns) benchmarking test2 = 17.74 ns (17.68 ns .. 17.81 ns) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 11:21:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 11:21:38 -0000 Subject: [GHC] #11029: Performance loss due to eta expansion In-Reply-To: <051.577c9e6d06531141cacd9cd4438f8d07@haskell.org> References: <051.577c9e6d06531141cacd9cd4438f8d07@haskell.org> Message-ID: <066.e7c123f661758a0907505ed9257360f8@haskell.org> #11029: Performance loss due to eta expansion -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by NeilMitchell): * Attachment "Main.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 11:22:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 11:22:51 -0000 Subject: [GHC] #11029: Performance loss due to eta expansion In-Reply-To: <051.577c9e6d06531141cacd9cd4438f8d07@haskell.org> References: <051.577c9e6d06531141cacd9cd4438f8d07@haskell.org> Message-ID: <066.fa3f8e3e2fe853c81345523d5fe5f708@haskell.org> #11029: Performance loss due to eta expansion -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): Wiki Page: | -------------------------------------+------------------------------------- Description changed by NeilMitchell: Old description: > Given the attached file, at both {{{-O2}}} and {{{-O0}}}, GHC translates > the function: > > {{{#!hs > test1 [1,2,3,4,5,6,7,8,9,10] = \x -> x > test1 _ = \x -> negate x > }}} > > To be equivalent to: > > {{{#!hs > test0 [1,2,3,4,5,6,7,8,9,10] x = x > test0 _ x = negate x > }}} > > When applied in a loop with something like: > > {{{#!hs > map (test1 [1..]) [1..1000] > }}} > > The eta-expanded variant is 3x slower. Adding a trace breaks that > transformation, and then the code goes 3x faster. Specifically: > > {noformat} > test2 [1,2,3,4,5,6,7,8,9,10] = \x -> x > test2 _ = trace "here" $ \x -> negate x > {noformat} > > Timings, as reported by Criterion under O2 with GHC 7.10.2, are: > > {{{ > benchmarking test0 = 40.99 ns (40.96 ns .. 41.02 ns) > benchmarking test1 = 41.09 ns (41.06 ns .. 41.14 ns) > benchmarking test2 = 17.74 ns (17.68 ns .. 17.81 ns) > }}} New description: Given the attached file, at both {{{-O2}}} and {{{-O0}}}, GHC translates the function: {{{#!hs test1 [1,2,3,4,5,6,7,8,9,10] = \x -> x test1 _ = \x -> negate x }}} To be equivalent to: {{{#!hs test0 [1,2,3,4,5,6,7,8,9,10] x = x test0 _ x = negate x }}} When applied in a loop with something like: {{{#!hs map (test1 [1..]) [1..1000] }}} The eta-expanded variant is 3x slower. Adding a trace breaks that transformation, and then the code goes 3x faster. Specifically: {{{#!hs test2 [1,2,3,4,5,6,7,8,9,10] = \x -> x test2 _ = trace "here" $ \x -> negate x }}} Timings, as reported by Criterion under O2 with GHC 7.10.2, are: {{{ benchmarking test0 = 40.99 ns (40.96 ns .. 41.02 ns) benchmarking test1 = 41.09 ns (41.06 ns .. 41.14 ns) benchmarking test2 = 17.74 ns (17.68 ns .. 17.81 ns) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 12:08:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 12:08:31 -0000 Subject: [GHC] #10967: Release a new stm package on Hackage In-Reply-To: <048.5f8e847ed74659a561fb4c92223590be@haskell.org> References: <048.5f8e847ed74659a561fb4c92223590be@haskell.org> Message-ID: <063.81112645dc43245c75b9334e5eb6393a@haskell.org> #10967: Release a new stm package on Hackage -------------------------------------+------------------------------------- Reporter: svenpanne | Owner: hvr Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: libraries | Version: (other) | 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: | -------------------------------------+------------------------------------- Changes (by svenpanne): * priority: normal => high Comment: Any ETA for a new stm release, things are still failing, see e.g. https ://travis-ci.org/haskell-opengl/StateVar/jobs/76990492. http://packdeps.haskellers.com/reverse/stm tells me that there are 452 reverse dependencies of stm, so I think this should have high priority (at least, if not highest). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 12:17:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 12:17:43 -0000 Subject: [GHC] #11010: Untouchable type, pattern synonyms In-Reply-To: <051.ac3dbe8ba403159d004fffbd87da4f52@haskell.org> References: <051.ac3dbe8ba403159d004fffbd87da4f52@haskell.org> Message-ID: <066.c739fad20789e77434067dc52645b01d@haskell.org> #11010: Untouchable type, pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: | patsyn/should_fail/T11010 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => patsyn/should_fail/T11010 * status: new => closed * resolution: => fixed Comment: Now we get {{{ T11010.hs:8:1: error: The 'required' context ?a ~ Int? mentions existential type variable ?a? T11010.hs:16:1: error: The 'required' context ?a ~ Int? mentions existential type variable ?a? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 12:20:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 12:20:52 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.e30aaed888586b3dbf485a75f3a4c5c8@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | 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 simonpj): Ah, you mean {{{ {% do { let (flag, qtvs, req, prov, ty) = snd $ unLoc $4 ; let sig = PatSynSig $2 (flag, mkHsQTvs qtvs) req prov ty }}} Ie just variable naming. Yes, good point I'll swap the names. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 12:31:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 12:31:11 -0000 Subject: [GHC] #11029: Performance loss due to eta expansion In-Reply-To: <051.577c9e6d06531141cacd9cd4438f8d07@haskell.org> References: <051.577c9e6d06531141cacd9cd4438f8d07@haskell.org> Message-ID: <066.f64038c54ddf771f5f7b2dcfc32c5eb1@haskell.org> #11029: Performance loss due to eta expansion -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > Given the attached file, at both -O2 and -O0 does this imply that it is not happening with `-O` (which I thought is the most common optimization level)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 12:34:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 12:34:10 -0000 Subject: [GHC] #11029: Performance loss due to eta expansion In-Reply-To: <051.577c9e6d06531141cacd9cd4438f8d07@haskell.org> References: <051.577c9e6d06531141cacd9cd4438f8d07@haskell.org> Message-ID: <066.383e6db46a5db573ae9eb1ef685a53e6@haskell.org> #11029: Performance loss due to eta expansion -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I have a large collection of eta-related tickets. See "Arity" in [wiki:Status/SLPJ-Tickets]. This one is awkward. If we have {{{ f True = \x -> .. f False = \y -> .. }}} and `f` is usually called applied to two arguments, it's really much better to eta-expand. But if we have `map (f v) xs` it probably isn't better to eta-expand. Generally, GHC will eta expand if the only duplication is pattern matching; but as you point out that is not always right. Currently there is no notion of how ''much'' pattern matching is duplicated, and that might not be hard to add. Another avenue would be to give programmers a way to control the behaviour, along the lines of the existing `oneShot` [https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc- prim-0.4.0.0/GHC-Magic.html docs]. I wish I knew a really good way to deal with this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 12:46:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 12:46:10 -0000 Subject: [GHC] #11029: Performance loss due to eta expansion In-Reply-To: <051.577c9e6d06531141cacd9cd4438f8d07@haskell.org> References: <051.577c9e6d06531141cacd9cd4438f8d07@haskell.org> Message-ID: <066.3df6894f12cac36be02ce7e5972f2f91@haskell.org> #11029: Performance loss due to eta expansion -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): JFTR, the relevant code is this bit in `CoreArity.lhs`: {{{#!hs arityType env (Case scrut _ _ alts) | exprIsBottom scrut || null alts = ABot 0 -- Do not eta expand -- See Note [Dealing with bottom (1)] | otherwise = case alts_type of ABot n | n>0 -> ATop [] -- Don't eta expand | otherwise -> ABot 0 -- if RHS is bottomming -- See Note [Dealing with bottom (2)] ATop as | not (ae_ped_bot env) -- See Note [Dealing with bottom (3)] , ae_cheap_fn env scrut Nothing -> ATop as | exprOkForSpeculation scrut -> ATop as | otherwise -> ATop (takeWhile isOneShotInfo as) where alts_type = foldr1 andArityType [arityType env rhs | (_,_,rhs) <- alts] }}} and you can prevent this behaviour with `-fpedantic-bottoms`. And it looks that I made this eta-expansion more aggressive in changeset:2931d19e90d2366f2ce308d65a36333336ca6059 when trying to fix #2915. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 13:00:37 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 13:00:37 -0000 Subject: [GHC] #11028: Refactor ConDecl In-Reply-To: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> References: <046.dc4f3ceb79e407eec299d5771faf5ae4@haskell.org> Message-ID: <061.360a53aa5f26b3824b5953aae20564b0@haskell.org> #11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I have no objections. It would be nice to somehow capture the fact that all constructors are either one or the other. But that might be annoying to code with. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 13:07:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 13:07:33 -0000 Subject: [GHC] #11030: D757 (emit Typeable at type definition site) regresses T3294 max_bytes_used by factor of two Message-ID: <046.dcbfe5b30aed7ce500ba8edfc26b6702@haskell.org> #11030: D757 (emit Typeable at type definition site) regresses T3294 max_bytes_used by factor of two -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: T3294 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I noticed that D757 caused max_bytes_allocated to go from 45MBytes to 96MBytes while updating the testsuite. This may be expected but I want to ensure I look into this since the test defines only one type (albeit with many fields) and a `Show` instance so we wouldn't necessarily expect this test to regress by this amount. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 13:08:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 13:08:11 -0000 Subject: [GHC] #11029: Performance loss due to eta expansion In-Reply-To: <051.577c9e6d06531141cacd9cd4438f8d07@haskell.org> References: <051.577c9e6d06531141cacd9cd4438f8d07@haskell.org> Message-ID: <066.34eefd58956b8e17c195139a2acee715@haskell.org> #11029: Performance loss due to eta expansion -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): @nomeata: I confirm {{{-O1}}} has exactly the same behaviour. As for fixes, my first thought is that eta-expansion is valuable even if you are duplicating more than patterns, and sometimes duplicating patterns is too much. My hypothetical solution would be: * Make each function have multiple versions at different arities, so you'd generate core for {{{test1/1}}} and {{{test1/2}}}. (The functions might refer to each other, or not be generated if it didn't seem valuable, to keep the size down.) * Have the call site select between {{{test1/1}}} and {{{test1/2}}} based on the number of arguments available. * After that, you might want to change the desugarer, so that the two functions above produce the same Core. Pattern matching on the first argument could happen after the first argument is supplied, before the second argument. It would be nice if the 2 argument version still went 3x faster when used partially applied. Trying to figure out the arity of a function at it's definition site seems difficult, and can never be optimal for all uses. For context, I got lead down this path starting at view patterns, which have similar considerations but with arbitrarily expensive "patterns", which GHC never duplicates: http://neilmitchell.blogspot.co.uk/2015/10 /viewpatterns-and-lambda-expansion.html. In Shake someone submitted a patch to refactor and move a lambda to the left of an {{{=}}}, which somewhat surprisingly can be much slower. Adding a {{{oneShot}}} equivalent would be very useful, to make such optimisations explicit and robust. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 13:08:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 13:08:23 -0000 Subject: [GHC] #11029: Performance loss due to eta expansion In-Reply-To: <051.577c9e6d06531141cacd9cd4438f8d07@haskell.org> References: <051.577c9e6d06531141cacd9cd4438f8d07@haskell.org> Message-ID: <066.cf6910716305fb479dc0c7f12a2025d8@haskell.org> #11029: Performance loss due to eta expansion -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by NeilMitchell): * cc: ndmitchell@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 13:11:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 13:11:57 -0000 Subject: [GHC] #11029: Performance loss due to eta expansion In-Reply-To: <051.577c9e6d06531141cacd9cd4438f8d07@haskell.org> References: <051.577c9e6d06531141cacd9cd4438f8d07@haskell.org> Message-ID: <066.ac20bf40badf746bafb63fadfdd2163a@haskell.org> #11029: Performance loss due to eta expansion -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Code duplication is an easy way out of many optimization problems; unfortunately, you easily get into exponential blow ups. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 13:25:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 13:25:18 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.a5cb703bb7eaa7de039b7deae91b9d0b@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | 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 simonpj): BTW I have not implemented comment:26: > While we're changing the parser, we should make sure that explicit quantification is allowed But someone else is welcome to! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 14:08:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 14:08:23 -0000 Subject: [GHC] #11017: ApiAnnotations: BooleanFormula is not properly Located In-Reply-To: <044.8a6c3bf330a4eb35f37df8711068c35c@haskell.org> References: <044.8a6c3bf330a4eb35f37df8711068c35c@haskell.org> Message-ID: <059.1edf4b8fe01521a5b17deb858f49732e@haskell.org> #11017: ApiAnnotations: BooleanFormula is not properly Located -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1384 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 15:51:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 15:51:57 -0000 Subject: [GHC] #11031: Record Pattern Synonym Cleanup Message-ID: <049.41e89b2b13b1b76485458be6dd918ffd@haskell.org> #11031: Record Pattern Synonym Cleanup -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- Ben comments that there are some loose ends with record pattern synonyms. * It's still not clear to me that the free variables produced in rnPatSynBind are correct * Perhaps in the future we want to refactor tc_single to use a function which extends the typechecking environment instead of using setGblEnv * @mpickering's suggested refactoring of RecSelId to RecSelId (Either PatSyn TyCon) Bool described in the comment in TcExpr.hs * There is a TODO in tc_patsyn_finish which should either be clarified so it can be considered actionable, removed, or just fixed The comment from TcExpr was: > I tried to refactor RecSelId to RecSelId [DataCon] Bool but this causes some pain when it comes to the interface files. Next try it is something like RecSelId (Either PatSyn TyCon) Bool with the aim for something better in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 16:13:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 16:13:02 -0000 Subject: [GHC] #11031: Record Pattern Synonym Cleanup In-Reply-To: <049.41e89b2b13b1b76485458be6dd918ffd@haskell.org> References: <049.41e89b2b13b1b76485458be6dd918ffd@haskell.org> Message-ID: <064.3a1c6563df4b3a32d6ba14ee07e6a1f0@haskell.org> #11031: Record Pattern Synonym Cleanup -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.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: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Ben comments that there are some loose ends with record pattern synonyms. > > * It's still not clear to me that the free variables produced in > rnPatSynBind are correct > * Perhaps in the future we want to refactor tc_single to use a function > which extends the typechecking environment instead of using setGblEnv > * @mpickering's suggested refactoring of RecSelId to RecSelId (Either > PatSyn TyCon) Bool described in the comment in TcExpr.hs > * There is a TODO in tc_patsyn_finish which should either be clarified so > it can be considered actionable, removed, or just fixed > > The comment from TcExpr was: > > > I tried to refactor RecSelId to RecSelId [DataCon] Bool but this causes > some pain when it comes to the interface files. Next try it is something > like RecSelId (Either PatSyn TyCon) Bool with the aim for something > better in the future. New description: Ben comments that there are some loose ends with record pattern synonyms (Phab:D1152), * It's still not clear to me that the free variables produced in `rnPatSynBind` are correct * Perhaps in the future we want to refactor `tc_single` to use a function which extends the typechecking environment instead of using `setGblEnv` * @mpickering's suggested refactoring of `RecSelId` to `RecSelId (Either PatSyn TyCon) Bool` described in the comment in `TcExpr.hs` * There is a TODO in `tc_patsyn_finish` which should either be clarified so it can be considered actionable, removed, or just fixed The comment from TcExpr was: > I tried to refactor RecSelId to RecSelId [DataCon] Bool but this causes some pain when it comes to the interface files. Next try it is something like RecSelId (Either PatSyn TyCon) Bool with the aim for something better in the future. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 16:13:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 16:13:26 -0000 Subject: [GHC] #11031: Record Pattern Synonym Cleanup In-Reply-To: <049.41e89b2b13b1b76485458be6dd918ffd@haskell.org> References: <049.41e89b2b13b1b76485458be6dd918ffd@haskell.org> Message-ID: <064.af08a5f3c9813dd52e2ccd864dd91f61@haskell.org> #11031: Record Pattern Synonym Cleanup -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 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): * version: 7.10.2 => 7.11 Old description: > Ben comments that there are some loose ends with record pattern synonyms > (Phab:D1152), > > * It's still not clear to me that the free variables produced in > `rnPatSynBind` are correct > * Perhaps in the future we want to refactor `tc_single` to use a function > which extends the typechecking environment instead of using `setGblEnv` > * @mpickering's suggested refactoring of `RecSelId` to `RecSelId (Either > PatSyn TyCon) Bool` described in the comment in `TcExpr.hs` > * There is a TODO in `tc_patsyn_finish` which should either be clarified > so it can be considered actionable, removed, or just fixed > > The comment from TcExpr was: > > > I tried to refactor RecSelId to RecSelId [DataCon] Bool but this causes > some pain when it comes to the interface files. Next try it is something > like RecSelId (Either PatSyn TyCon) Bool with the aim for something > better in the future. New description: Ben comments that there are some loose ends with record pattern synonyms (Phab:D1152), * It's still not clear to me that the free variables produced in `rnPatSynBind` are correct * Perhaps in the future we want to refactor `tc_single` to use a function which extends the typechecking environment instead of using `setGblEnv` * @mpickering's suggested refactoring of `RecSelId` to `RecSelId (Either PatSyn TyCon) Bool` described in the comment in `TcExpr.hs` * There is a TODO in `tc_patsyn_finish` which should either be clarified so it can be considered actionable, removed, or just fixed The comment from `TcExpr` was: > I tried to refactor `RecSelId `to `RecSelId [DataCon] Bool` but this causes some pain when it comes to the interface files. Next try it is something like `RecSelId (Either PatSyn TyCon) Bool` with the aim for something better in the future. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 17:01:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 17:01:31 -0000 Subject: [GHC] #11031: Record Pattern Synonym Cleanup In-Reply-To: <049.41e89b2b13b1b76485458be6dd918ffd@haskell.org> References: <049.41e89b2b13b1b76485458be6dd918ffd@haskell.org> Message-ID: <064.71042ba6d951ca69e78743fe01585203@haskell.org> #11031: Record Pattern Synonym Cleanup -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 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 simonpj): > @mpickering's suggested refactoring of RecSelId to RecSelId (Either PatSyn TyCon) Bool described in the comment in TcExpr.hs Is that not done already, using `RecSelParent` rather than the `Either` type? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 17:46:29 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 17:46:29 -0000 Subject: [GHC] #10967: Release a new stm package on Hackage In-Reply-To: <048.5f8e847ed74659a561fb4c92223590be@haskell.org> References: <048.5f8e847ed74659a561fb4c92223590be@haskell.org> Message-ID: <063.4e70de3b0dccb22921230b149593d62c@haskell.org> #10967: Release a new stm package on Hackage -------------------------------------+------------------------------------- Reporter: svenpanne | Owner: hvr Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: libraries | Version: (other) | 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 hvr): I'm right now setting things in motion for #11026, and will have to update `stm` anyway; I'm a bit reluctant to upload a `stm` version too soon, in order to avoid publishing something to Hackage just to have it broken yet again as we're going to merge more stuff soon into GHC HEAD which has the risk of breaking `stm` again -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 18:47:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 18:47:06 -0000 Subject: [GHC] #11023: ghci and ghc-pkg disagree about what's exposed In-Reply-To: <044.ef36fd7d1a67594e7e4f6b601e531b2a@haskell.org> References: <044.ef36fd7d1a67594e7e4f6b601e531b2a@haskell.org> Message-ID: <059.3befce1fa1b92d6ce861e4b5eb37c69b@haskell.org> #11023: ghci and ghc-pkg disagree about what's exposed -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dmwit): According to ghc-pkg, the only two packages that are hidden are vector-0.11.0.0 (in the user database) and ghc-7.10.2 (in the global database). Neither of those appear in the dependency tree of vector-0.10.12.3, which is: {{{ vector-0.10.12.3 ??? base-4.8.1.0 ??? ??? ghc-prim-0.4.0.0 ??? ??? ??? builtin_rts ??? ??? integer-gmp-1.0.0.0 ??? ??? ghc-prim-0.4.0.0 ??? ??? builtin_rts ??? deepseq-1.4.1.1 ??? ??? array-0.5.1.0 ??? ??? ??? base-4.8.1.0 ??? ??? ??? ghc-prim-0.4.0.0 ??? ??? ??? ??? builtin_rts ??? ??? ??? integer-gmp-1.0.0.0 ??? ??? ??? ghc-prim-0.4.0.0 ??? ??? ??? builtin_rts ??? ??? base-4.8.1.0 ??? ??? ghc-prim-0.4.0.0 ??? ??? ??? builtin_rts ??? ??? integer-gmp-1.0.0.0 ??? ??? ghc-prim-0.4.0.0 ??? ??? builtin_rts ??? ghc-prim-0.4.0.0 ??? ??? builtin_rts ??? primitive-0.6 ??? base-4.8.1.0 ??? ??? ghc-prim-0.4.0.0 ??? ??? ??? builtin_rts ??? ??? integer-gmp-1.0.0.0 ??? ??? ghc-prim-0.4.0.0 ??? ??? builtin_rts ??? ghc-prim-0.4.0.0 ??? ??? builtin_rts ??? transformers-0.4.2.0 ??? base-4.8.1.0 ??? ghc-prim-0.4.0.0 ??? ??? builtin_rts ??? integer-gmp-1.0.0.0 ??? ghc-prim-0.4.0.0 ??? builtin_rts }}} I also ran ghc-pkg check just to make sure no packages were broken; the only report is an unrelated complaint about haddocks for the nats package. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 19:42:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 19:42:31 -0000 Subject: [GHC] #11032: Missing result type handling for State# s in foreign import prim. Message-ID: <045.864636ea7945cdc0bca5fad7c6cfe665@haskell.org> #11032: Missing result type handling for State# s in foreign import prim. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (FFI) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've been using `foreign import prim` for a while now to craft custom primops on an as-needed basis. Attempting to write {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} {-# LANGUAGE UnliftedFFITypes #-} {-# LANGUAGE GHCForeignImportPrim #-} {-# LANGUAGE ForeignFunctionInterface #-} foreign import prim "pinThreadzh" pinThread# :: State# s -> (# State# s, Int#, Int# #) foreign import prim "unpinThreadzh" unpinThread# :: State# s -> State# s }}} threw me for a loop when it didn't work. The former works fine. The latter complains that `State# s` isn't a valid result type! {{{ src/Concurrent/Internal/Thread.hs:23:1: Unacceptable result type in foreign declaration: ?State# s? cannot be marshalled in a foreign call When checking declaration: foreign import prim safe "static unpinThreadzh" unpinThread# :: State# s -> State# s }}} Builtin primitives work this way all the time, so I'm guessing we just missed it in a case statement somewhere inside the compiler when dealing with `foreign import prim` support. I can likely hack around it by giving back something like `(# State# s #)` for now but that is a rather unsatisfying solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 20:03:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 20:03:43 -0000 Subject: [GHC] #10273: haskeline : Cross-compile from Linux to Windows fails due to In-Reply-To: <044.16994f6a5932b910b77581b817b33330@haskell.org> References: <044.16994f6a5932b910b77581b817b33330@haskell.org> Message-ID: <059.eda96e20bb2e5f0cb478445c656748e7@haskell.org> #10273: haskeline : Cross-compile from Linux to Windows fails due to -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: libraries | Version: 7.11 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #10070 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * owner: erikd => * status: closed => new * resolution: fixed => Comment: I don't consider this one fixed yet, as this needs to be merged upstream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 20:19:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 20:19:21 -0000 Subject: [GHC] #11026: Bump `base` version to 4.9.0.0 In-Reply-To: <042.f747c2b78427a306bca14268108fcb46@haskell.org> References: <042.f747c2b78427a306bca14268108fcb46@haskell.org> Message-ID: <057.9cf6f950faf5475dfaf37ded1d47526e@haskell.org> #11026: Bump `base` version to 4.9.0.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"de27bedb002264d3703394f93f86ee9ec816153a/ghc" de27bedb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="de27bedb002264d3703394f93f86ee9ec816153a" Update haskeline/terminfo submodules This is needed to prepare for #11026 as these updates relax the upper bounds on `base` to allow for `base-4.9.0.0` This update contains no code-changes to terminfo/haskeline yet }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 20:21:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 20:21:24 -0000 Subject: [GHC] #11032: Missing result type handling for State# s in foreign import prim. In-Reply-To: <045.864636ea7945cdc0bca5fad7c6cfe665@haskell.org> References: <045.864636ea7945cdc0bca5fad7c6cfe665@haskell.org> Message-ID: <060.2a88ebd71e0da54eb32087d28ef03ffc@haskell.org> #11032: Missing result type handling for State# s in foreign import prim. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 7.10.2 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 fryguybob): * cc: fryguybob@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 21:00:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 21:00:01 -0000 Subject: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> References: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> Message-ID: <060.5e2587a202f37bd2dbbcfd11b2b72611@haskell.org> #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------+----------------------------- Reporter: jeffz1 | Owner: Phyx- Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Rev(s): Wiki Page: | ---------------------------------+----------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 21:11:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 21:11:04 -0000 Subject: [GHC] #11026: Bump `base` version to 4.9.0.0 In-Reply-To: <042.f747c2b78427a306bca14268108fcb46@haskell.org> References: <042.f747c2b78427a306bca14268108fcb46@haskell.org> Message-ID: <057.6d5c4193d4a52d49deef6b74015b48fa@haskell.org> #11026: Bump `base` version to 4.9.0.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"c1e1584aa175a1c4341ffa1c1f548c2f7513a331/ghc" c1e1584/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c1e1584aa175a1c4341ffa1c1f548c2f7513a331" Update `deepseq` submodule This is done now to prepare for #11026 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 28 22:15:07 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Oct 2015 22:15:07 -0000 Subject: [GHC] #10273: haskeline : Cross-compile from Linux to Windows fails due to In-Reply-To: <044.16994f6a5932b910b77581b817b33330@haskell.org> References: <044.16994f6a5932b910b77581b817b33330@haskell.org> Message-ID: <059.ee05e570ea35774190a7eed3ad41d74f@haskell.org> #10273: haskeline : Cross-compile from Linux to Windows fails due to -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: libraries | Version: 7.11 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #10070 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Submitted a PR on github : https://github.com/judah/haskeline/pull/29 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 07:14:26 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 07:14:26 -0000 Subject: [GHC] #10917: Provide a utility to check API Annotations In-Reply-To: <044.180158552b685611f17d6b8a8773714f@haskell.org> References: <044.180158552b685611f17d6b8a8773714f@haskell.org> Message-ID: <059.8beb561b6dafb3a2d991d4f6496391c9@haskell.org> #10917: Provide a utility to check API Annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1368 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * owner: alanz => * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 07:15:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 07:15:45 -0000 Subject: [GHC] #10917: Provide a utility to check API Annotations In-Reply-To: <044.180158552b685611f17d6b8a8773714f@haskell.org> References: <044.180158552b685611f17d6b8a8773714f@haskell.org> Message-ID: <059.ec7f231b62f5a2e5ebb66ad150a895b3@haskell.org> #10917: Provide a utility to check API Annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1368 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * owner: => alanz Comment: Although the patch has landed in master, I still need to write a proper manual for it, and clean up the output so it is more understandable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 08:59:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 08:59:13 -0000 Subject: [GHC] #10273: haskeline : Cross-compile from Linux to Windows fails due to In-Reply-To: <044.16994f6a5932b910b77581b817b33330@haskell.org> References: <044.16994f6a5932b910b77581b817b33330@haskell.org> Message-ID: <059.f801978ff98b26287cd45d2637ad6cd4@haskell.org> #10273: haskeline : Cross-compile from Linux to Windows fails due to -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: upstream Priority: normal | Milestone: 8.0.1 Component: libraries | Version: 7.11 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #10070 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => upstream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 11:01:59 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 11:01:59 -0000 Subject: [GHC] #11033: ghc 7.10.2 testsuite: "DoParamM(normal)" test fails Message-ID: <048.1c7db3aeebf6a66b725d369df661d4e5@haskell.org> #11033: ghc 7.10.2 testsuite: "DoParamM(normal)" test fails --------------------------------------+--------------------------------- Reporter: dtonhofer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- In the log: {{{ =====> DoParamM(normal) 13 of 4142 [0, 0, 0] cd ./rebindable && "/usr/local/bin/ghc" -c DoParamM.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history > DoParamM.comp.stderr 2>&1 Actual stderr output differs from expected: --- ./rebindable/DoParamM.stderr 2014-12-23 02:31:11.000000000 +0000 +++ ./rebindable/DoParamM.comp.stderr 2015-10-29 10:21:12.520000000 +0000 @@ -1,25 +1,20 @@ DoParamM.hs:146:25: - Couldn't match expected type `Int' with actual type `Char' - In the second argument of `(==)', namely v' - In the first argument of `return', namely `(v == v')' - In a stmt of a 'do' block: return (v == v') + Couldn't match expected type ?Int? with actual type ?Char? + In the second argument of ?(==)?, namely ?v'? + In the first argument of ?return?, namely ?(v == v')? DoParamM.hs:286:28: - Couldn't match type `Unlocked' with `Locked' + Couldn't match type ?Unlocked? with ?Locked? Expected type: LIO Locked Locked () Actual type: LIO Unlocked Locked () In a stmt of a 'do' block: tlock2_do In the expression: do { tlock2_do; tlock2_do } - In an equation for `tlock4_do': - tlock4_do - = do { tlock2_do; - tlock2_do } DoParamM.hs:302:37: - Couldn't match type `Locked' with `Unlocked' + Couldn't match type ?Locked? with ?Unlocked? Expected type: LIO Unlocked Unlocked () Actual type: LIO Locked Unlocked () In a stmt of a 'do' block: unlock @@ -27,8 +22,3 @@ do { tlock2_do; unlock; unlock } - In an equation for `tlock4'_do': - tlock4'_do - = do { tlock2_do; - unlock; - unlock } *** unexpected failure for DoParamM(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 11:08:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 11:08:00 -0000 Subject: [GHC] #11034: ghc 7.10.2 testsuite: "T367(normal)" test compilation fails Message-ID: <048.7bcba4146771a0fa18b97c4cde40ecf0@haskell.org> #11034: ghc 7.10.2 testsuite: "T367(normal)" test compilation fails ----------------------------------------+--------------------------------- Reporter: dtonhofer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- {{{ =====> T367(normal) 39 of 4142 [0, 1, 0] cd ./concurrent/should_run && "/usr/local/bin/ghc" -o T367 T367.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-warn-tabs -fno-ghci-history -O2 -fno-omit-yields > T367.comp.stderr 2>&1 Compile failed (status 256) errors were: [1 of 1] Compiling Main ( T367.hs, T367.o ) *** Core Lint errors : in result of Simplifier *** : Warning: In the expression: seq @ (Id Int) @ (# State# RealWorld, () #) (foldlM' @ Int @ Int @ Id @ Vector $fMonadId ($fNumInt_$c+ `cast` (_R -> _R -> Sym (NTCo:Id[0] _R) :: (Int -> Int -> Int) ~R# (Int -> Int -> Id Int))) z_a2UZ (enumFromTo_int @ Id @ Vector $fMonadId (I# 1) (I# 1000000000))) (# eta_B1, () #) Kinds don't match in type application: Type variable: b_13 :: * Arg type: (# State# RealWorld, () #) :: # xx # (.... offending program attached ...) *** End of Offense *** : Compilation had errors *** unexpected failure for T367(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 11:08:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 11:08:24 -0000 Subject: [GHC] #11034: ghc 7.10.2 testsuite: "T367(normal)" test compilation fails In-Reply-To: <048.7bcba4146771a0fa18b97c4cde40ecf0@haskell.org> References: <048.7bcba4146771a0fa18b97c4cde40ecf0@haskell.org> Message-ID: <063.7f4c3e4863e47fa915f30d0db8d34138@haskell.org> #11034: ghc 7.10.2 testsuite: "T367(normal)" test compilation fails ---------------------------------+---------------------------------------- Reporter: dtonhofer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.2 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 dtonhofer): * Attachment "attach.txt" added. Dump of offending program -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 11:56:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 11:56:03 -0000 Subject: [GHC] #10962: Improved arithmetic primops In-Reply-To: <050.9a384d25dddf3580aebe73d3e27aa54b@haskell.org> References: <050.9a384d25dddf3580aebe73d3e27aa54b@haskell.org> Message-ID: <065.15ad8ba2b0e08ddffdcaa861ed2ad3d2@haskell.org> #10962: Improved arithmetic primops -------------------------------------+------------------------------------- Reporter: nkaretnikov | Owner: nkaretnikov Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | wiki:ImprovedArithmeticPrimops | -------------------------------------+------------------------------------- Comment (by nkaretnikov): Replying to [comment:3 tibbe]: > Could you clarify (on the wiki) what assembly you get if you just implement this in Haskell (on top of the "unsafe" primops) and what assembly you'd like to see. Elsewhere (e.g. with the shift primops) we have been able to implement "safe" primops on top of the unsafe ones. https://ghc.haskell.org/trac/ghc/wiki/ImprovedArithmeticPrimops#AsmfromsubWordCvs .asmfromauser-definedoverflow-checkingfunction -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 12:27:01 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 12:27:01 -0000 Subject: [GHC] #11034: ghc 7.10.2 testsuite: "T367(normal)" test compilation fails In-Reply-To: <048.7bcba4146771a0fa18b97c4cde40ecf0@haskell.org> References: <048.7bcba4146771a0fa18b97c4cde40ecf0@haskell.org> Message-ID: <063.edbbb4bd4297a77c770b3b579d13982b@haskell.org> #11034: ghc 7.10.2 testsuite: "T367(normal)" test compilation fails ---------------------------------+---------------------------------------- Reporter: dtonhofer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.2 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 simonpj): This is in `testsuite/tests/concurrent/should_run` correct? I get {{{ 1 had missing libraries }}} and indeed I don't have `libraries/concurrent` installed. I'm not sure whether it lives in GHC's build tree any more. Could you have an out of date hi file or something? Anyway how do I reproduce? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 13:31:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 13:31:54 -0000 Subject: [GHC] #4837: Template Haskell does not work in a profiled compiler. In-Reply-To: <043.b5650b88723ece09a2484d5316810782@haskell.org> References: <043.b5650b88723ece09a2484d5316810782@haskell.org> Message-ID: <058.9bdf6353ef7a0271328010e369a1d96b@haskell.org> #4837: Template Haskell does not work in a profiled compiler. -------------------------------------+------------------------------------- Reporter: benl | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Profiling | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * owner: => simonmar * priority: low => high Comment: I'm working on this. It's mostly working already, the patch is on my github branch: https://github.com/simonmar/ghc/tree/prof-ghci -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 13:34:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 13:34:06 -0000 Subject: [GHC] #545: GHCi + profiling doesn't work In-Reply-To: <049.b673ccee7e6889a7345a01acda87eed3@haskell.org> References: <049.b673ccee7e6889a7345a01acda87eed3@haskell.org> Message-ID: <064.70949809a39d52b98dea79f033ea1805@haskell.org> #545: GHCi + profiling doesn't work -------------------------------------+------------------------------------- Reporter: nilsanders | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 5.0 Resolution: | Keywords: 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 simonmar): * status: closed => new * type: bug => feature request * os: => Unknown/Multiple * component: Compiler => GHCi * failure: => None/Unknown * architecture: => Unknown/Multiple * milestone: => 8.0.1 * owner: nobody => * resolution: Wont Fix => Old description: > {{{ > Main.hs: > > module Main where > > main = putStrLn "Hi!" > > Compile this with profiling turned on: > > > ghc -prof -auto-all -o hello --make Main.hs > ghc-5.00: chasing modules from: Main.hs > Compiling Main ( Main.hs, ./Main.o ) > ghc: linking ... > > Try to load the file with GHCi: > > > ghci Main > ___ ___ _ > / _ \ /\ /\/ __(_) > / /_\// /_/ / / | | GHC Interactive, version > 5.00, For Haskell 98. > / /_\\/ __ / /___| | http://www.haskell.org/ghc/ > \____/\/ /_/\____/|_| Type :? for help. > > Loading package std ... linking ... done. > Skipping Main ( Main.hs, ./Main.o ) > ghc-5.00: fatal error: do_Elf32_Rel_relocations: > ./Main.o: unknown symbol `CC_LIST' > > }}} New description: {{{ Main.hs: module Main where main = putStrLn "Hi!" Compile this with profiling turned on: > ghc -prof -auto-all -o hello --make Main.hs ghc-5.00: chasing modules from: Main.hs Compiling Main ( Main.hs, ./Main.o ) ghc: linking ... Try to load the file with GHCi: > ghci Main ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.00, For Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. Loading package std ... linking ... done. Skipping Main ( Main.hs, ./Main.o ) ghc-5.00: fatal error: do_Elf32_Rel_relocations: ./Main.o: unknown symbol `CC_LIST' }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 13:34:40 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 13:34:40 -0000 Subject: [GHC] #545: GHCi + profiling doesn't work In-Reply-To: <049.b673ccee7e6889a7345a01acda87eed3@haskell.org> References: <049.b673ccee7e6889a7345a01acda87eed3@haskell.org> Message-ID: <064.546b3f1f0eab6aebba3a3c661c7483a6@haskell.org> #545: GHCi + profiling doesn't work -------------------------------------+------------------------------------- Reporter: nilsanders | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 5.0 Resolution: | Keywords: 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 simonmar): * owner: => simonmar Comment: Work in progress: https://github.com/simonmar/ghc/tree/prof-ghci -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 14:13:22 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 14:13:22 -0000 Subject: [GHC] #10967: Release a new stm package on Hackage In-Reply-To: <048.5f8e847ed74659a561fb4c92223590be@haskell.org> References: <048.5f8e847ed74659a561fb4c92223590be@haskell.org> Message-ID: <063.13b09ace2cc0d56e3d797ebe62127621@haskell.org> #10967: Release a new stm package on Hackage -------------------------------------+------------------------------------- Reporter: svenpanne | Owner: hvr Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: libraries | Version: (other) | 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 svenpanne): OK, that's fine with me. I guess a few more things will break when base's version number is bumped, anyway. I just wanted to point out that lots of packages are effectively broken with HEAD right now (even if they have no problem in their *own* sources), and the sooner things get fixed, the better. Given the amount of changes in base, Travis-CI is more important than ever... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 14:34:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 14:34:32 -0000 Subject: [GHC] #10998: Parser should suggest -XMagicHash In-Reply-To: <043.3df6745fc43649973c9f6cd84b47f3f2@haskell.org> References: <043.3df6745fc43649973c9f6cd84b47f3f2@haskell.org> Message-ID: <058.051b6209453b5373b3e2eadf2db86f31@haskell.org> #10998: Parser should suggest -XMagicHash -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (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 osa1): I think we should to be able to say, in the lexer, "print these warnings only if parsing fails". This would be very useful in cases like this. Some examples: {{{#!haskell ?:9> 1#2 :9:2: Not in scope: ?#? ?:10> :set -XMagicHash ?:11> 1#2 :11:1: Couldn't match expected type ?Integer -> t? with actual type ?Int#? Relevant bindings include it :: t (bound at :11:1) The function ?1#? is applied to one argument, but its type ?Int#? has none In the expression: 1# 2 In an equation for ?it?: it = 1# 2 }}} Here we shouldn't print any warnings like "Maybe you intended to use -XMagicHash" in the first line. But suppose this happened: {{{#!haskell ?:6> 1# +# 2# :6:4: parse error on input ?+#? }}} or see my original example above. In these cases we want to print a warning. I think only reliable way to decide when to print this warning is to check if parsing succeeded. If it's not, and if there was another way to lex some tokens with `-XMagicHash`, maybe the user is intended to use `-XMagicHash`, so the warning makes sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 15:03:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 15:03:58 -0000 Subject: [GHC] #11001: BlockedIndefinitelyOnMVar thrown with live reference in unrelated finalizer In-Reply-To: <046.2cc9f3eed9ffb6efbcf5550718daab5b@haskell.org> References: <046.2cc9f3eed9ffb6efbcf5550718daab5b@haskell.org> Message-ID: <061.15c238a2a99bf5d7ad496d8aa9958c9c@haskell.org> #11001: BlockedIndefinitelyOnMVar thrown with live reference in unrelated finalizer -------------------------------------+------------------------------------- Reporter: exFalso | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: wontfix | Keywords: | BlockedIndefinitelyOnMVar finalize Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: Yes, this is working as intended, see documentation at https://downloads.haskell.org/~ghc/7.10.2/docs/html/libraries/base-4.8.1.0 /Control-Concurrent.html#g:14 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 15:15:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 15:15:12 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.8b8a9af9e2936111d5029f46e27484ea@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T9858a,b,c; | should_run/T9858b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D652 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"bef2f03e4d56d88a7e9752a7afd6a0a35616da6c/ghc" bef2f03e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bef2f03e4d56d88a7e9752a7afd6a0a35616da6c" Generate Typeable info at definition sites This patch implements the idea floated in Trac #9858, namely that we should generate type-representation information at the data type declaration site, rather than when solving a Typeable constraint. However, this turned out quite a bit harder than I expected. I still think it's the right thing to do, and it's done now, but it was quite a struggle. See particularly * Note [Grand plan for Typeable] in TcTypeable (which is a new module) * Note [The overall promotion story] in DataCon (clarifies existing stuff) The most painful bit was that to generate Typeable instances (ie TyConRepName bindings) for every TyCon is tricky for types in ghc-prim etc: * We need to have enough data types around to *define* a TyCon * Many of these types are wired-in Also, to minimise the code generated for each data type, I wanted to generate pure data, not CAFs with unpackCString# stuff floating about. Performance ~~~~~~~~~~~ Three perf/compiler tests start to allocate quite a bit more. This isn't surprising, because they all allocate zillions of data types, with practically no other code, esp. T1969 * T3294: GHC allocates 110% more (filed #11030 to track this) * T1969: GHC allocates 30% more * T4801: GHC allocates 14% more * T5321FD: GHC allocates 13% more * T783: GHC allocates 12% more * T9675: GHC allocates 12% more * T5642: GHC allocates 10% more * T9961: GHC allocates 6% more * T9203: Program allocates 54% less I'm treating this as acceptable. The payoff comes in Typeable-heavy code. Remaining to do ~~~~~~~~~~~~~~~ * I think that "TyCon" and "Module" are over-generic names to use for the runtime type representations used in GHC.Typeable. Better might be "TrTyCon" and "TrModule". But I have not yet done this * Add more info the the "TyCon" e.g. source location where it was defined * Use the new "Module" type to help with Trac Trac #10068 * It would be possible to generate TyConRepName (ie Typeable instances) selectively rather than all the time. We'd need to persist the information in interface files. Lacking a motivating reason I have not done this, but it would not be difficult. Refactoring ~~~~~~~~~~~ As is so often the case, I ended up refactoring more than I intended. In particular * In TyCon, a type *family* (whether type or data) is repesented by a FamilyTyCon * a algebraic data type (including data/newtype instances) is represented by AlgTyCon This wasn't true before; a data family was represented as an AlgTyCon. There are some corresponding changes in IfaceSyn. * Also get rid of the (unhelpfully named) tyConParent. * In TyCon define 'Promoted', isomorphic to Maybe, used when things are optionally promoted; and use it elsewhere in GHC. * Cleanup handling of knownKeyNames * Each TyCon, including promoted TyCons, contains its TyConRepName, if it has one. This is, in effect, the name of its Typeable instance. Requires update of the haddock submodule. Differential Revision: https://phabricator.haskell.org/D757 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 15:15:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 15:15:12 -0000 Subject: [GHC] #11030: D757 (emit Typeable at type definition site) regresses T3294 max_bytes_used by factor of two In-Reply-To: <046.dcbfe5b30aed7ce500ba8edfc26b6702@haskell.org> References: <046.dcbfe5b30aed7ce500ba8edfc26b6702@haskell.org> Message-ID: <061.65213d1596ec717d52a0261ee9bdc086@haskell.org> #11030: D757 (emit Typeable at type definition site) regresses T3294 max_bytes_used by factor of two -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T3294 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"bef2f03e4d56d88a7e9752a7afd6a0a35616da6c/ghc" bef2f03e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bef2f03e4d56d88a7e9752a7afd6a0a35616da6c" Generate Typeable info at definition sites This patch implements the idea floated in Trac #9858, namely that we should generate type-representation information at the data type declaration site, rather than when solving a Typeable constraint. However, this turned out quite a bit harder than I expected. I still think it's the right thing to do, and it's done now, but it was quite a struggle. See particularly * Note [Grand plan for Typeable] in TcTypeable (which is a new module) * Note [The overall promotion story] in DataCon (clarifies existing stuff) The most painful bit was that to generate Typeable instances (ie TyConRepName bindings) for every TyCon is tricky for types in ghc-prim etc: * We need to have enough data types around to *define* a TyCon * Many of these types are wired-in Also, to minimise the code generated for each data type, I wanted to generate pure data, not CAFs with unpackCString# stuff floating about. Performance ~~~~~~~~~~~ Three perf/compiler tests start to allocate quite a bit more. This isn't surprising, because they all allocate zillions of data types, with practically no other code, esp. T1969 * T3294: GHC allocates 110% more (filed #11030 to track this) * T1969: GHC allocates 30% more * T4801: GHC allocates 14% more * T5321FD: GHC allocates 13% more * T783: GHC allocates 12% more * T9675: GHC allocates 12% more * T5642: GHC allocates 10% more * T9961: GHC allocates 6% more * T9203: Program allocates 54% less I'm treating this as acceptable. The payoff comes in Typeable-heavy code. Remaining to do ~~~~~~~~~~~~~~~ * I think that "TyCon" and "Module" are over-generic names to use for the runtime type representations used in GHC.Typeable. Better might be "TrTyCon" and "TrModule". But I have not yet done this * Add more info the the "TyCon" e.g. source location where it was defined * Use the new "Module" type to help with Trac Trac #10068 * It would be possible to generate TyConRepName (ie Typeable instances) selectively rather than all the time. We'd need to persist the information in interface files. Lacking a motivating reason I have not done this, but it would not be difficult. Refactoring ~~~~~~~~~~~ As is so often the case, I ended up refactoring more than I intended. In particular * In TyCon, a type *family* (whether type or data) is repesented by a FamilyTyCon * a algebraic data type (including data/newtype instances) is represented by AlgTyCon This wasn't true before; a data family was represented as an AlgTyCon. There are some corresponding changes in IfaceSyn. * Also get rid of the (unhelpfully named) tyConParent. * In TyCon define 'Promoted', isomorphic to Maybe, used when things are optionally promoted; and use it elsewhere in GHC. * Cleanup handling of knownKeyNames * Each TyCon, including promoted TyCons, contains its TyConRepName, if it has one. This is, in effect, the name of its Typeable instance. Requires update of the haddock submodule. Differential Revision: https://phabricator.haskell.org/D757 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 15:15:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 15:15:12 -0000 Subject: [GHC] #10068: Make the runtime reflection API for names, modules, locations more systematic In-Reply-To: <046.e24e266e9d617fc4224d115c2a203db8@haskell.org> References: <046.e24e266e9d617fc4224d115c2a203db8@haskell.org> Message-ID: <061.1ce08c2e3eaf5b67b5518448138dbd8e@haskell.org> #10068: Make the runtime reflection API for names, modules, locations more systematic -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"bef2f03e4d56d88a7e9752a7afd6a0a35616da6c/ghc" bef2f03e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bef2f03e4d56d88a7e9752a7afd6a0a35616da6c" Generate Typeable info at definition sites This patch implements the idea floated in Trac #9858, namely that we should generate type-representation information at the data type declaration site, rather than when solving a Typeable constraint. However, this turned out quite a bit harder than I expected. I still think it's the right thing to do, and it's done now, but it was quite a struggle. See particularly * Note [Grand plan for Typeable] in TcTypeable (which is a new module) * Note [The overall promotion story] in DataCon (clarifies existing stuff) The most painful bit was that to generate Typeable instances (ie TyConRepName bindings) for every TyCon is tricky for types in ghc-prim etc: * We need to have enough data types around to *define* a TyCon * Many of these types are wired-in Also, to minimise the code generated for each data type, I wanted to generate pure data, not CAFs with unpackCString# stuff floating about. Performance ~~~~~~~~~~~ Three perf/compiler tests start to allocate quite a bit more. This isn't surprising, because they all allocate zillions of data types, with practically no other code, esp. T1969 * T3294: GHC allocates 110% more (filed #11030 to track this) * T1969: GHC allocates 30% more * T4801: GHC allocates 14% more * T5321FD: GHC allocates 13% more * T783: GHC allocates 12% more * T9675: GHC allocates 12% more * T5642: GHC allocates 10% more * T9961: GHC allocates 6% more * T9203: Program allocates 54% less I'm treating this as acceptable. The payoff comes in Typeable-heavy code. Remaining to do ~~~~~~~~~~~~~~~ * I think that "TyCon" and "Module" are over-generic names to use for the runtime type representations used in GHC.Typeable. Better might be "TrTyCon" and "TrModule". But I have not yet done this * Add more info the the "TyCon" e.g. source location where it was defined * Use the new "Module" type to help with Trac Trac #10068 * It would be possible to generate TyConRepName (ie Typeable instances) selectively rather than all the time. We'd need to persist the information in interface files. Lacking a motivating reason I have not done this, but it would not be difficult. Refactoring ~~~~~~~~~~~ As is so often the case, I ended up refactoring more than I intended. In particular * In TyCon, a type *family* (whether type or data) is repesented by a FamilyTyCon * a algebraic data type (including data/newtype instances) is represented by AlgTyCon This wasn't true before; a data family was represented as an AlgTyCon. There are some corresponding changes in IfaceSyn. * Also get rid of the (unhelpfully named) tyConParent. * In TyCon define 'Promoted', isomorphic to Maybe, used when things are optionally promoted; and use it elsewhere in GHC. * Cleanup handling of knownKeyNames * Each TyCon, including promoted TyCons, contains its TyConRepName, if it has one. This is, in effect, the name of its Typeable instance. Requires update of the haddock submodule. Differential Revision: https://phabricator.haskell.org/D757 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 16:32:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 16:32:28 -0000 Subject: [GHC] #11035: Add implicit call-stacks to partial functions in base Message-ID: <049.cfaa63a68670a816facc2036509f578c@haskell.org> #11035: Add implicit call-stacks to partial functions in base -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From https://www.reddit.com/r/haskell/comments/3qpefo/a_very_unfortunate_error_message/ {{{ ghci> minimumBy compare [] *** Exception: Prelude.foldr1: empty list CallStack: error, called at libraries/base/GHC/List.hs:999:3 in base-4.8.2.0:GHC.List }}} This is not a very useful call-stack. It tells us that error was called in GHC.List, and if we happen to have the source we can even see where it was called. https://github.com/ghc/ghc/blob/master/libraries/base/GHC/List.hs#L999 But that's '''still''' not very helpful because: 1. It points us to some generic `errorEmptyList` function. This function always diverges, so by our current rule it ought to get a CallStack constraint. Oops! 2. Even if we add the CallStack to `errorEmptyList`, the next culprit will (presumably) be `foldr1`, where the stack ends again. `foldr1` is partial, but it doesn't '''always''' diverge, so our current rule would say it shouldn't get a CallStack. This is quite unfortunate because the CallStack will point the finger at `foldr1`, but the error message itself '''already does that'''. So we haven't really gained anything by using the CallStack-aware `error` in base. What we really want to know is where `foldr1` was called, which just so happens to be `minimumBy` itself! Ben Gamari pinged me earlier today on IRC with a similar instance in GHC.Arr. ---- So, I think we should '''consider''' expanding the use of CallStacks in base by one level, to partial functions. By "partial" I specifically mean functions that directly call `error` or one of its wrappers (like `errorEmptyList`). That means that {{{#!haskell head [] = error "bad" head (x:xs) = x }}} would get a CallStack, but {{{#!haskell minimumBy cmp = foldr1 min' where min' x y = case cmp x y of GT -> y _ -> x }}} would '''not''', even though `minimumBy` is also partial in the traditional sense. I recall three arguments against broader use of CallStacks: 1. '''Performance concerns''': CallStacks exist at runtime in the form of an extra parameter to each CallStack-aware function. This is a valid concern and we should certainly do some benchmarking to see what the effects are. 2. '''Readability concerns''': Adding CallStacks will clutter otherwise simple type signatures, e.g. {{{#!haskell head :: [a] -> a head :: (?callStack :: CallStack) => [a] -> a }}} Also a valid concern, especially considering that base functions are the first novices will encounter. But I think we can mitigate this one in two steps. (1) The `:type` command in ghci already suppresses the CallStacks (because it happens to invoke the constraint solver), but `:info` shows them. I think this is fine as is. (2) If haddock shows CallStacks (I'm not sure if it does), we could patch haddock to render them differently. For example, instead of rendering the full type, just render {{{ head :: [a] -> a }}} with a badge that indicates that `head` is location-aware. That would reduce the cognitive overhead of the larger type signature, while retaining the important data. 3. '''Slippery slope''': Where do we draw the line? Why should `head` get a CallStack but not `minimumBy`? I don't have a good answer to this one yet, apart from a suspicion that my proposal will get us a closer to an 80/20 balance. I'm sure this would need to go through the Core Libraries Committee, but I'd also like feedback from fellow GHC devs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 17:20:26 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 17:20:26 -0000 Subject: [GHC] #11035: Add implicit call-stacks to partial functions in base In-Reply-To: <049.cfaa63a68670a816facc2036509f578c@haskell.org> References: <049.cfaa63a68670a816facc2036509f578c@haskell.org> Message-ID: <064.c3a81f00dfa76aad8859e4270e60f6fb@haskell.org> #11035: Add implicit call-stacks to partial functions in base -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I like this general idea. But I want to find a way to the bottom of the slope, where '''all''' partial functions in base get call stack information. This plan alleviates your problem (3) quite nicely. * For problem (1): it seems quite easy to write a core-to-core pass that scrubs away the call stacks. This core pass would be enabled by `-O` but could be countermanded with `-fno-scrub-call-stacks` (in case there is an error only in optimized code, say). base would be compiled with `-fno- scrub-call-stacks`. This approach doesn't fix the performance of library functions, though. So we could instead have base export two versions of the functions, one with call stacks and one without. How do we relate the two? Via `RULES`: {{{#!hs foldr1 :: (?callstack :: CallStack) => ... faster_foldr1 :: ... {-# RULES "foldr1 call stack scrub" foldr1 = faster_foldr1 #-} }}} Without optimizations, we get the call stack. With optimizations, we don't. Huzzah. It's easy to imagine someone wanting to disable only these call-stack- ish RULES but keep others. Perhaps we should consider tagging RULES somehow to allow activating or deactivating RULES in groups. But that's a proposal for another day, and I don't think we absolutely need that here. * For problem (2): Your suggestions are good. We could also do a cheap trick like this: {{{#!hs type PartialFunction = (?callstack :: CallStack) head :: PartialFunction => [a] -> a }}} Yes, this needs `ConstraintKinds`, but I sorta like it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 17:55:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 17:55:53 -0000 Subject: [GHC] #11035: Add implicit call-stacks to partial functions in base In-Reply-To: <049.cfaa63a68670a816facc2036509f578c@haskell.org> References: <049.cfaa63a68670a816facc2036509f578c@haskell.org> Message-ID: <064.6d4ff141f0d99e68368d1b4ccb9a5b34@haskell.org> #11035: Add implicit call-stacks to partial functions in base -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): Regarding problem (1): I get the feeling this will require code duplication at the source level, which would be a Bad Thing. We can't just write {{{#!haskell foldr1 :: (?callStack :: CallStack) => ... foldr1 = faster_foldr1 faster_foldr1 :: ... faster_foldr1 f [] = error faster_foldr1 f (x:xs) = foldr f xs }}} because the call to `error` in `faster_foldr1` won't see a given CallStack, and the chain will be broken there. Instead we'd have to write {{{#!haskell foldr1 :: (?callStack :: CallStack) => ... foldr1 f [] = error foldr1 f (x:xs) = foldr f x xs faster_foldr1 :: ... faster_foldr1 f [] = error faster_foldr1 f (x:xs) = foldr f xs }}} It may be the case that most partial functions in base are either simple themselves (like `head`) or have simple definitions in terms of a total function (like `foldr`). So maybe the duplication wouldn't be ''that'' bad, but I'm still pretty wary of this route... A more heavyweight solution could be to have GHC generate a callstack-free version of each function that takes a CallStack, along with a RULE like you described. Then the source-level duplication is gone, but the desugarer or simplifier becomes more complex. In either scenario we end up exporting multiple versions of the "same" function, which will bloat library sizes. But maybe that's not so bad, the binaries shouldn't be affected. (I kinda like the `PartialFunction` constraint too, it's cute.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 17:58:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 17:58:11 -0000 Subject: [GHC] #11035: Add implicit call-stacks to partial functions in base In-Reply-To: <049.cfaa63a68670a816facc2036509f578c@haskell.org> References: <049.cfaa63a68670a816facc2036509f578c@haskell.org> Message-ID: <064.27bfb8b6469befa29cd73a810b5827e2@haskell.org> #11035: Add implicit call-stacks to partial functions in base -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): Question: won't the dwarf based runtime stack traces that Ben Gamari is polishing for ghc 8 provide equivalent ish information , but without any performance implications? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 17:59:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 17:59:06 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.dc02c95d8ebfcbc5176a07e6964127cd@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.3 Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1205 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: closed => new * resolution: fixed => Comment: While the patch is nice, I don?t think this bug is fixed (see comment:13). Also see https://mail.haskell.org/pipermail/libraries/2015-October/026430.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 18:09:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 18:09:55 -0000 Subject: [GHC] #11035: Add implicit call-stacks to partial functions in base In-Reply-To: <049.cfaa63a68670a816facc2036509f578c@haskell.org> References: <049.cfaa63a68670a816facc2036509f578c@haskell.org> Message-ID: <064.a46c3008b03db78dd7eac73feb1c5e6d@haskell.org> #11035: Add implicit call-stacks to partial functions in base -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): Possibly, I admit I'm not super familiar with the DWARF work. My main concern would be that the DWARF stack trace will expose haskell's lazy evaluation just like the cost-centre traces do. I find these difficult to debug because they jump all over the place as values are demanded. That might be useful for performance debugging, but for debugging a crash I just want to know '''where''' things were called, not what sequence of "demandings" led me to the crash. In other words, I want a trace based on the static call graph, which is what the implicit call-stacks provide. I hope that makes sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 18:29:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 18:29:13 -0000 Subject: [GHC] #11035: Add implicit call-stacks to partial functions in base In-Reply-To: <049.cfaa63a68670a816facc2036509f578c@haskell.org> References: <049.cfaa63a68670a816facc2036509f578c@haskell.org> Message-ID: <064.44a4f6b518cae3dbdeb2616e616282fd@haskell.org> #11035: Add implicit call-stacks to partial functions in base -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): How about we stay on top of the slipperly slope for a while, and let people experiment with their call-stack enabled custom Preludes first for a while? In fact, what I do not like about {{{ ghci> minimumBy compare [] *** Exception: Prelude.foldr1: empty list CallStack: error, called at libraries/base/GHC/List.hs:999:3 in base-4.8.2.0:GHC.List }}} is that it leaks implementation details. This is great in your own code, but a polished library should _not_ leak a call stack about its details; it should either print plain exception or the call stack that finishes at the library?s API. At least for ?expected exceptions? like `"empty list"`. So I would say what we have to do here is to prevent this call to error from adding a call stack. For that, uses of `error` in library functions? should explicitly use `let ?foo::CallStack = emptyCallStack in error "..."` to prevent the constraint solver from adding an implementation- leaky call-stack here (if that even works, maybe what I want to achieve here requires modifications to the solver). ? Of course, precisely those that do not propagate the `?_::CallStack` constraint to the caller. If we decide to do that, then everything is fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 20:16:36 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 20:16:36 -0000 Subject: [GHC] #10917: Provide a utility to check API Annotations In-Reply-To: <044.180158552b685611f17d6b8a8773714f@haskell.org> References: <044.180158552b685611f17d6b8a8773714f@haskell.org> Message-ID: <059.50642f706d0f19d6317f7a2e0c8d4e29@haskell.org> #10917: Provide a utility to check API Annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | Phab:D1368,Phab:D1397 -------------------------------------+------------------------------------- Changes (by alanz): * differential: Phab:D1368 => Phab:D1368,Phab:D1397 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 20:39:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 20:39:47 -0000 Subject: [GHC] #10273: haskeline : Cross-compile from Linux to Windows fails due to In-Reply-To: <044.16994f6a5932b910b77581b817b33330@haskell.org> References: <044.16994f6a5932b910b77581b817b33330@haskell.org> Message-ID: <059.81db442b129670b14e644b1f24fac02f@haskell.org> #10273: haskeline : Cross-compile from Linux to Windows fails due to -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: upstream Priority: normal | Milestone: 8.0.1 Component: libraries | Version: 7.11 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #10070 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): The PR has been accepted upstream. Not sure if a new release has been rolled yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 21:12:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 21:12:33 -0000 Subject: [GHC] #10917: Provide a utility to check API Annotations In-Reply-To: <044.180158552b685611f17d6b8a8773714f@haskell.org> References: <044.180158552b685611f17d6b8a8773714f@haskell.org> Message-ID: <059.7918059dd8b70dadc02442ab296ea90d@haskell.org> #10917: Provide a utility to check API Annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1368 Wiki Page: | Phab:D1397 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch * differential: Phab:D1368,Phab:D1397 => Phab:D1368 Phab:D1397 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 22:08:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 22:08:32 -0000 Subject: [GHC] #11035: Add implicit call-stacks to partial functions in base In-Reply-To: <049.cfaa63a68670a816facc2036509f578c@haskell.org> References: <049.cfaa63a68670a816facc2036509f578c@haskell.org> Message-ID: <064.d38cb531460b28850bb71f3a7529c3d4@haskell.org> #11035: Add implicit call-stacks to partial functions in base -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): > it should either print plain exception or the call stack that finishes at the library?s API I would say that `minimumBy`s call stack does "finish at the library's api;" the root is in GHC.List, which is part of base. Perhaps you mean that a function `f` should only print call stacks whose root is `f`. That's an interesting point, and does seem reasonable for production code, but it sounds very non-trivial to implement. You can think of the CallStack solver as rewriting your code as follows. Whenever it sees a CallStack constraint, eg from a call to `error` {{{ f x = error }}} it inserts a new implicit binder that adds the current call-site {{{ f x = let ?callStack = `pushCallStack` ?callStack in error }}} The `?callStack` on the rhs will either be discharged by the CallStack in `f`s context (if `f` requested one) or by the empty CallStack. So we can't just write `let ?callStack = emptyCallStack in error` because that's effectively what GHC is already doing for us. Instead we would need multiple versions of the callstack-aware functions, as Richard suggested. In general, I think Richard's suggestion of a call-stack scrubbing pass for optimized code should satisfy your concern as well. If I compile packages from hackage with optimizations (the default I think), then I won't see the implementation details. If I don't, I'll see the details, but I can at least submit a more informative bug report! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 22:17:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 22:17:27 -0000 Subject: [GHC] #11035: Add implicit call-stacks to partial functions in base In-Reply-To: <049.cfaa63a68670a816facc2036509f578c@haskell.org> References: <049.cfaa63a68670a816facc2036509f578c@haskell.org> Message-ID: <064.f011bcc53aee4a60b6d45fd0fbe79e1b@haskell.org> #11035: Add implicit call-stacks to partial functions in base -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > So we can't just write `let ?callStack = emptyCallStack in error` because that's effectively what GHC is already doing for us. Instead we would need multiple versions of the callstack-aware functions, as Richard suggested. What if we add a special `rootCallStack :: CallStack` which is a value such that {{{ x `pushCallStack` rootCallStack = rootCallStack }}} but {{{ rootCallStack `pushCallStack` x = rootCallStack ?:? x }}} as before and a call stack that consists of only a rootCallStack causes no stack trace to be printed. This allows the following two important patterns: {{{ f x = let ?callStack = rootCallStack in {... something with error or any other callStack expecting function ...} }}} would prevent any CallStack information to appear in `{...}`, and {{{ f x = let ?callStack = rootCallStack `pushCallStack` ?callStack in {... something with error or any other callStack expecting function ...} }}} which would include a CallStack in exceptions raised in `{...}`, but the stack would end in `f`, and not expose any of the structure of the implementation. I?d like to have something like this for API hygiene and implementation hiding. But note that if we had that, constant propagation (or `rootCallStack`) and a specialization mechanism that?s very much like the existing type class constraint specialization would allow the compiler to specialize the implementation in the former case to one that does _not_ pass CallStacks around any more. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 22:47:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 22:47:58 -0000 Subject: [GHC] #11035: Add implicit call-stacks to partial functions in base In-Reply-To: <049.cfaa63a68670a816facc2036509f578c@haskell.org> References: <049.cfaa63a68670a816facc2036509f578c@haskell.org> Message-ID: <064.d9b99f815110edaa51f1db765bcf7615@haskell.org> #11035: Add implicit call-stacks to partial functions in base -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): > What if we add a special `rootCallStack :: CallStack` ... I think this is doable. One thing worth stressing is that in your scenario the programmer has to '''explicitly''' say where they want the call-stack to be cut off (or to kill it altogether). This is in stark contrast to the existing scenarios, where call-stacks are handled entirely behind the scenes by GHC. But it sounds like you really want the option for explicit control, and I kinda understand why. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 22:56:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 22:56:27 -0000 Subject: [GHC] #11035: Add implicit call-stacks to partial functions in base In-Reply-To: <049.cfaa63a68670a816facc2036509f578c@haskell.org> References: <049.cfaa63a68670a816facc2036509f578c@haskell.org> Message-ID: <064.c2de3fcf0bd68f5596a3ffb9b7afd745@haskell.org> #11035: Add implicit call-stacks to partial functions in base -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Yes, I kinda hijacked this ticket by accident; sorry for that. Do you want me to open a separate one? But yes: In a carefully crafted library for public consumption, explicit control over the produced call stacks seem to be desirable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 23:04:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 23:04:31 -0000 Subject: [GHC] #10667: '-g' option generates invalid assembly when '*/*' operator is used In-Reply-To: <045.7de7e3e8915f886ced608adea09f7f67@haskell.org> References: <045.7de7e3e8915f886ced608adea09f7f67@haskell.org> Message-ID: <060.ab077559fc2939eb48b769662ca29791@haskell.org> #10667: '-g' option generates invalid assembly when '*/*' operator is used -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1386 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"e272ab99f60884e5c510c9597fbdb1a570eedcaa/ghc" e272ab9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e272ab99f60884e5c510c9597fbdb1a570eedcaa" x86 codegen: don't generate location comments The following source snippet 'module A where x */* y = 42' when being compiled with '-g' option emits syntactically invalid comment for GNU as: .text .align 8 .loc 1 3 1 /* */* */ Fixed by not emitting comments at all. We already suppress all asm comments in 'X86/Ppr.hs'. Signed-off-by: Sergei Trofimovich Test Plan: added test and check it works Reviewers: scpmw, simonmar, austin, bgamari Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1386 GHC Trac Issues: #10667 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 29 23:05:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Oct 2015 23:05:51 -0000 Subject: [GHC] #10667: '-g' option generates invalid assembly when '*/*' operator is used In-Reply-To: <045.7de7e3e8915f886ced608adea09f7f67@haskell.org> References: <045.7de7e3e8915f886ced608adea09f7f67@haskell.org> Message-ID: <060.3259d30144d785fb4459a9af6888b40f@haskell.org> #10667: '-g' option generates invalid assembly when '*/*' operator is used -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2-rc2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1386 Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 00:02:13 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 00:02:13 -0000 Subject: [GHC] #7608: LLVM only handles a hard-coded list of triples. In-Reply-To: <049.5e6798700ded89ff697ada495d9b6a1a@haskell.org> References: <049.5e6798700ded89ff697ada495d9b6a1a@haskell.org> Message-ID: <064.8ba51d5dc9bb4c336670fc979c5c6ff8@haskell.org> #7608: LLVM only handles a hard-coded list of triples. -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.7 Resolution: | Keywords: cross- | compiling llvm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: 7610 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 03:24:36 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 03:24:36 -0000 Subject: [GHC] #11034: ghc 7.10.2 testsuite: "T367(normal)" test compilation fails In-Reply-To: <048.7bcba4146771a0fa18b97c4cde40ecf0@haskell.org> References: <048.7bcba4146771a0fa18b97c4cde40ecf0@haskell.org> Message-ID: <063.8af8b9832412e49230aba4598982a04d@haskell.org> #11034: ghc 7.10.2 testsuite: "T367(normal)" test compilation fails ---------------------------------+---------------------------------------- Reporter: dtonhofer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.2 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 dtonhofer): I wrote up how I compiled GHC from scratch here: http://superuser.com/questions/991190/compile-glasgow-haskell-compiler-on- fedora-22 with the test run at the very end. If you want I can give you the credentials to the EC2 machine used in setting this up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 03:49:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 03:49:16 -0000 Subject: [GHC] #11036: powerpc/linux: undefined reference to `__sync_sub_and_fetch_8 Message-ID: <044.03dbeea328f18da62d1371f8a42e95d7@haskell.org> #11036: powerpc/linux: undefined reference to `__sync_sub_and_fetch_8 --------------------------------+---------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Linux Architecture: powerpc | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- Ever since [changeset:"04e8366608fee4f5e3358acc855bc6f556c3f508/ghc"] I've been getting this on powerpc/linux: {{{ /home/erikd/Git/ghc-upstream/rts/dist/build/libHSrts.a(Linker.o): In function `m32_free_internal': /home/erikd/Git/ghc-upstream/rts/Linker.c:1220:0: error: undefined reference to `__sync_sub_and_fetch_8' collect2: error: ld returned 1 exit status }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 04:03:36 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 04:03:36 -0000 Subject: [GHC] #11036: powerpc/linux: undefined reference to `__sync_sub_and_fetch_8 In-Reply-To: <044.03dbeea328f18da62d1371f8a42e95d7@haskell.org> References: <044.03dbeea328f18da62d1371f8a42e95d7@haskell.org> Message-ID: <059.daf21e80c2327b9a16b65effbbe24aa4@haskell.org> #11036: powerpc/linux: undefined reference to `__sync_sub_and_fetch_8 ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Changes (by erikd): * owner: => erikd Comment: Looks like the following fix will work. {{{ diff --git a/rts/Linker.c b/rts/Linker.c index 98969b9..e7bb8f0 100644 --- a/rts/Linker.c +++ b/rts/Linker.c @@ -1217,7 +1217,7 @@ static void m32_allocator_init(m32_allocator m32) { * You shouldn't have to use this method. Use `m32_free` instead. */ static void m32_free_internal(void * addr) { - uint64_t c = __sync_sub_and_fetch((uint64_t*)addr, 1); + uintptr_t c = __sync_sub_and_fetch((uintptr_t*)addr, 1); if (c == 0) { munmapForLinker(addr, getPageSize()); } }}} Need to test on powerpc, x86_64 and arm at least. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 04:37:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 04:37:00 -0000 Subject: [GHC] #11036: powerpc/linux: undefined reference to `__sync_sub_and_fetch_8 In-Reply-To: <044.03dbeea328f18da62d1371f8a42e95d7@haskell.org> References: <044.03dbeea328f18da62d1371f8a42e95d7@haskell.org> Message-ID: <059.5bbd91b8d6f3616e3a92246690edd8c9@haskell.org> #11036: powerpc/linux: undefined reference to `__sync_sub_and_fetch_8 ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1399 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by erikd): * differential: => Phab:D1399 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 08:26:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 08:26:26 -0000 Subject: [GHC] #11037: Expose pop count primitives to cmm Message-ID: <045.50f16c88a6c36cd2e458bb6789421d32@haskell.org> #11037: Expose pop count primitives to cmm -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I can't actually invoke the various `MO_PopCnt width` prim ops from the literal Cmm syntax. Would it be possible to expose them via `machOps` in `CmmParse.y` as `popcnt8`, `popcnt16`, etc.? This would enable me to generate much more efficient code. I started hacking up a mostly Cmm-side implementation of a HashMap. This lets me directly index into fields in data constructors and the like, eliding the indirection of the array machinery and allowing a much more direct implementation. Other than this, until this point it has been going remarkably smoothly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 08:53:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 08:53:49 -0000 Subject: [GHC] #11036: powerpc/linux: undefined reference to `__sync_sub_and_fetch_8 In-Reply-To: <044.03dbeea328f18da62d1371f8a42e95d7@haskell.org> References: <044.03dbeea328f18da62d1371f8a42e95d7@haskell.org> Message-ID: <059.73e2e009e6469901ec880e7482d26cf2@haskell.org> #11036: powerpc/linux: undefined reference to `__sync_sub_and_fetch_8 ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1399 Wiki Page: | ----------------------------------------+---------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"8ddf41744ea8b0c1d034f9c5e062b0112d3d3aff/ghc" 8ddf4174/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8ddf41744ea8b0c1d034f9c5e062b0112d3d3aff" Linker: Fix type in m32_free_internal The code: uint64_t c = __sync_sub_and_fetch((uint64_t*)addr, 1); was causing GCC to emit atomic instructions for 64 bit values which are not available on PowerPC. However, since PowerPC only has a 32 bit address space, use of a 64 bit value is superflous. Switching the type from `uint64_t` to `uintptr_t` should simply do the correct thing on all 32 and 64 bit architectures. Reviewers: austin, bgamari, simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1399 GHC Trac Issues: #11036 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 11:27:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 11:27:17 -0000 Subject: [GHC] #10890: Incorrect redundant import warning for type classes In-Reply-To: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> References: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> Message-ID: <060.e9f0c80b0174e2480e2aa12303766d45@haskell.org> #10890: Incorrect redundant import warning for type classes -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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:D1257 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"9376249b6b78610db055a10d05f6592d6bbbea2f/ghc" 9376249/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9376249b6b78610db055a10d05f6592d6bbbea2f" Fix unused-import stuff in a better way The fix for Trac #10890 in commit 1818b48, namely Fix incorrect import warnings when methods with identical names are imported was wrong, as demonstrated by the new test T10890_2. It suppressed far too many warnings! This patch fixes the original problem in a different way, by making RdrName.greUsedRdrName a bit cleverer. But this too is not really the Right Thing. I think the Right Thing is to store the /GRE/ in the tcg_used_rdrnames, not the /RdrName/. That would be a lot simpler and more direct. But one step at a time. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 11:27:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 11:27:17 -0000 Subject: [GHC] #10928: Refine pattern synonym signatures In-Reply-To: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> References: <049.0f879fe3e05dc4bb2373b37c81634439@haskell.org> Message-ID: <064.b50f76345489e843bfc0714a99a015fc@haskell.org> #10928: Refine pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | 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 Simon Peyton Jones ): In [changeset:"9b3a0588e7523db54443270005ba2c6016e56ab8/ghc" 9b3a058/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9b3a0588e7523db54443270005ba2c6016e56ab8" Swap prov/req in variable naming in Parser.y This is a follow on to the patch for Trac #10928. It's a local renaming of variables only; no change in behaviour. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 11:37:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 11:37:48 -0000 Subject: [GHC] #10890: Incorrect redundant import warning for type classes In-Reply-To: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> References: <045.1d7793ff19c595f6fc025366df90cb33@haskell.org> Message-ID: <060.c2e08b4f9d64f111e409f9079dcb42ed@haskell.org> #10890: Incorrect redundant import warning for type classes -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | warnings/should_compile/T10890, | T10890_1, T10890_2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1257 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => warnings/should_compile/T10890, T10890_1, T10890_2 Comment: I followed up with this {{{ commit 3e94842d4d1258fbd6a1202bf74d41ce1d01c753 Author: Simon Peyton Jones Date: Fri Oct 30 09:41:47 2015 +0000 Record usage information using GlobalRdrElt This patch implements an improvment that I've wanted to do for ages, but never gotten around to. Unused imports are computed based on how imported entities occur (qualified, unqualified). This info was accumulated in tcg_used_rdrnames :: Set RdrName. But that was a huge pain, and it got worse when we introduced duplicate record fields. The Right Thing is to record tcg_used_gres :: [GlobalRdrElt], which records the GRE *after* filtering with pickGREs. See Note [GRE filtering] in RdrName. This is much, much bette. This patch deletes quite a bit of code, and is conceptually much easier to follow. Hooray. There should be no change in functionality. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 11:54:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 11:54:28 -0000 Subject: [GHC] #10976: Applicative Comprehensions In-Reply-To: <046.b8fb42a1a67c05a5fd3b2ee681f1abcf@haskell.org> References: <046.b8fb42a1a67c05a5fd3b2ee681f1abcf@haskell.org> Message-ID: <061.951c448ccf50e1f49b4506d680dbf4e4@haskell.org> #10976: Applicative Comprehensions -------------------------------------+------------------------------------- Reporter: davidar | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8914 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by thomie: Old description: > As discussed on `ghc-devs`, when both the `MonadComprehensions` and > `ApplicativeDo` language extensions are enabled, it should be possible to > use comprehension-notation (in addition to do-notation) for > `Applicative`s. This would allow, for example, an expression like > > {{{#!hs > (\x y -> x + 2*y) <$> ZipList [1..10] <*> ZipList [10,20..100] > }}} > > to also be written as > > {{{#!hs > [ x + 2*y | x <- ZipList [1..10], y <- ZipList [10,20..100] ] > }}} New description: As discussed on [https://mail.haskell.org/pipermail/ghc- devs/2015-October/010062.html ghc-devs], when both the `MonadComprehensions` and `ApplicativeDo` language extensions are enabled, it should be possible to use comprehension-notation (in addition to do- notation) for `Applicative`s. This would allow, for example, an expression like {{{#!hs (\x y -> x + 2*y) <$> ZipList [1..10] <*> ZipList [10,20..100] }}} to also be written as {{{#!hs [ x + 2*y | x <- ZipList [1..10], y <- ZipList [10,20..100] ] }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 12:14:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 12:14:41 -0000 Subject: [GHC] #11034: ghc 7.10.2 testsuite: "T367(normal)" test compilation fails In-Reply-To: <048.7bcba4146771a0fa18b97c4cde40ecf0@haskell.org> References: <048.7bcba4146771a0fa18b97c4cde40ecf0@haskell.org> Message-ID: <063.aeb0e6655b774ef0ffc2143bd448bde3@haskell.org> #11034: ghc 7.10.2 testsuite: "T367(normal)" test compilation fails ---------------------------------+---------------------------------------- Reporter: dtonhofer | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 12:23:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 12:23:26 -0000 Subject: [GHC] #11006: Warning: Glomming in Main In-Reply-To: <045.7166ee4256f525a9bdeeeecfa550ca07@haskell.org> References: <045.7166ee4256f525a9bdeeeecfa550ca07@haskell.org> Message-ID: <060.48e15d95b3e842d88eb4a42e3058000c@haskell.org> #11006: Warning: Glomming in Main -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"268aa9a2ee98d800594875c930cfcd76cb5e221b/ghc" 268aa9a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="268aa9a2ee98d800594875c930cfcd76cb5e221b" integerConstantFolding: when(compiler_debugged(), expect_broken(#11006)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 12:26:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 12:26:46 -0000 Subject: [GHC] #11012: Support for unicode primes on identifiers. In-Reply-To: <048.363b1ce44ead0d11a6975760504f792b@haskell.org> References: <048.363b1ce44ead0d11a6975760504f792b@haskell.org> Message-ID: <063.9a387241e30b00244ea11d02e4371134@haskell.org> #11012: Support for unicode primes on identifiers. -------------------------------------+------------------------------------- Reporter: ghartshaw | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Keywords: unicode, Resolution: | report-impact 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 thomie): * keywords: => unicode, report-impact -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 12:52:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 12:52:28 -0000 Subject: [GHC] #10972: Add a :binfo (beginner info) GHCi command In-Reply-To: <045.69c25027f6e9192e0896957840c11b0e@haskell.org> References: <045.69c25027f6e9192e0896957840c11b0e@haskell.org> Message-ID: <060.10f9bf7be8d0e3ec74ee78493bbf0a46@haskell.org> #10972: Add a :binfo (beginner info) GHCi command -------------------------------------+------------------------------------- Reporter: kanetw | Owner: kanetw Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kanetw): I'll write out a specification soon[tm] (https://ghc.haskell.org/trac/ghc/wiki/Proposal/SpecializationInfo). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 13:00:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 13:00:46 -0000 Subject: [GHC] #11037: Expose pop count primitives to cmm In-Reply-To: <045.50f16c88a6c36cd2e458bb6789421d32@haskell.org> References: <045.50f16c88a6c36cd2e458bb6789421d32@haskell.org> Message-ID: <060.d8b2146eaeb407e5441762e1820de11d@haskell.org> #11037: Expose pop count primitives to cmm -------------------------------------+------------------------------------- Reporter: ekmett | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari Comment: Sure. Patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 13:13:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 13:13:17 -0000 Subject: [GHC] #11033: ghc 7.10.2 testsuite: "DoParamM(normal)" test fails In-Reply-To: <048.1c7db3aeebf6a66b725d369df661d4e5@haskell.org> References: <048.1c7db3aeebf6a66b725d369df661d4e5@haskell.org> Message-ID: <063.e6be399d7b897c4683e27863c25185dc@haskell.org> #11033: ghc 7.10.2 testsuite: "DoParamM(normal)" test fails ---------------------------------+-------------------------------------- Reporter: dtonhofer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by thomie): Please try again when the 7.10.3 release candidate is out (real soon now). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 14:44:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 14:44:02 -0000 Subject: [GHC] #11037: Expose pop count primitives to cmm In-Reply-To: <045.50f16c88a6c36cd2e458bb6789421d32@haskell.org> References: <045.50f16c88a6c36cd2e458bb6789421d32@haskell.org> Message-ID: <060.126b690e8e2f42cb6b100c5f42aa3451@haskell.org> #11037: Expose pop count primitives to cmm -------------------------------------+------------------------------------- Reporter: ekmett | Owner: bgamari Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 14:44:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 14:44:18 -0000 Subject: [GHC] #11037: Expose pop count primitives to cmm In-Reply-To: <045.50f16c88a6c36cd2e458bb6789421d32@haskell.org> References: <045.50f16c88a6c36cd2e458bb6789421d32@haskell.org> Message-ID: <060.b928f9d8b7f670d6274a415060c42d6b@haskell.org> #11037: Expose pop count primitives to cmm -------------------------------------+------------------------------------- Reporter: ekmett | Owner: bgamari Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: PopCnt Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1402 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => PopCnt * differential: => Phab:D1402 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 15:25:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 15:25:38 -0000 Subject: [GHC] #10871: Implement "fat" interface files which can be directly compiled without source In-Reply-To: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> References: <045.f4306fd46ddf30e7464e9ea8971267bf@haskell.org> Message-ID: <060.172b5bf9827f036c0553b40faefa4547@haskell.org> #10871: Implement "fat" interface files which can be directly compiled without source -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: backpack 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 skilpat): * cc: skilpat (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 16:46:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 16:46:31 -0000 Subject: [GHC] #10374: Can't build GHC with a dynamic only GHC installation In-Reply-To: <047.5b2f040bca29d3e5d41bd8a4d0f768d7@haskell.org> References: <047.5b2f040bca29d3e5d41bd8a4d0f768d7@haskell.org> Message-ID: <062.63428563d5b0d41cd5c17ef38ae292c2@haskell.org> #10374: Can't build GHC with a dynamic only GHC installation -------------------------------------+------------------------------------- Reporter: jessicah | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.1 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): -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"314395e00be10e6343840c215a4779aeec2542df/ghc" 314395e0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="314395e00be10e6343840c215a4779aeec2542df" Build system: cabalise deriveConstants + genprimopcode This is needed for #10374 (but doesn't fix it yet). Also rename DeriveConstants.hs to Main.hs, because the build system has trouble with Main modules not called Main.hs. Differential Revision: https://phabricator.haskell.org/D1380 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 17:03:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 17:03:34 -0000 Subject: [GHC] #11032: Missing result type handling for State# s in foreign import prim. In-Reply-To: <045.864636ea7945cdc0bca5fad7c6cfe665@haskell.org> References: <045.864636ea7945cdc0bca5fad7c6cfe665@haskell.org> Message-ID: <060.740ceb52afdc86cb44796e1f016267dd@haskell.org> #11032: Missing result type handling for State# s in foreign import prim. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I see in `TcType` this comment: {{{ Note [Marshalling VoidRep] ~~~~~~~~~~~~~~~~~~~~~~~~~~ We don't treat State# (whose PrimRep is VoidRep) as marshalable. In turn that means you can't write foreign import foo :: Int -> State# RealWorld Reason: the back end falls over with panic "primRepHint:VoidRep"; and there is no compelling reason to permit it }}} I don't think there is any fundamental reason not to allow this. Would someone like to free it up? It'd mean looking at that `ptrRepHint` stuff. Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 18:26:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 18:26:23 -0000 Subject: [GHC] #11021: Document best practices for bringing up Sphinx on Windows In-Reply-To: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> References: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> Message-ID: <061.dbef7e99dcad7b121fb38219e69e336c@haskell.org> #11021: Document best practices for bringing up Sphinx on Windows ----------------------------------+---------------------------------------- Reporter: bgamari | Owner: Phyx- Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Changes (by Phyx-): * owner: => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 19:15:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 19:15:11 -0000 Subject: [GHC] #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> References: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> Message-ID: <065.f7dec0000825f5db9e62569ef22f4364@haskell.org> #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #10682 | Differential Rev(s): Phab:D1405 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D1354 => Phab:D1405 Comment: `getrlimit` and friends seem to be a bit finicky. The new approach (Phab:D1405) is just to successively reduce the allocation size until we find a size that the kernel will give us. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 19:17:45 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 19:17:45 -0000 Subject: [GHC] #10458: GHCi fails to load shared object (the 'impossible' happened) In-Reply-To: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> References: <046.4114d092404072b00fcfc0e155d0e19b@haskell.org> Message-ID: <061.86643d0c325884ada3e407dd4208ffa8@haskell.org> #10458: GHCi fails to load shared object (the 'impossible' happened) ---------------------------------+-------------------------------------- Reporter: rleslie | Owner: trommler Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by mboes): Replying to [comment:17 trommler]: > Perhaps it is better to go for option one in my comment:12 and load C libraries with `RTLD_GLOBAL` after all. > > I'll take a look. Any luck? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 19:20:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 19:20:07 -0000 Subject: [GHC] #11037: Expose pop count primitives to cmm In-Reply-To: <045.50f16c88a6c36cd2e458bb6789421d32@haskell.org> References: <045.50f16c88a6c36cd2e458bb6789421d32@haskell.org> Message-ID: <060.f201af48f0b1b9888aaf31f2badd6610@haskell.org> #11037: Expose pop count primitives to cmm -------------------------------------+------------------------------------- Reporter: ekmett | Owner: bgamari Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: PopCnt Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1402 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"42e85284b7be4aa298cff51119f33a72c0e3bd7a/ghc" 42e8528/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="42e85284b7be4aa298cff51119f33a72c0e3bd7a" CmmParse: Expose popcnt operations Make various population count operations available via C-- syntax under the names %popcnt{8,16,32,64}. Fixes #11037. Reviewers: simonmar, austin, ekmett Reviewed By: austin, ekmett Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1402 GHC Trac Issues: #11037 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 19:20:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 19:20:08 -0000 Subject: [GHC] #11022: Invalid ELF "note" section format In-Reply-To: <045.8f29382f96dd0bd7affe58790341c9d8@haskell.org> References: <045.8f29382f96dd0bd7affe58790341c9d8@haskell.org> Message-ID: <060.65c0fd468b748b60ab350c206b6278a2@haskell.org> #11022: Invalid ELF "note" section format ---------------------------+---------------------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Driver | Version: 7.10.2 Resolution: | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1375 Wiki Page: | ---------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"f78b477bd0ba1f85089c515259c9e3145abd1f7b/ghc" f78b477b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f78b477bd0ba1f85089c515259c9e3145abd1f7b" driver: use PROGBITS type for .debug-ghc-link-info section Previously the `.debug-ghc-link-info` section was of type `SHT_NOTE` but this is not compliant with the ELF specification, which requires that `NOTE` sections are in a particular record-based format. We mark this section as `PROGBITS` instead, which is defined as implying no particular format. Fixes #11022. Reviewers: bgamari, austin Reviewed By: bgamari, austin Subscribers: thomie, hsyl20 Differential Revision: https://phabricator.haskell.org/D1375 GHC Trac Issues: #11022 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 19:25:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 19:25:15 -0000 Subject: [GHC] #11037: Expose pop count primitives to cmm In-Reply-To: <045.50f16c88a6c36cd2e458bb6789421d32@haskell.org> References: <045.50f16c88a6c36cd2e458bb6789421d32@haskell.org> Message-ID: <060.6a984f24136b59bed81dc7d891f12d85@haskell.org> #11037: Expose pop count primitives to cmm -------------------------------------+------------------------------------- Reporter: ekmett | Owner: bgamari Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: PopCnt Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1402 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: It has been done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 19:25:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 19:25:26 -0000 Subject: [GHC] #11037: Expose pop count primitives to cmm In-Reply-To: <045.50f16c88a6c36cd2e458bb6789421d32@haskell.org> References: <045.50f16c88a6c36cd2e458bb6789421d32@haskell.org> Message-ID: <060.c3c0040aca5aca79207f8c3eaf2c35f0@haskell.org> #11037: Expose pop count primitives to cmm -------------------------------------+------------------------------------- Reporter: ekmett | Owner: bgamari Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: PopCnt Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1402 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 19:26:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 19:26:18 -0000 Subject: [GHC] #11036: powerpc/linux: undefined reference to `__sync_sub_and_fetch_8 In-Reply-To: <044.03dbeea328f18da62d1371f8a42e95d7@haskell.org> References: <044.03dbeea328f18da62d1371f8a42e95d7@haskell.org> Message-ID: <059.db9443742b2165c6c3fd8d1b45d5688b@haskell.org> #11036: powerpc/linux: undefined reference to `__sync_sub_and_fetch_8 ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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:D1399 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 19:27:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 19:27:12 -0000 Subject: [GHC] #11022: Invalid ELF "note" section format In-Reply-To: <045.8f29382f96dd0bd7affe58790341c9d8@haskell.org> References: <045.8f29382f96dd0bd7affe58790341c9d8@haskell.org> Message-ID: <060.5b5ce0cd80e59f82e8529f2c4b63859a@haskell.org> #11022: Invalid ELF "note" section format ---------------------------+---------------------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Driver | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1375 Wiki Page: | ---------------------------+---------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Fixed. Thanks hsyl20! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 19:27:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 19:27:43 -0000 Subject: [GHC] #11038: No more unsafePerformIO.com Message-ID: <054.1ee02216393bdfeb23e8e455b8f75421@haskell.org> #11038: No more unsafePerformIO.com -------------------------------------+------------------------------------- Reporter: | Owner: doismellburning | Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 7.10.2 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: -------------------------------------+------------------------------------- According to https://wiki.haskell.org/Haskell_program_coverage > The latest version is version 0.4 and can be found at: http://projects.unsafePerformIO.com/hpc That's no longer the case given unsafeperformio.com doesn't resolve any more! If I knew what URL to use, I'd attempt to change it myself ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 19:45:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 19:45:35 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.6be48bf065e97349ad197ff27fdb6ba4@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T9858a,b,c; | should_run/T9858b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D652 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"91c6b1f54aea658b0056caec45655475897f1972/ghc" 91c6b1f5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="91c6b1f54aea658b0056caec45655475897f1972" Generate Typeable info at definition sites This is the second attempt at merging D757. This patch implements the idea floated in Trac #9858, namely that we should generate type-representation information at the data type declaration site, rather than when solving a Typeable constraint. However, this turned out quite a bit harder than I expected. I still think it's the right thing to do, and it's done now, but it was quite a struggle. See particularly * Note [Grand plan for Typeable] in TcTypeable (which is a new module) * Note [The overall promotion story] in DataCon (clarifies existing stuff) The most painful bit was that to generate Typeable instances (ie TyConRepName bindings) for every TyCon is tricky for types in ghc-prim etc: * We need to have enough data types around to *define* a TyCon * Many of these types are wired-in Also, to minimise the code generated for each data type, I wanted to generate pure data, not CAFs with unpackCString# stuff floating about. Performance ~~~~~~~~~~~ Three perf/compiler tests start to allocate quite a bit more. This isn't surprising, because they all allocate zillions of data types, with practically no other code, esp. T1969 * T1969: GHC allocates 19% more * T4801: GHC allocates 13% more * T5321FD: GHC allocates 13% more * T9675: GHC allocates 11% more * T783: GHC allocates 11% more * T5642: GHC allocates 10% more I'm treating this as acceptable. The payoff comes in Typeable-heavy code. Remaining to do ~~~~~~~~~~~~~~~ * I think that "TyCon" and "Module" are over-generic names to use for the runtime type representations used in GHC.Typeable. Better might be "TrTyCon" and "TrModule". But I have not yet done this * Add more info the the "TyCon" e.g. source location where it was defined * Use the new "Module" type to help with Trac Trac #10068 * It would be possible to generate TyConRepName (ie Typeable instances) selectively rather than all the time. We'd need to persist the information in interface files. Lacking a motivating reason I have not done this, but it would not be difficult. Refactoring ~~~~~~~~~~~ As is so often the case, I ended up refactoring more than I intended. In particular * In TyCon, a type *family* (whether type or data) is repesented by a FamilyTyCon * a algebraic data type (including data/newtype instances) is represented by AlgTyCon This wasn't true before; a data family was represented as an AlgTyCon. There are some corresponding changes in IfaceSyn. * Also get rid of the (unhelpfully named) tyConParent. * In TyCon define 'Promoted', isomorphic to Maybe, used when things are optionally promoted; and use it elsewhere in GHC. * Cleanup handling of knownKeyNames * Each TyCon, including promoted TyCons, contains its TyConRepName, if it has one. This is, in effect, the name of its Typeable instance. Updates haddock submodule Test Plan: Let Harbormaster validate Reviewers: austin, hvr, goldfire Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D1404 GHC Trac Issues: #9858 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 19:45:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 19:45:35 -0000 Subject: [GHC] #10068: Make the runtime reflection API for names, modules, locations more systematic In-Reply-To: <046.e24e266e9d617fc4224d115c2a203db8@haskell.org> References: <046.e24e266e9d617fc4224d115c2a203db8@haskell.org> Message-ID: <061.69637c167e620ca23b8a9f683a43b125@haskell.org> #10068: Make the runtime reflection API for names, modules, locations more systematic -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"91c6b1f54aea658b0056caec45655475897f1972/ghc" 91c6b1f5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="91c6b1f54aea658b0056caec45655475897f1972" Generate Typeable info at definition sites This is the second attempt at merging D757. This patch implements the idea floated in Trac #9858, namely that we should generate type-representation information at the data type declaration site, rather than when solving a Typeable constraint. However, this turned out quite a bit harder than I expected. I still think it's the right thing to do, and it's done now, but it was quite a struggle. See particularly * Note [Grand plan for Typeable] in TcTypeable (which is a new module) * Note [The overall promotion story] in DataCon (clarifies existing stuff) The most painful bit was that to generate Typeable instances (ie TyConRepName bindings) for every TyCon is tricky for types in ghc-prim etc: * We need to have enough data types around to *define* a TyCon * Many of these types are wired-in Also, to minimise the code generated for each data type, I wanted to generate pure data, not CAFs with unpackCString# stuff floating about. Performance ~~~~~~~~~~~ Three perf/compiler tests start to allocate quite a bit more. This isn't surprising, because they all allocate zillions of data types, with practically no other code, esp. T1969 * T1969: GHC allocates 19% more * T4801: GHC allocates 13% more * T5321FD: GHC allocates 13% more * T9675: GHC allocates 11% more * T783: GHC allocates 11% more * T5642: GHC allocates 10% more I'm treating this as acceptable. The payoff comes in Typeable-heavy code. Remaining to do ~~~~~~~~~~~~~~~ * I think that "TyCon" and "Module" are over-generic names to use for the runtime type representations used in GHC.Typeable. Better might be "TrTyCon" and "TrModule". But I have not yet done this * Add more info the the "TyCon" e.g. source location where it was defined * Use the new "Module" type to help with Trac Trac #10068 * It would be possible to generate TyConRepName (ie Typeable instances) selectively rather than all the time. We'd need to persist the information in interface files. Lacking a motivating reason I have not done this, but it would not be difficult. Refactoring ~~~~~~~~~~~ As is so often the case, I ended up refactoring more than I intended. In particular * In TyCon, a type *family* (whether type or data) is repesented by a FamilyTyCon * a algebraic data type (including data/newtype instances) is represented by AlgTyCon This wasn't true before; a data family was represented as an AlgTyCon. There are some corresponding changes in IfaceSyn. * Also get rid of the (unhelpfully named) tyConParent. * In TyCon define 'Promoted', isomorphic to Maybe, used when things are optionally promoted; and use it elsewhere in GHC. * Cleanup handling of knownKeyNames * Each TyCon, including promoted TyCons, contains its TyConRepName, if it has one. This is, in effect, the name of its Typeable instance. Updates haddock submodule Test Plan: Let Harbormaster validate Reviewers: austin, hvr, goldfire Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D1404 GHC Trac Issues: #9858 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 19:52:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 19:52:49 -0000 Subject: [GHC] #11039: Panic with incorrect pattern synonym signature Message-ID: <049.d27e3ae5d026b330a69421484a0cabf6@haskell.org> #11039: Panic with incorrect pattern synonym signature -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE PatternSynonyms #-} module Foo () where data A a = A a pattern Q :: () => (A ~ f) => a -> f a pattern Q a = A a }}} error with HEAD {{{ poly-export2.hs:7:9: error:ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151030 for x86_64-apple-darwin): No skolem info: f_amp[sk] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 20:06:40 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 20:06:40 -0000 Subject: [GHC] #8761: Make pattern synonyms work with Template Haskell In-Reply-To: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> References: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> Message-ID: <062.d0484f3a8d7610fd06b39298d20c3868@haskell.org> #8761: Make pattern synonyms work with Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | 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 sboo): one motivation is for fixed points https://www.reddit.com/r/haskell/comments/3qrkzr/one_weird_trick_for_nicer_functor_fixpoints/cwhsy6i for example: {{{#!hs {-# LANGUAGE TemplateHaskell, PatternSynonyms, DeriveFunctor #-} data TreeF a r = LitF a | VarF String | BinF r Operation r deriving Functor data Operation = Add | ... makeFix ''TreeF }}} would generate: {{{#!hs type Tree a = Fix (TreeF a) pattern Lit :: a -> Tree a pattern Lit a = Fix (LitF a) pattern Var :: String -> Tree a pattern Var s = Fix (VarF s) pattern Bin :: Tree a -> Operation -> Tree a -> Tree a pattern Bin l op r = Fix (BinF l op r) }}} which would make `TreeF` as easy to use as `Tree` when using pattern matching: {{{#!hs optimize :: Tree a -> Tree a optimize (Bin (Lit x) Add (Lit y)) = Lit (x + y) optimize ... = ... }}} and still as easy when using recursion schemes: {{{#!hs evalTreeF :: Map String Integer -> TreeF Integer (Maybe Integer) -> Maybe Integer evalTreeF environment (BinF (Just l) Add (Just r)) = Just (l + r) evalTreeF ... evalTree :: Map String Integer -> Tree Integer -> Maybe Integer evalTree environment = cata (evalTreeF environment) }}} (sorry if here's the wrong place, this is my first post) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 20:49:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 20:49:58 -0000 Subject: [GHC] #11038: No more unsafePerformIO.com In-Reply-To: <054.1ee02216393bdfeb23e8e455b8f75421@haskell.org> References: <054.1ee02216393bdfeb23e8e455b8f75421@haskell.org> Message-ID: <069.3514d44978a334e9176cc0850d45ed8e@haskell.org> #11038: No more unsafePerformIO.com -------------------------------------+------------------------------------- Reporter: doismellburning | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 7.10.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 refold): I guess the wiki page should be updated to point to Hackage: https://hackage.haskell.org/package/hpc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 23:06:20 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 23:06:20 -0000 Subject: [GHC] #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) In-Reply-To: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> References: <050.ab3ee9d3ff60499476bc10d829ff13d9@haskell.org> Message-ID: <065.76d46e21f93b2fe7df3c91d59be2017d@haskell.org> #10877: x86_64: dll-split: out of memory (requested 1099512676352 bytes) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #10682 | Differential Rev(s): Phab:D1405 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f5974c88451783d4c1fb69444b10d7053be142bf/ghc" f5974c88/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f5974c88451783d4c1fb69444b10d7053be142bf" rts: Make MBLOCK_SPACE_SIZE dynamic Previously this was introduced in D524 as a compile-time constant. Sadly, this isn't flexible enough to allow for environments where ulimits restrict the maximum address space size (see, for instance, Consequently, we are forced to make this dynamic. In principle this shouldn't be so terrible as we can place both the beginning and end addresses within the same cache line, likely incurring only one or so additional instruction in HEAP_ALLOCED. Test Plan: validate Reviewers: austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1353 GHC Trac Issues: #10877 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 23:06:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 23:06:21 -0000 Subject: [GHC] #11039: Panic with incorrect pattern synonym signature In-Reply-To: <049.d27e3ae5d026b330a69421484a0cabf6@haskell.org> References: <049.d27e3ae5d026b330a69421484a0cabf6@haskell.org> Message-ID: <064.da29a40a18c0ec07be3e0665d4c03b33@haskell.org> #11039: Panic with incorrect pattern synonym signature -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: 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:"fce758c5a5a54e8cfa491c5168893854bf7e974d/ghc" fce758c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fce758c5a5a54e8cfa491c5168893854bf7e974d" Add failing test for #11039 Reviewers: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1406 GHC Trac Issues: #11039 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 30 23:06:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Oct 2015 23:06:21 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.3990de199321ad18223bf594e71b77f0@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, Wiki Page: | Phab:D1268 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a5cb27f323a0c78f61db1a3c5338045b0981850b/ghc" a5cb27f3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a5cb27f323a0c78f61db1a3c5338045b0981850b" Make type-class dictionary let binds deterministic When generating dictionary let binds in dsTcEvBinds we may end up generating them in arbitrary order according to Unique order. Consider: ``` let $dEq = GHC.Classes.$fEqInt in let $$dNum = GHC.Num.$fNumInt in ... ``` vs ``` let $dNum = GHC.Num.$fNumInt in let $dEq = GHC.Classes.$fEqInt in ... ``` The way this change fixes it is by using `UniqDFM` - a type of deterministic finite maps of things keyed on `Unique`s. This way when you pull out evidence variables corresponding to type-class dictionaries they are in deterministic order. Currently it's the order of insertion and the way it's implemented is by tagging the values with the time of insertion. Test Plan: I've added a new test case to reproduce the issue. ./validate Reviewers: ezyang, simonmar, austin, simonpj, bgamari Reviewed By: simonmar, simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1396 GHC Trac Issues: #4012 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 31 06:55:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Oct 2015 06:55:24 -0000 Subject: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> References: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> Message-ID: <060.128e6f0999ffb1fff37b4289d5f0179f@haskell.org> #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------+----------------------------- Reporter: jeffz1 | Owner: Phyx- Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Rev(s): Wiki Page: | ---------------------------------+----------------------------- Comment (by Phyx-): It seems the issue is caused by `findArchive` being unable to find any archives that are shipped using the in-place `GCC`. - It works on Linux because `findArchive` would search the standard Linux include path. - It works during compilation because `GCC` can find it's own libraries (we explicitly tell it where to look for libraries using the `gcc` wrapper around `realgcc`) So fixing the issue means using `searchForLibUsingGcc` in `findArchive` as well, which will then find the correct file. The reason for the error as it is, is because if we can't locate the library using any of the methods we have, we assume it is a system dll, or something on the system search path. e.g. if trying to load `kernel32.dll`. There is a slight issue in that the `GHCi` code (incorrectly) favors `static archives` over `dynamic` ones {{{ findDll `orElse` findArchive `orElse` tryGcc `orElse` tryGccPrefixed `orElse` assumeDll }}} This has the unwanted effect of when `kernel32` is specific as a lib, it will try to load `kernel32.a` instead of `kernel32.dll`. To solve this I have added another search function that is able to search the Windows search paths using `SearchPath` in order to find if it is a dll on the system search path. The new search order is: {{{ findDll `orElse` findSysDll `orElse` tryGcc `orElse` findArchive `orElse` assumeDll }}} (`tryGccPrefixed` was rolled into `tryGcc` so it is no longer needed at top level) This seems to be working well, it is dependent on another patch of mine so have to push that one through before this one. But patch coming soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 31 07:21:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Oct 2015 07:21:51 -0000 Subject: [GHC] #11009: Errors reading stdin on Windows In-Reply-To: <045.6536b0b9909b2bd209cff5be9e0bf17c@haskell.org> References: <045.6536b0b9909b2bd209cff5be9e0bf17c@haskell.org> Message-ID: <060.d6e439551eb6706e6e484b73ff822e5a@haskell.org> #11009: Errors reading stdin on Windows -------------------------------------+------------------------------------- Reporter: ncreep | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | 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 Phyx-): Hi, Thanks for the report. I don't seem to be able to reproduce this error on any of my `GHC` versions (`7.8.x`, `7.10.x` or `HEAD`) {{{ GHCi, version 7.11.20151029: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( test.hs, interpreted ) Ok, modules loaded: Main. *Main> readStdin (32 * 1024) a 3 *Main> readStdin (320 * 1024) a 3 }}} I assume you're running this in `GHCi` as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 31 09:58:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Oct 2015 09:58:52 -0000 Subject: [GHC] #11026: Bump `base` version to 4.9.0.0 In-Reply-To: <042.f747c2b78427a306bca14268108fcb46@haskell.org> References: <042.f747c2b78427a306bca14268108fcb46@haskell.org> Message-ID: <057.76f7e268294b22cb7f8bc3546b9ed5d2@haskell.org> #11026: Bump `base` version to 4.9.0.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"89958657ee5af52313b7eb4d32d4d9a377e05634/ghc" 89958657/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="89958657ee5af52313b7eb4d32d4d9a377e05634" Update primitive/vector submodules This is needed to prepare for #11026 as these updates relax the upper bounds on `base` to allow for `base-4.9.0.0` }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 31 10:32:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Oct 2015 10:32:03 -0000 Subject: [GHC] #11038: No more unsafePerformIO.com In-Reply-To: <054.1ee02216393bdfeb23e8e455b8f75421@haskell.org> References: <054.1ee02216393bdfeb23e8e455b8f75421@haskell.org> Message-ID: <069.25ed6247ba4ed512f429f7fe954f8da5@haskell.org> #11038: No more unsafePerformIO.com -------------------------------------+------------------------------------- Reporter: doismellburning | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Code Coverage | Version: 7.10.2 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 monoidal): * status: new => closed * resolution: => fixed Comment: I've changed it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 31 10:58:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Oct 2015 10:58:45 -0000 Subject: [GHC] #11040: Split SRT tables on Mac OS Message-ID: <045.d8c9369242df8d82f99b5632da2707c7@haskell.org> #11040: Split SRT tables on Mac OS ----------------------------------------+--------------------------------- Reporter: olsner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: ----------------------------------------+--------------------------------- Split off from https://phabricator.haskell.org/D1242#inline-11490 Mac uses subsections via symbols to allow dead code stripping, but doesn't seem to do anything special with the SRT tables (in `HscMain.doCodeGen`), so either I'm missing something or Mac doesn't actually get much useful dead code stripping at all from the subsections feature because the SRT tables would keep everything alive. Perhaps Mac should just always do SRT splitting. Looks like you need to manually add `-optl-Wl,-dead_strip` to test this, since that's not enabled by default. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 31 12:32:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Oct 2015 12:32:26 -0000 Subject: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> References: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> Message-ID: <060.0a32c0085bcf1734e390380323617b30@haskell.org> #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------+----------------------------- Reporter: jeffz1 | Owner: Phyx- Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Rev(s): Wiki Page: | ---------------------------------+----------------------------- Comment (by Kludgy): Great insight! I'm really looking forward to this patch. I presume `findSysDll` is the new function? Replying to [comment:40 Phyx-]: > It seems the issue is caused by `findArchive` being unable to find any archives that are shipped using the in-place `GCC`. > - It works on Linux because `findArchive` would search the standard Linux include path. > - It works during compilation because `GCC` can find it's own libraries (we explicitly tell it where to look for libraries using the `gcc` wrapper around `realgcc`) > > So fixing the issue means using `searchForLibUsingGcc` in `findArchive` as well, which will then find the correct file. > > The reason for the error as it is, is because if we can't locate the library using any of the methods we have, we assume it is a system dll, or something on the system search path. e.g. if trying to load `kernel32.dll`. > > There is a slight issue in that the `GHCi` code (incorrectly) favors `static archives` over `dynamic` ones > > {{{ > findDll `orElse` > findArchive `orElse` > tryGcc `orElse` > tryGccPrefixed `orElse` > assumeDll > }}} > > This has the unwanted effect of when `kernel32` is specific as a lib, it will try to load `kernel32.a` instead of `kernel32.dll`. > > To solve this I have added another search function that is able to search the Windows search paths using `SearchPath` in order to find if it is a dll on the system search path. > > The new search order is: > > {{{ > findDll `orElse` > findSysDll `orElse` > tryGcc `orElse` > findArchive `orElse` > assumeDll > }}} > > (`tryGccPrefixed` was rolled into `tryGcc` so it is no longer needed at top level) > > This seems to be working well, it is dependent on another patch of mine so have to push that one through before this one. But patch coming soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 31 12:52:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Oct 2015 12:52:37 -0000 Subject: [GHC] #11026: Bump `base` version to 4.9.0.0 In-Reply-To: <042.f747c2b78427a306bca14268108fcb46@haskell.org> References: <042.f747c2b78427a306bca14268108fcb46@haskell.org> Message-ID: <057.dc78dfec768b0654a7afdc0e840421a8@haskell.org> #11026: Bump `base` version to 4.9.0.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"62f0fbc943307d8522e6c8333caf37c6569ee873/ghc" 62f0fbc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="62f0fbc943307d8522e6c8333caf37c6569ee873" Update parallel submodule This is needed to prepare for #11026 as this update relaxes the upper bounds on `base` to allow for `base-4.9.0.0` }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 31 14:51:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Oct 2015 14:51:05 -0000 Subject: [GHC] #8761: Make pattern synonyms work with Template Haskell In-Reply-To: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> References: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> Message-ID: <062.38594f7fada2238fdc0e3f1e201ac752@haskell.org> #8761: Make pattern synonyms work with Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | 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 goldfire): This is the right place. Thanks for posting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 31 15:37:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Oct 2015 15:37:14 -0000 Subject: [GHC] #11021: Document best practices for bringing up Sphinx on Windows In-Reply-To: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> References: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> Message-ID: <061.ca73a2e9b6b96505727c2689744b17f4@haskell.org> #11021: Document best practices for bringing up Sphinx on Windows ----------------------------------+---------------------------------------- Reporter: bgamari | Owner: Phyx- Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1408 Wiki Page: | ----------------------------------+---------------------------------------- Changes (by Phyx-): * differential: => Phab:D1408 Comment: Thanks @awson -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 31 15:40:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Oct 2015 15:40:43 -0000 Subject: [GHC] #10962: Improved arithmetic primops In-Reply-To: <050.9a384d25dddf3580aebe73d3e27aa54b@haskell.org> References: <050.9a384d25dddf3580aebe73d3e27aa54b@haskell.org> Message-ID: <065.20550b6980abc61c69fb3b315d3bf8ea@haskell.org> #10962: Improved arithmetic primops -------------------------------------+------------------------------------- Reporter: nkaretnikov | Owner: nkaretnikov Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | wiki:ImprovedArithmeticPrimops | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8160f42b8dad33e47b4c73ed3f9bf889462e7bfe/ghc" 8160f42b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8160f42b8dad33e47b4c73ed3f9bf889462e7bfe" Add subWordC# on x86ish This adds a subWordC# primop which implements subtraction with overflow reporting. Reviewers: tibbe, goldfire, rwbarton, bgamari, austin, hvr Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1334 GHC Trac Issues: #10962 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 31 16:12:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Oct 2015 16:12:37 -0000 Subject: [GHC] #11009: Errors reading stdin on Windows In-Reply-To: <045.6536b0b9909b2bd209cff5be9e0bf17c@haskell.org> References: <045.6536b0b9909b2bd209cff5be9e0bf17c@haskell.org> Message-ID: <060.f28f04ecd9b08fd13a2f69a048d942d4@haskell.org> #11009: Errors reading stdin on Windows -------------------------------------+------------------------------------- Reporter: ncreep | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | 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 ncreep): It fails in `GHCi` as well. And using a `7.8` GHC yields the same error. Is there anything I can do to further pinpoint the failure? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 31 17:13:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Oct 2015 17:13:00 -0000 Subject: [GHC] #11021: Document best practices for bringing up Sphinx on Windows In-Reply-To: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> References: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> Message-ID: <061.6ee9a6d48681902adc6da6707d76744e@haskell.org> #11021: Document best practices for bringing up Sphinx on Windows ----------------------------------+---------------------------------------- Reporter: bgamari | Owner: Phyx- Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1408 Wiki Page: | ----------------------------------+---------------------------------------- Comment (by Tamar Christina ): In [changeset:"6bef55c6b561080c5ddff73f2c501e40acee86ef/ghc" 6bef55c6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6bef55c6b561080c5ddff73f2c501e40acee86ef" Fix documentation build on windows Summary: Fix building new Sphinx documenation on Windows in msys2 using Awson's patch on #11021. Install Sphinx using `pacman -S mingw-w64-$(uname -m)-python2-sphinx` Test Plan: Apply patch and ./validate Reviewers: thomie, bgamari, austin Reviewed By: thomie, bgamari Subscribers: erikd Differential Revision: https://phabricator.haskell.org/D1408 GHC Trac Issues: #11021 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 31 17:18:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Oct 2015 17:18:05 -0000 Subject: [GHC] #11021: Document best practices for bringing up Sphinx on Windows In-Reply-To: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> References: <046.0c4621633ac4967e9cb5eee4e02186fd@haskell.org> Message-ID: <061.2ce40b888bee310f40ab669b38a7caad@haskell.org> #11021: Document best practices for bringing up Sphinx on Windows ----------------------------------+---------------------------------------- Reporter: bgamari | Owner: Phyx- Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.11 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:D1408 Wiki Page: | ----------------------------------+---------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 31 18:42:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Oct 2015 18:42:27 -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.4e7b405f3ecd8af4bd2bea17d109c44a@haskell.org> #10789: Notify user when a kind mismatch holds up a type family reduction -------------------------------------+------------------------------------- Reporter: goldfire | Owner: ssequeira Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 7.10.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: | -------------------------------------+------------------------------------- Changes (by ssequeira): * owner: => ssequeira * milestone: 8.0.1 => ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 31 20:29:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Oct 2015 20:29:41 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.84789e4162ce60cfe44d5db61257db1d@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1284 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): @bgamari: I've removed words/unwords/lines/unlines. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 31 21:28:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Oct 2015 21:28:52 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.a2e895300fa885a84bff06ef689bb39f@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1284 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"8f02baac9ea3d8cf8dfbadd2bc3af799ddbc0367/ghc" 8f02baa/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8f02baac9ea3d8cf8dfbadd2bc3af799ddbc0367" Remove Data.List.NonEmpty.{words,unwords,lines,unlines} This change mirrors the change that occured for the recent `semigroups-0.18` release, i.e. https://github.com/ekmett/semigroups/commit/7a000212847b0d309892f34e4754a25ddec7100b This removal addresses concerns raised in #10365 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 31 22:00:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Oct 2015 22:00:19 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.e86ca1465c87c9d7feafa9d0ceba29ce@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1284 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): However, the real concern raised in #10365 is why Data.List.NonEmpty should be in base at all, causing extra work for GHC developers, and tying future fixes (once base is released) of this type to new versions of GHC, with no perceivable advantages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 31 23:48:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Oct 2015 23:48:35 -0000 Subject: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> References: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> Message-ID: <060.6c8073dc8e65fdf149c0f186826e42cc@haskell.org> #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------+----------------------------- Reporter: jeffz1 | Owner: Phyx- Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Rev(s): Wiki Page: | ---------------------------------+----------------------------- Comment (by Phyx-): Yup, `findSysDll` on Windows will try to see if `assumeDll` would be loading anything. on other platforms it just does a `no-op` -- Ticket URL: GHC The Glasgow Haskell Compiler