From ghc-devs at haskell.org Sun Jul 1 01:03:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jul 2018 01:03:58 -0000 Subject: [GHC] #15328: cpphs: internal error: evacuate(static): strange closure type 8440 In-Reply-To: <044.e7d3083ced1a98874e271c4b45548264@haskell.org> References: <044.e7d3083ced1a98874e271c4b45548264@haskell.org> Message-ID: <059.6342b5d130a04c97573951029bb59dab@haskell.org> #15328: cpphs: internal error: evacuate(static): strange closure type 8440 -------------------------------------+------------------------------------- Reporter: cnmne | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Package system | Version: 8.4.3 Resolution: | Keywords: cabal, cpphs, | strange closure Operating System: MacOS X | Architecture: x86 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by cnmne): * Attachment "Agda-2.5.4-8dEVcms4EEl7BLLd7N0hcZ(2).log" added. progress? second log file with only error being alex exit (-11) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 1 01:04:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jul 2018 01:04:27 -0000 Subject: [GHC] #15328: cpphs: internal error: evacuate(static): strange closure type 8440 In-Reply-To: <044.e7d3083ced1a98874e271c4b45548264@haskell.org> References: <044.e7d3083ced1a98874e271c4b45548264@haskell.org> Message-ID: <059.4bab057b5d05eea442345377afe81cce@haskell.org> #15328: cpphs: internal error: evacuate(static): strange closure type 8440 -------------------------------------+------------------------------------- Reporter: cnmne | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Package system | Version: 8.4.3 Resolution: | Keywords: cabal, cpphs, | strange closure Operating System: MacOS X | Architecture: x86 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cnmne): I had installed Haskell Core from the official site, assuming that the prerequisites (ghc, cabal-install, Alex, Happy, cpphs) would be accessible. However after manually installing cabal-install, alex, happy, and cpphs I now have a different error: {{{/Users/seth/Library/Haskell/bin/alex returned ExitFailure (-11)}}} attached is the second log file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 1 01:37:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jul 2018 01:37:27 -0000 Subject: [GHC] #15329: Cannot parse `type (*)` in fixity declaration In-Reply-To: <047.29f9825bd03c372c5062f690254f7bbf@haskell.org> References: <047.29f9825bd03c372c5062f690254f7bbf@haskell.org> Message-ID: <062.ac8d841f28e5db1a3aa14fb7f2a95b4f@haskell.org> #15329: Cannot parse `type (*)` in fixity declaration -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: Oh. Somehow I completely misunderstood this. My bad -- this is invalid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 1 02:34:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jul 2018 02:34:53 -0000 Subject: [GHC] #9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.46713beefbf60cf96754ff157306eebf@haskell.org> #9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Roles, Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T9123{,a} Blocked By: 15290 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I agree that would be very ad-hoc, but I wasn't quite thinking of doing the inference in the solver. Instead, we could do it in !TcDerivInfer by anticipating the need for role-based implication constraint and then providing it. It would still be ad-hoc, but it would have company, as much of the `deriving` code is very ad-hoc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 1 08:05:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jul 2018 08:05:37 -0000 Subject: [GHC] #14858: Typed hole subtitution search fails in the REPL In-Reply-To: <044.605f4aa7b63ca26feac6d76a97945eb0@haskell.org> References: <044.605f4aa7b63ca26feac6d76a97945eb0@haskell.org> Message-ID: <059.3aa93ad5373f12dec4a09e1fb98ac48f@haskell.org> #14858: Typed hole subtitution search fails in the REPL -------------------------------------+------------------------------------- Reporter: paf31 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.4.1-alpha3 checker) | Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * owner: sighingnow => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 1 09:44:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jul 2018 09:44:28 -0000 Subject: [GHC] #15087: Internal Error with Bibliography Profiling In-Reply-To: <047.4e3533cfbf44e6814004409e34e96335@haskell.org> References: <047.4e3533cfbf44e6814004409e34e96335@haskell.org> Message-ID: <062.ed1ad7c241d27df492175f682cde3d7f@haskell.org> #15087: Internal Error with Bibliography Profiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063, #15165, | Differential Rev(s): #7836 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): @crockeea, it this on i386 Linux or some other platform? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 1 09:48:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jul 2018 09:48:19 -0000 Subject: [GHC] #15306: First attempt at starting GHCI failed In-Reply-To: <044.bb0e20f9b63de8ba8466a48783a5351a@haskell.org> References: <044.bb0e20f9b63de8ba8466a48783a5351a@haskell.org> Message-ID: <059.75d9ef3f4ec78a232caa7ab1786df7c2@haskell.org> #15306: First attempt at starting GHCI failed -------------------------------------+------------------------------------- Reporter: DaleB | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 (Linker) | Resolution: invalid | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => invalid Comment: This looks to me like you had a 32bit mingw on your PATH. Removing the folder made it find the proper libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 1 10:59:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jul 2018 10:59:09 -0000 Subject: [GHC] #15313: Framework failures on windows with plugins In-Reply-To: <046.f52c74aebbb7c1bfb16082509fa8f952@haskell.org> References: <046.f52c74aebbb7c1bfb16082509fa8f952@haskell.org> Message-ID: <061.89a2634903d694e106f174b626a605b1@haskell.org> #15313: Framework failures on windows with plugins -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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:D4918 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * differential: => Phab:D4918 Comment: This patch will force these tests serially until the package registration can be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 1 10:59:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jul 2018 10:59:46 -0000 Subject: [GHC] #15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7 In-Reply-To: <048.2e4683ede5797175b196c3bdda927d9f@haskell.org> References: <048.2e4683ede5797175b196c3bdda927d9f@haskell.org> Message-ID: <063.45ddf6df14774cc9ece53502c1ae17ab@haskell.org> #15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7 -------------------------------------+------------------------------------- Reporter: ki11men0w | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: Component: ghc-pkg | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4917 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D4917 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 1 11:00:44 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jul 2018 11:00:44 -0000 Subject: [GHC] #15051: -split-objs generates excessively many files on Windows In-Reply-To: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> References: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> Message-ID: <060.903d6fd4cb1f3a9fe6b4917731389d45@haskell.org> #15051: -split-objs generates excessively many files on Windows -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Phyx- Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (CodeGen) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4915 Wiki Page: | Phab:D4916 -------------------------------------+------------------------------------- Changes (by Phyx-): * differential: => Phab:D4915 Phab:D4916 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 1 11:09:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jul 2018 11:09:24 -0000 Subject: [GHC] #15058: scc001 unexpected passes in prof way on CircleCI In-Reply-To: <046.0b378e99b79b2d6dc8ceb312b2117de0@haskell.org> References: <046.0b378e99b79b2d6dc8ceb312b2117de0@haskell.org> Message-ID: <061.c368aa379cf1f3622333075269284fbd@haskell.org> #15058: scc001 unexpected passes in prof way on CircleCI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10037 | Differential Rev(s): Phab:D4712 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => closed * differential: => Phab:D4712 * resolution: => fixed * related: #10037, #4012, #12935 => #10037 Old description: > This should supposedly fail due to #10037. New description: This was already fixed with c4219d9f7d1, but I realized this too late and actually debugged this. See below for my summary. This is also not related with #4012 (different optimization parameters of course result in different compiled code) and #12935 (Core outputs are different, not related with object code) so removing those from "related tickets". ---- The diff is not helpful because it doesn't show the original output and expected files so we miss some context. Basically with `-O0` (default, prof way) `h` is top level and gets a cost centre accordingly, but with `-O` (profasm way) it's inlined with its SCC. With -O0 (default, prof way): {{{ h_rsH = scctick case ds_r1I1 of { (h1_a1qY) -> h1_a1qY } main :: IO () main = scctick
>> GHC.Base.$fMonadIO ($ (print GHC.Show.$fShowBool) (tick GHC.Types.True)) (>> GHC.Base.$fMonadIO ($ (print GHC.Show.$fShowInt) (tick GHC.Types.I# 3#)) ($ (print GHC.Show.$fShowChar) (h_rsH (GHC.Types.C# 'a'#)))) }}} With -O (profasm WAY): {{{ Main.main2 = scc
tick case Main.main5 of { (h_a1se) -> case scc h_a1se Main.main4 of { GHC.Types.C# ds1_a1Zn -> case ds1_a1Zn of ds2_a1Zp { __DEFAULT -> GHC.Types.: GHC.Show.$fShowChar3 (GHC.Show.$wshowLitChar ds2_a1Zp Main.main3); '\''# -> GHC.Show.$fShowChar1 } } } }}} And profiling outputs are correct in both cases. prof way: (h is a CAF) {{{ COST CENTRE MODULE SRC no. entries %time %alloc %time %alloc MAIN MAIN 115 0 0.0 1.2 0.0 100.0 CAF Main 229 0 0.0 0.1 0.0 1.5 (...) Main scc001.hs:16:1-16 235 1 0.0 0.0 0.0 0.0 h Main scc001.hs:16:1-16 234 1 0.0 0.0 0.0 0.0 main Main scc001.hs:(5,1)-(7,23) 230 1 0.0 1.4 0.0 1.4 f Main scc001.hs:10:1-7 232 1 0.0 0.0 0.0 0.0 g Main scc001.hs:13:1-7 233 1 0.0 0.0 0.0 0.0 }}} profasm way: (h is inlined, no CAFs for it) {{{ COST CENTRE MODULE SRC no. entries %time %alloc %time %alloc MAIN MAIN 115 0 0.0 1.2 0.0 100.0 CAF Main 229 0 0.0 0.1 0.0 0.3 (...) Main scc001.hs:16:1-16 235 1 0.0 0.0 0.0 0.0 main Main scc001.hs:(5,1)-(7,23) 230 1 0.0 0.3 0.0 0.3 g Main scc001.hs:13:1-7 233 1 0.0 0.0 0.0 0.0 h Main scc001.hs:16:1-16 234 1 0.0 0.0 0.0 0.0 }}} Some ways to fix: - If we really want to test this with multiple ways, use two different tests depending on whether the ways add -O or not. Use two different prof.sample files. - Only test with ways that add or don't add -O, use single prof.sample. I don't understand why scc001 is considered as "unexpected pass" in the summary in CircleCI link above. In the logs I see that it actually failed, and I don't see any unexpected passes. -- Comment: This was already fixed with c4219d9f7d1, but I realized this too late (why is this ticket submitted after that patch?) and actually debugged this. See below for my summary. This is also not related with #4012 (different optimization parameters will of course give different compiled code) and #12935 (Core outputs are different, not related with object code) so removing those from "related tickets". ---- The diff is not helpful because it doesn't show the original output and expected files so we miss some context. Basically with `-O0` (default, prof way) `h` is top level and gets a cost centre accordingly, but with `-O` (profasm way) it's inlined with its SCC. With -O0 (default, prof way): {{{ h_rsH = scctick case ds_r1I1 of { (h1_a1qY) -> h1_a1qY } main :: IO () main = scctick
>> GHC.Base.$fMonadIO ($ (print GHC.Show.$fShowBool) (tick GHC.Types.True)) (>> GHC.Base.$fMonadIO ($ (print GHC.Show.$fShowInt) (tick GHC.Types.I# 3#)) ($ (print GHC.Show.$fShowChar) (h_rsH (GHC.Types.C# 'a'#)))) }}} With -O (profasm WAY): {{{ Main.main2 = scc
tick case Main.main5 of { (h_a1se) -> case scc h_a1se Main.main4 of { GHC.Types.C# ds1_a1Zn -> case ds1_a1Zn of ds2_a1Zp { __DEFAULT -> GHC.Types.: GHC.Show.$fShowChar3 (GHC.Show.$wshowLitChar ds2_a1Zp Main.main3); '\''# -> GHC.Show.$fShowChar1 } } } }}} And profiling outputs are correct in both cases. prof way: (h is a CAF) {{{ COST CENTRE MODULE SRC no. entries %time %alloc %time %alloc MAIN MAIN 115 0 0.0 1.2 0.0 100.0 CAF Main 229 0 0.0 0.1 0.0 1.5 (...) Main scc001.hs:16:1-16 235 1 0.0 0.0 0.0 0.0 h Main scc001.hs:16:1-16 234 1 0.0 0.0 0.0 0.0 main Main scc001.hs:(5,1)-(7,23) 230 1 0.0 1.4 0.0 1.4 f Main scc001.hs:10:1-7 232 1 0.0 0.0 0.0 0.0 g Main scc001.hs:13:1-7 233 1 0.0 0.0 0.0 0.0 }}} profasm way: (h is inlined, no CAFs for it) {{{ COST CENTRE MODULE SRC no. entries %time %alloc %time %alloc MAIN MAIN 115 0 0.0 1.2 0.0 100.0 CAF Main 229 0 0.0 0.1 0.0 0.3 (...) Main scc001.hs:16:1-16 235 1 0.0 0.0 0.0 0.0 main Main scc001.hs:(5,1)-(7,23) 230 1 0.0 0.3 0.0 0.3 g Main scc001.hs:13:1-7 233 1 0.0 0.0 0.0 0.0 h Main scc001.hs:16:1-16 234 1 0.0 0.0 0.0 0.0 }}} Some ways to fix: - If we really want to test this with multiple ways, use two different tests depending on whether the ways add -O or not. Use two different prof.sample files. - Only test with ways that add or don't add -O, use single prof.sample. I don't understand why scc001 is considered as "unexpected pass" in the summary in CircleCI link above. In the logs I see that it actually failed, and I don't see any unexpected passes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 1 11:10:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jul 2018 11:10:17 -0000 Subject: [GHC] #15058: scc001 unexpected passes in prof way on CircleCI In-Reply-To: <046.0b378e99b79b2d6dc8ceb312b2117de0@haskell.org> References: <046.0b378e99b79b2d6dc8ceb312b2117de0@haskell.org> Message-ID: <061.e37a496694c10090ab7b3a4ab0d3856d@haskell.org> #15058: scc001 unexpected passes in prof way on CircleCI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10037 | Differential Rev(s): Phab:D4712 Wiki Page: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: > This was already fixed with c4219d9f7d1, but I realized this too late and > actually debugged this. See below for my summary. > > This is also not related with #4012 (different optimization parameters of > course result in different compiled code) and #12935 (Core outputs are > different, not related with object code) so removing those from "related > tickets". > > ---- > > The diff is not helpful because it doesn't show the original output and > expected files so we miss some context. Basically with `-O0` (default, > prof way) `h` is top level and gets a cost centre accordingly, but with > `-O` (profasm way) it's inlined with its SCC. > > With -O0 (default, prof way): > > {{{ > h_rsH = scctick case ds_r1I1 of { (h1_a1qY) -> h1_a1qY } > > main :: IO () > main > = scctick
> >> > GHC.Base.$fMonadIO > ($ (print GHC.Show.$fShowBool) (tick GHC.Types.True)) > (>> > GHC.Base.$fMonadIO > ($ (print GHC.Show.$fShowInt) (tick GHC.Types.I# 3#)) > ($ (print GHC.Show.$fShowChar) (h_rsH (GHC.Types.C# 'a'#)))) > }}} > > With -O (profasm WAY): > > {{{ > Main.main2 > = scc
> tick > case Main.main5 of { (h_a1se) -> > case scc h_a1se Main.main4 of { GHC.Types.C# ds1_a1Zn -> > case ds1_a1Zn of ds2_a1Zp { > __DEFAULT -> > GHC.Types.: > GHC.Show.$fShowChar3 (GHC.Show.$wshowLitChar ds2_a1Zp > Main.main3); > '\''# -> GHC.Show.$fShowChar1 > } > } > } > }}} > > And profiling outputs are correct in both cases. prof way: (h is a CAF) > > {{{ > COST CENTRE MODULE SRC no. entries > %time %alloc %time %alloc > > MAIN MAIN 115 0 > 0.0 1.2 0.0 100.0 > CAF Main 229 0 > 0.0 0.1 0.0 1.5 > (...) Main scc001.hs:16:1-16 235 1 > 0.0 0.0 0.0 0.0 > h Main scc001.hs:16:1-16 234 1 > 0.0 0.0 0.0 0.0 > main Main scc001.hs:(5,1)-(7,23) 230 1 > 0.0 1.4 0.0 1.4 > f Main scc001.hs:10:1-7 232 1 > 0.0 0.0 0.0 0.0 > g Main scc001.hs:13:1-7 233 1 > 0.0 0.0 0.0 0.0 > }}} > > profasm way: (h is inlined, no CAFs for it) > > {{{ > COST CENTRE MODULE SRC no. entries > %time %alloc %time %alloc > > MAIN MAIN 115 0 > 0.0 1.2 0.0 100.0 > CAF Main 229 0 > 0.0 0.1 0.0 0.3 > (...) Main scc001.hs:16:1-16 235 1 > 0.0 0.0 0.0 0.0 > main Main scc001.hs:(5,1)-(7,23) 230 1 > 0.0 0.3 0.0 0.3 > g Main scc001.hs:13:1-7 233 1 > 0.0 0.0 0.0 0.0 > h Main scc001.hs:16:1-16 234 1 > 0.0 0.0 0.0 0.0 > }}} > > Some ways to fix: > > - If we really want to test this with multiple ways, use two different > tests depending on whether the ways add -O or not. Use two different > prof.sample files. > - Only test with ways that add or don't add -O, use single prof.sample. > > I don't understand why scc001 is considered as "unexpected pass" in the > summary in CircleCI link above. In the logs I see that it actually > failed, and I don't see any unexpected passes. New description: This should supposedly fail due to #10037. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 1 11:11:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jul 2018 11:11:43 -0000 Subject: [GHC] #15058: scc001 unexpected passes in prof way on CircleCI In-Reply-To: <046.0b378e99b79b2d6dc8ceb312b2117de0@haskell.org> References: <046.0b378e99b79b2d6dc8ceb312b2117de0@haskell.org> Message-ID: <061.8e6bda04bec593087745e5c6b5b5f15b@haskell.org> #15058: scc001 unexpected passes in prof way on CircleCI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10037 | Differential Rev(s): Phab:D4712 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): (I was modifying the ticket while also adding a new comment, and accidentally updated the wrong form and updated ticket description. I now reverted it, sorry for the noise) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 1 12:09:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jul 2018 12:09:14 -0000 Subject: [GHC] #15053: Compiler panic on invalid syntax (unterminated pragma) In-Reply-To: <047.d617a7e8bd5e9dac7c56bae30af4b445@haskell.org> References: <047.d617a7e8bd5e9dac7c56bae30af4b445@haskell.org> Message-ID: <062.35dfa2b69317cf3092b1c53ae1141d75@haskell.org> #15053: Compiler panic on invalid syntax (unterminated pragma) -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4883 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): This is easy to fix, we just need to decide on an error message. If current message is fine that we could just throw an exception instead of panicking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 1 18:35:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jul 2018 18:35:56 -0000 Subject: [GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 In-Reply-To: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> References: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> Message-ID: <066.682973381a50798fd6037a81922d8230@haskell.org> #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by NathanWaivio): * Attachment "ghc-8.4.2-v.txt" added. Attached verbose output of ghc-8.4.2. Noticed that while compiling the memory usage increased from 10GB to 32GB during CodeGen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 1 19:52:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 01 Jul 2018 19:52:48 -0000 Subject: [GHC] #14994: ghc api: `load LoadAllTargets` is not idempotent In-Reply-To: <044.059168af26f269e453b3c36e5b5a0115@haskell.org> References: <044.059168af26f269e453b3c36e5b5a0115@haskell.org> Message-ID: <059.21f5ebe8ae0f1f94969f2bffba04a718@haskell.org> #14994: ghc api: `load LoadAllTargets` is not idempotent -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: GHC API | Version: 8.4.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-e): * status: new => closed * resolution: => invalid Comment: I'm sorry, but I cannot reproduce this as described either. This is embarrassing, because I really spent a lot of time on tracking this down. But I did patch the compiler at the time, so it's possible that I ended up breaking it and never testing my findings with a pristine version. I'll have to retrace my steps. I'll hopefully find time for that after the next weekend. In the meantime I'm marking this as invalid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 00:09:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 00:09:52 -0000 Subject: [GHC] #14553: Implement native CPP In-Reply-To: <045.adf1dad4e79717b77bccedf2aee73f71@haskell.org> References: <045.adf1dad4e79717b77bccedf2aee73f71@haskell.org> Message-ID: <060.741b45a3b8d0ff0d731c9b024d025178@haskell.org> #14553: Implement native CPP -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 1290 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hgolden): I suggest putting the [https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp Proposal/NativeCpp] into [https://github.com/ghc-proposals/ghc-proposals ghc-proposals] on Github so it can follow the new process. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 01:36:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 01:36:25 -0000 Subject: [GHC] #14627: qAddTopDecls: can't convert top-level declarations In-Reply-To: <049.485d47f57c339e482133548d02dc333a@haskell.org> References: <049.485d47f57c339e482133548d02dc333a@haskell.org> Message-ID: <064.eaee12e4c4fca84a8b9e87de38d624ac@haskell.org> #14627: qAddTopDecls: can't convert top-level declarations -------------------------------------+------------------------------------- Reporter: tianxiaogu | Owner: mgsloan Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mgsloan): I've put up a patch that makes addTopDelcs no longer panic for conversion errors: https://phabricator.haskell.org/D4914 . Instead they are reported as normal errors like this: {{{ T14627.hs:3:3: error: qAddTopDecls: can't convert declarations: Illegal variable name: ‘Bool’ When splicing a TH declaration: f_0 = Bool | 3 | $(do | ^^... }}} Atop this, the error "Illegal variable name: 'Bool'" is quite poor, instead it should just say there's an out of scope constructor. I have a patch that fixes this and adds documentation to `UnboundVarE` clarifying this case. Can't push it to phabricator yet, though, because it appears to be down. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 02:12:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 02:12:11 -0000 Subject: [GHC] #14318: TH shadowing bind statement triggers -Wunused-matches In-Reply-To: <044.951fdf427e51c6e07b18c7fa19ddd812@haskell.org> References: <044.951fdf427e51c6e07b18c7fa19ddd812@haskell.org> Message-ID: <059.1507cf50f46ad02082c34e809a790e1f@haskell.org> #14318: TH shadowing bind statement triggers -Wunused-matches -------------------------------------+------------------------------------- Reporter: lyxia | Owner: mgsloan Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mgsloan): * owner: (none) => mgsloan -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 02:37:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 02:37:03 -0000 Subject: [GHC] #14318: TH shadowing bind statement triggers -Wunused-matches In-Reply-To: <044.951fdf427e51c6e07b18c7fa19ddd812@haskell.org> References: <044.951fdf427e51c6e07b18c7fa19ddd812@haskell.org> Message-ID: <059.b20f9d9ed84da28c567a3258f7612ae8@haskell.org> #14318: TH shadowing bind statement triggers -Wunused-matches -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mgsloan): * owner: mgsloan => (none) Comment: I've looked into this a bit. It looks like names created by `newName` are turned into GHC names via `mkSystemNameAt`, and integer making the name unique is used directly. See `Convert.thRdrName`. I'm guessing that code involving warnings is expecting that these unique names are unique per binding site, whereas in this case the same unique name is bound multiple times. I'm not sure what the correct approach is to fixing this. It could either be to fix the warning code, or, alternatively, have TH ensure that generated code has per-binding uniqueness. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 02:42:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 02:42:55 -0000 Subject: [GHC] #12410: Somehow detect splicing in ghci In-Reply-To: <051.68fec2e99046d2d08b438c5a4bbecc1c@haskell.org> References: <051.68fec2e99046d2d08b438c5a4bbecc1c@haskell.org> Message-ID: <066.21e1a072703fdc6fb3129f7d5bd962f1@haskell.org> #12410: Somehow detect splicing in ghci -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mgsloan): Another alternative to get ghci to do declaration splices: `{ $(makeLenses ''A) }` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 02:51:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 02:51:53 -0000 Subject: [GHC] #14318: TH shadowing bind statement triggers -Wunused-matches In-Reply-To: <044.951fdf427e51c6e07b18c7fa19ddd812@haskell.org> References: <044.951fdf427e51c6e07b18c7fa19ddd812@haskell.org> Message-ID: <059.c9f94c8694cbbc6c42e64b6c4a07e309@haskell.org> #14318: TH shadowing bind statement triggers -Wunused-matches -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mgsloan): Ah, here is a ticket about TH allowing you to produce non-unique uniques: https://ghc.haskell.org/trac/ghc/ticket/11812 So, I suspect that the proper solution here would involve making it so that TH cannot produce non-unique binding of unique names. There is some tricky stuff here, though. I can imagine a scenario where a TH user might rely on storing unique names in memory and re-using them between splices. This makes the task of further unique-ification quite non-trivial. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 02:52:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 02:52:52 -0000 Subject: [GHC] #11812: Template Haskell can induce non-unique Uniques In-Reply-To: <047.c1baa8985653a0b59eeec1328ee66507@haskell.org> References: <047.c1baa8985653a0b59eeec1328ee66507@haskell.org> Message-ID: <062.0cdd95882de85a9de7b007728c14ee2a@haskell.org> #11812: Template Haskell can induce non-unique Uniques -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mgsloan): Looks like having multiple bindings of the same unique name can also cause erroneous unused binding warnings: https://ghc.haskell.org/trac/ghc/ticket/14318 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 03:06:10 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 03:06:10 -0000 Subject: [GHC] #4222: Template Haskell lets you reify supposedly-abstract data types In-Reply-To: <046.e3ae8d54b8e418af2eef54ca9c93c353@haskell.org> References: <046.e3ae8d54b8e418af2eef54ca9c93c353@haskell.org> Message-ID: <061.b2d15ef5385581208dc502829cecc4f1@haskell.org> #4222: Template Haskell lets you reify supposedly-abstract data types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Template Haskell | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mgsloan): IMHO being able to reify stuff like this is a feature not a bug. See, for example, the http://hackage.haskell.org/package/true-name package. One thing that comes to mind here is just making it a special variety of warning when TH references things that are not imported. This way things like the "true-name" package will still be possible, but will cause warnings that can be ignored if the user chooses to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 03:59:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 03:59:26 -0000 Subject: [GHC] #8489: clean up dependency and usages handling in interface files In-Reply-To: <044.51af461702f35c8970f506002f551481@haskell.org> References: <044.51af461702f35c8970f506002f551481@haskell.org> Message-ID: <059.0677003a76326b5c4558ea190ce5e962@haskell.org> #8489: clean up dependency and usages handling in interface files -------------------------------------+------------------------------------- Reporter: errge | Owner: errge Type: task | Status: new Priority: normal | Milestone: Component: Template Haskell | 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 mgsloan): I don't understand how the explicit imports list of a module would be helpful to another module. I've never grokked the usecase for this. I suggest just changing the documentation to indicate that it is a list of usages rather than imports, to resolve this. How's that sound? Assigning this ticket to myself, to implement via documentation. Alternatively, this usages information could just get removed. Worth checking if there are uses of it on hackage. I am considering implementing reification of exports (https://ghc.haskell.org/trac/ghc/ticket/10391), which is what I think most people would want in module reification as that would be quite useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 03:59:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 03:59:50 -0000 Subject: [GHC] #8489: clean up dependency and usages handling in interface files In-Reply-To: <044.51af461702f35c8970f506002f551481@haskell.org> References: <044.51af461702f35c8970f506002f551481@haskell.org> Message-ID: <059.5ccc8e968504cd2fe78babab1c0e3984@haskell.org> #8489: clean up dependency and usages handling in interface files -------------------------------------+------------------------------------- Reporter: errge | Owner: mgsloan Type: task | Status: new Priority: normal | Milestone: Component: Template Haskell | 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: | -------------------------------------+------------------------------------- Changes (by mgsloan): * owner: errge => mgsloan -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 04:00:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 04:00:20 -0000 Subject: [GHC] #10391: Ability to get export list of TH reified module In-Reply-To: <047.4433cd04132dabf0d7e1565467e79715@haskell.org> References: <047.4433cd04132dabf0d7e1565467e79715@haskell.org> Message-ID: <062.50a8d1cdb7fdca61d2f413df5452bdda@haskell.org> #10391: Ability to get export list of TH reified module -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: mgsloan Type: feature request | Status: new Priority: low | Milestone: Component: Template Haskell | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10842 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mgsloan): * owner: (none) => mgsloan Comment: I might make progress on this, so assigning this to myself for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 07:28:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 07:28:48 -0000 Subject: [GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin In-Reply-To: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> References: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> Message-ID: <062.52b4c2f2905967c0136155cd32e15489@haskell.org> #15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | typeable,knownnat Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10348 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > This makes it possible to define "infinite" instances for any class like this: Well, how does the `KnownNat` constraint help in defining the instance for `MyClass (T n)`? Presumably, because `KnownNat` lets you use `natSign`: {{{ class KnownNat (n :: Nat) where natSing :: SNat n }}} If that's what you need for `instance MyClass (T n)`, then that makes perfect sense. But it makes no such sense for `Typeable`. How does having `KnownNat n` available help you write the `Typeable` instance? I think we just need built-in behaviour for `Typeable (n :: Nat)`, without any reference to `KnownNat`, don't we? There is ''some'' such built-in behaviour already, but I don't understand what it is, and it's clearly dodgy as this ticket shows. Would you like to elaborate your description of what happens now? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 08:20:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 08:20:57 -0000 Subject: [GHC] #15326: Add option to disable error message expression context (the 'In the expression' things) In-Reply-To: <050.d8b5750cd390deaca2bcecfe092d3c9f@haskell.org> References: <050.d8b5750cd390deaca2bcecfe092d3c9f@haskell.org> Message-ID: <065.6b5e393477dc1b6c36eb4a35a8c9eabe@haskell.org> #15326: Add option to disable error message expression context (the 'In the expression' things) -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'd be ok with someone adding such a flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 08:28:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 08:28:43 -0000 Subject: [GHC] #9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.4c1060a211e377ba7f344037a09941f0@haskell.org> #9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Roles, Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T9123{,a} Blocked By: 15290 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Instead, we could do it in TcDerivInfer by anticipating the need for role-based implication constraint and then providing it. `TcDerivInfer` works as follows: * Generate constraints * Simplify them * Decide what to quantify over I don't see where in that path we would add "anticipate the need for role- based implication constrains and provide it". Anyway I think we have bigger fish to fry! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 09:47:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 09:47:06 -0000 Subject: [GHC] #14995: QuantifiedConstraints: Incorrect pretty printing In-Reply-To: <051.242dc881fd2a4ef06fb4148e07f31348@haskell.org> References: <051.242dc881fd2a4ef06fb4148e07f31348@haskell.org> Message-ID: <066.3964ea626ad4775176999de387952f75@haskell.org> #14995: QuantifiedConstraints: Incorrect pretty printing -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 8.2.2 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mgsloan): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 10:25:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 10:25:53 -0000 Subject: [GHC] #15326: Add option to disable error message expression context (the 'In the expression' things) In-Reply-To: <050.d8b5750cd390deaca2bcecfe092d3c9f@haskell.org> References: <050.d8b5750cd390deaca2bcecfe092d3c9f@haskell.org> Message-ID: <065.375db84c66e108ce0892f46b049b40ec@haskell.org> #15326: Add option to disable error message expression context (the 'In the expression' things) -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: 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 RyanGlScott): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 12:12:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 12:12:47 -0000 Subject: [GHC] #12410: Somehow detect splicing in ghci In-Reply-To: <051.68fec2e99046d2d08b438c5a4bbecc1c@haskell.org> References: <051.68fec2e99046d2d08b438c5a4bbecc1c@haskell.org> Message-ID: <066.c7ad00572cf84e753a687fc345b832b1@haskell.org> #12410: Somehow detect splicing in ghci -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I like the suggestion in comment:5. It's short, and fairly intuitive. Perhaps we should just enshrine this in the users' guide and call this bug fixed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 12:16:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 12:16:57 -0000 Subject: [GHC] #4222: Template Haskell lets you reify supposedly-abstract data types In-Reply-To: <046.e3ae8d54b8e418af2eef54ca9c93c353@haskell.org> References: <046.e3ae8d54b8e418af2eef54ca9c93c353@haskell.org> Message-ID: <061.c5a51628e60e96433d6363bf3d16c32c@haskell.org> #4222: Template Haskell lets you reify supposedly-abstract data types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Template Haskell | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Another possibility is to restrict what can be reified in the presence of the `Safe` language extension. To my knowledge, Template Haskell's ability to reify abstract names is precisely what makes `TemplateHaskell` imply `Unsafe`, so perhaps we could regain its safety by restricting what it can do in Safe Haskell. I agree that I wouldn't want to remove the ability to reify abstract names altogether, since there are many situations where that comes in handy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 12:18:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 12:18:00 -0000 Subject: [GHC] #12410: Somehow detect splicing in ghci In-Reply-To: <051.68fec2e99046d2d08b438c5a4bbecc1c@haskell.org> References: <051.68fec2e99046d2d08b438c5a4bbecc1c@haskell.org> Message-ID: <066.33130b1ad60912ee63614b30c6967a75@haskell.org> #12410: Somehow detect splicing in ghci -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): What's wrong with comment:3? The GHCi prompt already is flexible over the type of the thing you write... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 12:21:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 12:21:38 -0000 Subject: [GHC] #15330: Error message prints invisible kind arguments in a visible matter Message-ID: <050.7a0d11dfbc8ef3463c27a79c9bdf89a1@haskell.org> #15330: Error message prints invisible kind arguments in a visible matter -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Data.Proxy data T :: forall a. a -> Type f1 :: Proxy (T True) f1 = "foo" f2 :: forall (t :: forall a. a -> Type). Proxy (t True) f2 = "foo" }}} This program doesn't typecheck (for good reason). The error messages, however, are a bit iffy: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:11:6: error: • Couldn't match expected type ‘Proxy (T 'True)’ with actual type ‘[Char]’ • In the expression: "foo" In an equation for ‘f1’: f1 = "foo" | 11 | f1 = "foo" | ^^^^^ Bug.hs:15:6: error: • Couldn't match expected type ‘Proxy (t Bool 'True)’ with actual type ‘[Char]’ • In the expression: "foo" In an equation for ‘f2’: f2 = "foo" • Relevant bindings include f2 :: Proxy (t Bool 'True) (bound at Bug.hs:15:1) | 15 | f2 = "foo" | ^^^^^ }}} Note that in the error message for `f1`, the type `T 'True` is printed correctly—the invisible `Bool` argument is omitted. However, in the error message for `f2`, this is not the case, as the type `t Bool 'True` is printed. That `Bool` is an invisible argument as well, and should not be printed without the use of, say, `-fprint-explicit-kinds`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 12:33:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 12:33:46 -0000 Subject: [GHC] #15331: -ddump-splices does not parenthesize visible type applications correctly Message-ID: <050.5bac58b457c421337e97e68faa19a271@haskell.org> #15331: -ddump-splices does not parenthesize visible type applications correctly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- So many `-ddump-splices` bugs... {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeApplications #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where import Data.Proxy $([d| f :: Proxy (Int -> Int) f = Proxy @(Int -> Int) |]) }}} {{{ $ /opt/ghc/8.6.1/bin/ghci Bug.hs GHCi, version 8.6.0.20180627: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(8,3)-(10,6): Splicing declarations [d| f_a1Dg :: Proxy (Int -> Int) f_a1Dg = Proxy @(Int -> Int) |] ======> f_a4tx :: Proxy (Int -> Int) f_a4tx = Proxy @Int -> Int }}} Ack—`Proxy @Int -> Int` should actually be `Proxy @(Int -> Int)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 12:51:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 12:51:00 -0000 Subject: [GHC] #12410: Somehow detect splicing in ghci In-Reply-To: <051.68fec2e99046d2d08b438c5a4bbecc1c@haskell.org> References: <051.68fec2e99046d2d08b438c5a4bbecc1c@haskell.org> Message-ID: <066.5a474a8bb913caeec4f2f261c1f95d85@haskell.org> #12410: Somehow detect splicing in ghci -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The GHCi prompt is only flexible because it has syntactic cues that it uses to distinguish between expressions, declarations, imports, etc. With Template Haskell splices, you have no such syntactic cues. The only way I could envision comment:3 ever being feasible is if we hacked the typechecker to treat `Q Exp` and `Q [Dec]`-returning splices differently, which is a lot of work for questionable benefit. comment:6 has the advantage that it's simple, works today, and is consistent with how other expressions and declarations are treated in GHCi (for instance, `3;` won't parse in GHCi's prompt). In light of this, I'm inclined to favor the simpler solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 12:54:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 12:54:06 -0000 Subject: [GHC] #14627: qAddTopDecls: can't convert top-level declarations In-Reply-To: <049.485d47f57c339e482133548d02dc333a@haskell.org> References: <049.485d47f57c339e482133548d02dc333a@haskell.org> Message-ID: <064.63fceccbbf3c80454b685aa89e21b9d3@haskell.org> #14627: qAddTopDecls: can't convert top-level declarations -------------------------------------+------------------------------------- Reporter: tianxiaogu | Owner: mgsloan Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4914 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * differential: => Phab:D4914 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 12:55:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 12:55:04 -0000 Subject: [GHC] #12410: Somehow detect splicing in ghci In-Reply-To: <051.68fec2e99046d2d08b438c5a4bbecc1c@haskell.org> References: <051.68fec2e99046d2d08b438c5a4bbecc1c@haskell.org> Message-ID: <066.0ce17806fa52157ec90499ec24a0aad1@haskell.org> #12410: Somehow detect splicing in ghci -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): OK -- I won't fight. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 13:40:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 13:40:20 -0000 Subject: [GHC] #15332: lintIdUnfolding could be simpler Message-ID: <049.a909e6dc2cdb6ebb060656336ed39a00@haskell.org> #15332: lintIdUnfolding could be simpler -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4919 | Wiki Page: -------------------------------------+------------------------------------- I think that `lintIdUnfolding` could use `maybeUnfoldingTemplate` rather than the complicated linting of `DFunUnfolding`. Seeing as `maybeUnfoldingTemplate` is the thing which is used when inlining, it makes sense to use that rather than some ad-hoc reconstruction. See https://phabricator.haskell.org/D4919 for the patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 13:46:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 13:46:07 -0000 Subject: [GHC] #15331: -ddump-splices does not parenthesize visible type applications correctly In-Reply-To: <050.5bac58b457c421337e97e68faa19a271@haskell.org> References: <050.5bac58b457c421337e97e68faa19a271@haskell.org> Message-ID: <065.f7f51fef113e62967789268e3e837f1f@haskell.org> #15331: -ddump-splices does not parenthesize visible type applications correctly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4920 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4920 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 13:57:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 13:57:00 -0000 Subject: [GHC] #15330: Error message prints invisible kind arguments in a visible matter In-Reply-To: <050.7a0d11dfbc8ef3463c27a79c9bdf89a1@haskell.org> References: <050.7a0d11dfbc8ef3463c27a79c9bdf89a1@haskell.org> Message-ID: <065.bb75f41c0b0e721352d663fa8e3f2c0c@haskell.org> #15330: Error message prints invisible kind arguments in a visible matter -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Unlike its cousin #15308, this ticket looks quite tricky to fix. The difference between pretty-printing the types of `f1` and `f2` is essentially the difference between pretty-printing `TyConApp` and `AppTy`. With `TyConApp`, we have convenient access to the kind of the underlying type constructor, which makes it simple to tell which of its arguments are visible or not. As an example, when we convert a `Type` to an `IfaceType` in `toIfaceTypeX`, we use this tycon kind information to convert the arguments of the tycon to `IfaceTcArgs`. Then, when pretty-printing a `Type`, we first convert to an `IfaceType`, and then determining which arguments of an `IfaceTyConApp` to print is a simple matter of checking for `ITC_Vis` or `ITC_Invis`. Things are tricker with `AppTy`. The type being applied in `AppTy` does not have its kind cached //a priori//, so in order to pretty-print `AppTy` analogously to how we pretty-print `TyConApp`, it seems like we'd have to: 1. Use `typeKind` to get the kind of the type being applied 2. Gather all of the arguments to the type (à la `collectArgs` for `Expr`s) 3. Tag which arguments are invisible (à la `IfaceTcArgs`) This sounds mighty gruesome, but I can't think of a simpler solution at the moment. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 14:37:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 14:37:32 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.f434b3a55525ed91289b81ba434795d7@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by andrewthad): * priority: normal => high Comment: Bumping this to high priority to increase make this visible in the list of important tickets for GHC 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 15:13:28 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 15:13:28 -0000 Subject: [GHC] #15333: Weird cachegrind results for binary-trees Message-ID: <044.7a98f83472ccde2b3f7411c5c885bd25@haskell.org> #15333: Weird cachegrind results for binary-trees -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research needed Component: NoFib | Version: 8.5 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): | Wiki Page: -------------------------------------+------------------------------------- I'm currently investigating an alleged regression in my branch of the late lambda lift and hit a confusing data point. Note that I'm very much relying on cachegrinds counted instructions/memory accesses for my findings. Check out the most recent version of `nofib` and run the following script: {{{#!sh #! /usr/bin/env zsh sed -i 's/import Debug.Trace//g' Main.hs # Make the following line idempotent echo "import Debug.Trace" | cat - Main.hs > Main.tmp && mv Main.tmp Main.hs # add the import for trace sed -i 's/trace "" \$ bit/bit/g' Main.hs # strip `trace $ ` prefixes in the call to `bit` ghc -O2 -XBangPatterns Main.hs -o bt1 sed -i 's/bit/trace "" $ bit/g' Main.hs # prepend `trace $ ` to the call to `bit` ghc -O2 -XBangPatterns Main.hs -o bt2 valgrind --tool=cachegrind ./bt1 12 2>&1 > /dev/null # without trace valgrind --tool=cachegrind ./bt2 12 2>&1 > /dev/null # with trace }}} This will compile two versions of `binary-trees`, one with an extra `trace "" $` call before the only call to the `bit` function. One would expect the version with the `trace` call (`bt1`) to allocate more than the version without (`bt2`). Indeed, the output of `+RTS -s` suggests that: {{{ $ ./bt1 12 +RTS -s ... 43,107,560 bytes allocated in the heap ... $ ./bt2 12 +RTS -s ... 43,116,888 bytes allocated in the heap ... }}} That's fine. A few benchmark runs by hand also suggested the tracing version is a little slower (probably due to IO). Compare that to the output of the above cachegrind calls: {{{ $ valgrind --tool=cachegrind ./bt1 12 > /dev/null ... I refs: 118,697,583 ... D refs: 43,475,212 ... $ valgrind --tool=cachegrind ./bt2 12 > /dev/null ... I refs: 116,340,710 ... D refs: 42,523,369 ... }}} It's the other way round here! How's that possible? Even if this isn't strictly a bug in GHC or NoFib, it's relevant nonetheless, as our benchmark infrastructure currently relies on instruction counts. I couldn't reproduce this by writing my own no-op `trace _ a = a; {-# NOINLINE trace #-}`, btw. I checked this on GHC 8.2.2 and a semi-recent HEAD commit (bb539cfe335eeec7989332b859b1f3162c5e105a). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 15:14:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 15:14:33 -0000 Subject: [GHC] #15333: Weird cachegrind results for binary-trees In-Reply-To: <044.7a98f83472ccde2b3f7411c5c885bd25@haskell.org> References: <044.7a98f83472ccde2b3f7411c5c885bd25@haskell.org> Message-ID: <059.97a16cb0f91e6b53f613406c5b83a3ac@haskell.org> #15333: Weird cachegrind results for binary-trees -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research Component: NoFib benchmark | needed suite | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by sgraf: Old description: > I'm currently investigating an alleged regression in my branch of the > late lambda lift and hit a confusing data point. Note that I'm very much > relying on cachegrinds counted instructions/memory accesses for my > findings. > > Check out the most recent version of `nofib` and run the following > script: > > {{{#!sh > #! /usr/bin/env zsh > sed -i 's/import Debug.Trace//g' Main.hs # Make the following line > idempotent > echo "import Debug.Trace" | cat - Main.hs > Main.tmp && mv Main.tmp > Main.hs # add the import for trace > sed -i 's/trace "" \$ bit/bit/g' Main.hs # strip `trace $ ` prefixes in > the call to `bit` > ghc -O2 -XBangPatterns Main.hs -o bt1 > sed -i 's/bit/trace "" $ bit/g' Main.hs # prepend `trace $ ` to the call > to `bit` > ghc -O2 -XBangPatterns Main.hs -o bt2 > valgrind --tool=cachegrind ./bt1 12 2>&1 > /dev/null # without trace > valgrind --tool=cachegrind ./bt2 12 2>&1 > /dev/null # with trace > }}} > > This will compile two versions of `binary-trees`, one with an extra > `trace "" $` call before the only call to the `bit` function. One would > expect the version with the `trace` call (`bt1`) to allocate more than > the version without (`bt2`). Indeed, the output of `+RTS -s` suggests > that: > > {{{ > $ ./bt1 12 +RTS -s > ... > 43,107,560 bytes allocated in the heap > ... > $ ./bt2 12 +RTS -s > ... > 43,116,888 bytes allocated in the heap > ... > }}} > > That's fine. A few benchmark runs by hand also suggested the tracing > version is a little slower (probably due to IO). > > Compare that to the output of the above cachegrind calls: > > {{{ > $ valgrind --tool=cachegrind ./bt1 12 > /dev/null > ... > I refs: 118,697,583 > ... > D refs: 43,475,212 > ... > $ valgrind --tool=cachegrind ./bt2 12 > /dev/null > ... > I refs: 116,340,710 > ... > D refs: 42,523,369 > ... > }}} > > It's the other way round here! How's that possible? > > Even if this isn't strictly a bug in GHC or NoFib, it's relevant > nonetheless, as our benchmark infrastructure currently relies on > instruction counts. I couldn't reproduce this by writing my own no-op > `trace _ a = a; {-# NOINLINE trace #-}`, btw. > > I checked this on GHC 8.2.2 and a semi-recent HEAD commit > (bb539cfe335eeec7989332b859b1f3162c5e105a). New description: I'm currently investigating an alleged regression in my branch of the late lambda lift and hit a confusing data point. Note that I'm very much relying on cachegrinds counted instructions/memory accesses for my findings. Check out the most recent version of `nofib` and run the following script: {{{#!sh #! /bin/sh sed -i 's/import Debug.Trace//g' Main.hs # Make the following line idempotent echo "import Debug.Trace" | cat - Main.hs > Main.tmp && mv Main.tmp Main.hs # add the import for trace sed -i 's/trace "" \$ bit/bit/g' Main.hs # strip `trace $ ` prefixes in the call to `bit` ghc -O2 -XBangPatterns Main.hs -o bt1 sed -i 's/bit/trace "" $ bit/g' Main.hs # prepend `trace $ ` to the call to `bit` ghc -O2 -XBangPatterns Main.hs -o bt2 valgrind --tool=cachegrind ./bt1 12 2>&1 > /dev/null # without trace valgrind --tool=cachegrind ./bt2 12 2>&1 > /dev/null # with trace }}} This will compile two versions of `binary-trees`, one with an extra `trace "" $` call before the only call to the `bit` function. One would expect the version with the `trace` call (`bt1`) to allocate more than the version without (`bt2`). Indeed, the output of `+RTS -s` suggests that: {{{ $ ./bt1 12 +RTS -s ... 43,107,560 bytes allocated in the heap ... $ ./bt2 12 +RTS -s ... 43,116,888 bytes allocated in the heap ... }}} That's fine. A few benchmark runs by hand also suggested the tracing version is a little slower (probably due to IO). Compare that to the output of the above cachegrind calls: {{{ $ valgrind --tool=cachegrind ./bt1 12 > /dev/null ... I refs: 118,697,583 ... D refs: 43,475,212 ... $ valgrind --tool=cachegrind ./bt2 12 > /dev/null ... I refs: 116,340,710 ... D refs: 42,523,369 ... }}} It's the other way round here! How's that possible? Even if this isn't strictly a bug in GHC or NoFib, it's relevant nonetheless, as our benchmark infrastructure currently relies on instruction counts. I couldn't reproduce this by writing my own no-op `trace _ a = a; {-# NOINLINE trace #-}`, btw. I checked this on GHC 8.2.2 and a semi-recent HEAD commit (bb539cfe335eeec7989332b859b1f3162c5e105a). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 15:26:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 15:26:03 -0000 Subject: [GHC] #15330: Error message prints invisible kind arguments in a visible matter In-Reply-To: <050.7a0d11dfbc8ef3463c27a79c9bdf89a1@haskell.org> References: <050.7a0d11dfbc8ef3463c27a79c9bdf89a1@haskell.org> Message-ID: <065.7996d60cbfef31421de6dea7cdd88b26@haskell.org> #15330: Error message prints invisible kind arguments in a visible matter -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): How about this: {{{#!hs data Type = ... | AppTy AppTyMode Type Type | ... data AppTyMode = VanillaATM | InvisATM -- | VisDepATM -- for visible dependent application, which will be available outside -- TyConApps with https://github.com/ghc-proposals/ghc- proposals/pull/81 }}} Every `AppTy` then gets tagged, at creation. `IfaceAppTy` naturally would get the same tags. I think `AppTy`s aren't all that common, so the extra word shouldn't be so bad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 15:31:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 15:31:49 -0000 Subject: [GHC] #15225: `-fno-state-hack` produces incorrect results in nofib In-Reply-To: <047.20e2da7aa2a2e4221951af3d8807d250@haskell.org> References: <047.20e2da7aa2a2e4221951af3d8807d250@haskell.org> Message-ID: <062.537b2fdba9aef8f97e86f3d6ed3fca0c@haskell.org> #15225: `-fno-state-hack` produces incorrect results in nofib -------------------------------------+------------------------------------- Reporter: tdammers | Owner: tdammers Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #7411 | Differential Rev(s): Phab:D4868 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 15:34:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 15:34:35 -0000 Subject: [GHC] #15330: Error message prints invisible kind arguments in a visible matter In-Reply-To: <050.7a0d11dfbc8ef3463c27a79c9bdf89a1@haskell.org> References: <050.7a0d11dfbc8ef3463c27a79c9bdf89a1@haskell.org> Message-ID: <065.57e6d21bcb0adcb80a3f85aef354dcbe@haskell.org> #15330: Error message prints invisible kind arguments in a visible matter -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): That sounds good to me. Two remaining questions: * How should we print `InvisATM`-tagged types when `-fprint-explicit- kinds` is enabled? Using the above example, should it be `f Bool 'True` or `f @Bool 'True`? Should `-dsuppress-type-applications` enter the picture somewhere? * Would we need to pretty-print `VisDepATM`-tagged types differently from `VanillaATM`-tagged ones? That is, why should we distinguish `VisDepATM` at all? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 15:44:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 15:44:08 -0000 Subject: [GHC] #15330: Error message prints invisible kind arguments in a visible matter In-Reply-To: <050.7a0d11dfbc8ef3463c27a79c9bdf89a1@haskell.org> References: <050.7a0d11dfbc8ef3463c27a79c9bdf89a1@haskell.org> Message-ID: <065.b3adc590d21bf4012711e40804673cda@haskell.org> #15330: Error message prints invisible kind arguments in a visible matter -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Let's not debate `VisDepATM` now. That's something I've pondered for a while, but I think it matters in coercions more than types. You're right that it won't affect printing. I quite like putting the `@` on kinds with `-fprint-explicit-kinds`. Regardless of anything else, we should absolutely do this. I wouldn't have it interact with `-dsuppress-type-applications`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 16:03:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 16:03:35 -0000 Subject: [GHC] #7331: Allow the evaluation of declaration splices in GHCi In-Reply-To: <044.7357b5463f6b7bd32b16f3031ed7a588@haskell.org> References: <044.7357b5463f6b7bd32b16f3031ed7a588@haskell.org> Message-ID: <059.41b279f061526ef1eaee9379d0ed5bc8@haskell.org> #7331: Allow the evaluation of declaration splices in GHCi -------------------------------------+------------------------------------- Reporter: parcs | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7331 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * related: => #7331 Comment: See also #12410. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 16:03:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 16:03:56 -0000 Subject: [GHC] #7331: Allow the evaluation of declaration splices in GHCi In-Reply-To: <044.7357b5463f6b7bd32b16f3031ed7a588@haskell.org> References: <044.7357b5463f6b7bd32b16f3031ed7a588@haskell.org> Message-ID: <059.8c7419ba16e0655940c2a9789a782407@haskell.org> #7331: Allow the evaluation of declaration splices in GHCi -------------------------------------+------------------------------------- Reporter: parcs | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * related: #7331 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 16:04:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 16:04:20 -0000 Subject: [GHC] #12410: Somehow detect splicing in ghci In-Reply-To: <051.68fec2e99046d2d08b438c5a4bbecc1c@haskell.org> References: <051.68fec2e99046d2d08b438c5a4bbecc1c@haskell.org> Message-ID: <066.86426a3d9e13bdb398eb6b9663c44eb3@haskell.org> #12410: Somehow detect splicing in ghci -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): See also #7331. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 16:46:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 16:46:19 -0000 Subject: [GHC] #15330: Error message prints invisible kind arguments in a visible matter In-Reply-To: <050.7a0d11dfbc8ef3463c27a79c9bdf89a1@haskell.org> References: <050.7a0d11dfbc8ef3463c27a79c9bdf89a1@haskell.org> Message-ID: <065.520899884e6164ade17d5ad05766e295@haskell.org> #15330: Error message prints invisible kind arguments in a visible matter -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Let's ''not'' do this in `Type`, but rather in `IfaceType`. For `Type` it is simply redundant info that we'll have to carry around and maintain. We only need it for pretty-printing. `IfaceType` (now a slight misnomer) is intended for serialisation, either to the user or to a binary file, so adding extra info makes sense. In practice, we are going to gather up all the args of a chain of `AppTy`s before pretty-printing, so we can lay them out nicely. So maybe we should use {{{ | IfaceAppTy IfaceType IfaceTcArgs }}} and then rename `IfaceTcArgs` to `IfaceAppArgs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 16:46:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 16:46:26 -0000 Subject: [GHC] #15051: -split-objs generates excessively many files on Windows In-Reply-To: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> References: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> Message-ID: <060.d96e404fbe9751adcc47d1d0b25f04f0@haskell.org> #15051: -split-objs generates excessively many files on Windows -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Phyx- Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (CodeGen) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4915 Wiki Page: | Phab:D4916 -------------------------------------+------------------------------------- Comment (by bgamari): Yes, I think just disabling (and ultimately removing) split objects is the right idea here. This is something I've been looking to do for quite some time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 17:03:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 17:03:19 -0000 Subject: [GHC] #15051: -split-objs generates excessively many files on Windows In-Reply-To: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> References: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> Message-ID: <060.d7a4199556b5c20a5e5955be94ca8725@haskell.org> #15051: -split-objs generates excessively many files on Windows -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Phyx- Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (CodeGen) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4915 Wiki Page: | Phab:D4916 -------------------------------------+------------------------------------- Comment (by Phyx-): It's unfortunate that it leaves the Windows port in a very icky situation. It either gets slower, gets much slower, or gets bigger. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 17:18:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 17:18:46 -0000 Subject: [GHC] #15326: Add option to disable error message expression context (the 'In the expression' things) In-Reply-To: <050.d8b5750cd390deaca2bcecfe092d3c9f@haskell.org> References: <050.d8b5750cd390deaca2bcecfe092d3c9f@haskell.org> Message-ID: <065.8b0d8e8f4d5728d86767c36404a710d1@haskell.org> #15326: Add option to disable error message expression context (the 'In the expression' things) -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: 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): * cc: goldfire (added) Comment: It seems like this very much falls in the area where Richard has a student working this summer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 17:21:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 17:21:48 -0000 Subject: [GHC] #14553: Implement native CPP In-Reply-To: <045.adf1dad4e79717b77bccedf2aee73f71@haskell.org> References: <045.adf1dad4e79717b77bccedf2aee73f71@haskell.org> Message-ID: <060.7be56ad587406ab4546b25e20ef1a417@haskell.org> #14553: Implement native CPP -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 1290 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I think this is really more of am implementation detail. As far as I can tell, Proposal/NativeCpp doesn't really propose any user-facing changes, it merely changes the implementation to be more robust and consistent across platforms. As such, I'm not entirely sure it needs to go through the proposals process. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 18:03:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 18:03:07 -0000 Subject: [GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin In-Reply-To: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> References: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> Message-ID: <062.6463591f35b159a27e2d7e63aacf0467@haskell.org> #15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | typeable,knownnat Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10348 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by diatchki): We are using the same system for `Typeable`. Have a look in `Data.Typeable.Internal` (in `base`): the functions `typeNatTypeRep` and `typeSymbolTypeRep` make the run-time representations used by the corresponding `Typeable` instances. The `ds_ev_typeable` function in `deSugar/DsBinds` just uses these functions when it needs to make evidence for `Typeable`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 18:18:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 18:18:19 -0000 Subject: [GHC] #15326: Add option to disable error message expression context (the 'In the expression' things) In-Reply-To: <050.d8b5750cd390deaca2bcecfe092d3c9f@haskell.org> References: <050.d8b5750cd390deaca2bcecfe092d3c9f@haskell.org> Message-ID: <065.19894fb0b24a8c0e9f9bf7dfaacf33f0@haskell.org> #15326: Add option to disable error message expression context (the 'In the expression' things) -------------------------------------+------------------------------------- Reporter: dramforever | Owner: nadine Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nadine): * owner: (none) => nadine -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 18:23:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 18:23:58 -0000 Subject: [GHC] #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) Message-ID: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs {-# LANGUAGE DeriveTraversable #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE UndecidableInstances #-} module Foo where import Data.Kind type family F a :: Type -> Type newtype WrappedF a b = WrapF (F a b) deriving instance Functor (F a) => Functor (WrappedF a) deriving instance Foldable (F a) => Foldable (WrappedF a) deriving instance Traversable (F a) => Traversable (WrappedF a) data SomeF b = forall a. MkSomeF (WrappedF a b) deriving instance (forall a. Functor (WrappedF a)) => Functor SomeF deriving instance (forall a. Foldable (WrappedF a)) => Foldable SomeF deriving instance ( forall a. Functor (WrappedF a) , forall a. Foldable (WrappedF a) , forall a. Traversable (WrappedF a) ) => Traversable SomeF }}} This typechecks. However, the last `Traversable SomeF` is a bit unfortunate in that is uses three separate `forall a.`s. I attempted to factor this out, like so: {{{#!hs deriving instance (forall a. ( Functor (WrappedF a) , Foldable (WrappedF a) , Traversable (WrappedF a) )) => Traversable SomeF }}} But then the file no longer typechecked! {{{ $ /opt/ghc/8.6.1/bin/ghc Foo.hs [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Foo.hs:21:1: error: • Could not deduce (Functor (F a)) arising from the superclasses of an instance declaration from the context: forall a. (Functor (WrappedF a), Foldable (WrappedF a), Traversable (WrappedF a)) bound by the instance declaration at Foo.hs:(21,1)-(24,52) • In the instance declaration for ‘Traversable SomeF’ | 21 | deriving instance (forall a. ( Functor (WrappedF a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... Foo.hs:21:1: error: • Could not deduce (Foldable (F a)) arising from the superclasses of an instance declaration from the context: forall a. (Functor (WrappedF a), Foldable (WrappedF a), Traversable (WrappedF a)) bound by the instance declaration at Foo.hs:(21,1)-(24,52) • In the instance declaration for ‘Traversable SomeF’ | 21 | deriving instance (forall a. ( Functor (WrappedF a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... Foo.hs:21:1: error: • Could not deduce (Traversable (F a1)) arising from a use of ‘traverse’ from the context: forall a. (Functor (WrappedF a), Foldable (WrappedF a), Traversable (WrappedF a)) bound by the instance declaration at Foo.hs:(21,1)-(24,52) or from: Applicative f bound by the type signature for: traverse :: forall (f :: * -> *) a b. Applicative f => (a -> f b) -> SomeF a -> f (SomeF b) at Foo.hs:(21,1)-(24,52) • In the second argument of ‘fmap’, namely ‘(traverse f a1)’ In the expression: fmap (\ b1 -> MkSomeF b1) (traverse f a1) In an equation for ‘traverse’: traverse f (MkSomeF a1) = fmap (\ b1 -> MkSomeF b1) (traverse f a1) When typechecking the code for ‘traverse’ in a derived instance for ‘Traversable SomeF’: To see the code I am typechecking, use -ddump-deriv | 21 | deriving instance (forall a. ( Functor (WrappedF a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} Richard suspects that this is a bug in the way quantified constraints expands superclasses, so I decided to post it here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 18:25:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 18:25:34 -0000 Subject: [GHC] #13194: Concurrent modifications of package.cache are not safe In-Reply-To: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> References: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> Message-ID: <062.547d7e41081d9e41b6dc38d5a52b32e6@haskell.org> #13194: Concurrent modifications of package.cache are not safe -------------------------------------+------------------------------------- Reporter: arybczak | Owner: arybczak Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13354, #13375, | Differential Rev(s): Phab:D3090 #14017 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): As noted in #15313, comment:10 is broken on Windows, failing to ensure mutual exclusion under high load. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 18:29:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 18:29:35 -0000 Subject: [GHC] #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) In-Reply-To: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> References: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> Message-ID: <065.49a5f583417199a3b9894b9651f32616@haskell.org> #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes. It looks to me like GHC isn't looking under tuples when expanding superclasses. Really, shouldn't we have `c1` and `c2` be superclasses of `(c1, c2)`? Then this would be all automatic. Or I've misunderstood something. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 19:05:16 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 19:05:16 -0000 Subject: [GHC] #12449: Broken types in identifiers bound by :print In-Reply-To: <044.542a5d089ce4efa7862430871616a137@haskell.org> References: <044.542a5d089ce4efa7862430871616a137@haskell.org> Message-ID: <059.3b7d59fb3d36381bb53fd4973e1e3d39@haskell.org> #12449: Broken types in identifiers bound by :print -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: | ghci/scripts/T12449 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => ghci/scripts/T12449 Comment: Test added in Phab:D4921 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 19:06:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 19:06:54 -0000 Subject: [GHC] #15051: -split-objs generates excessively many files on Windows In-Reply-To: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> References: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> Message-ID: <060.802e9227d63b8b8e85ab9f7d56c73062@haskell.org> #15051: -split-objs generates excessively many files on Windows -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Phyx- Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (CodeGen) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4915 Wiki Page: | Phab:D4916 -------------------------------------+------------------------------------- Comment (by bgamari): I agree, but disk space is reasonably cheap now. It seems to me like accepting a temporary increase in size and focusing effort on fixing split sections is a better use of time than trying to fix what is ultimately a dead-end. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 19:19:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 19:19:07 -0000 Subject: [GHC] #13584: ghci parse error on operator info In-Reply-To: <046.930e1afa5ab80feb957e040b20527a91@haskell.org> References: <046.930e1afa5ab80feb957e040b20527a91@haskell.org> Message-ID: <061.31bc2ad3f3a35b93c0e978df529a56be@haskell.org> #13584: ghci parse error on operator info -------------------------------------+------------------------------------- Reporter: akegalj | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: parse, info, | operator Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Alright, looking at the report again I suppose accepting `(+ )` is reasonable; afterall whitespace is not allowed in identifiers; it's merely a lexeme delimiter. I rescind comment:2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 19:22:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 19:22:58 -0000 Subject: [GHC] #13584: ghci parse error on operator info In-Reply-To: <046.930e1afa5ab80feb957e040b20527a91@haskell.org> References: <046.930e1afa5ab80feb957e040b20527a91@haskell.org> Message-ID: <061.f6a778fec4b6ca16d93525bd526900d0@haskell.org> #13584: ghci parse error on operator info -------------------------------------+------------------------------------- Reporter: akegalj | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: parse, info, | operator Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): anarchist666, I'm not sure I understand your proposal. Are you suggesting that `:info` simply drop all parentheses from its arguments? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 19:26:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 19:26:36 -0000 Subject: [GHC] #14298: Let Template Haskell dynamically add something with which to link In-Reply-To: <050.5b84ef44d6dba8c28fe71b17d035f8a7@haskell.org> References: <050.5b84ef44d6dba8c28fe71b17d035f8a7@haskell.org> Message-ID: <065.a03f0ad29962616c3151c1e4b1b01505@haskell.org> #14298: Let Template Haskell dynamically add something with which to link -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4064 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed it is. Thanks for noticing! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 19:37:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 19:37:36 -0000 Subject: [GHC] #15051: -split-objs generates excessively many files on Windows In-Reply-To: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> References: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> Message-ID: <060.8e4efedae8e3a12baa69c09f83c99d66@haskell.org> #15051: -split-objs generates excessively many files on Windows -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Phyx- Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (CodeGen) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4915 Wiki Page: | Phab:D4916 -------------------------------------+------------------------------------- Comment (by Phyx-): True, from my own checks the increase in size doesn't seem to be that much. so Yeah I also think disabling it is the way forwards. Also because fundamentally there's nothing really that can be done about it. split-objs just won't scale. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 19:41:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 19:41:32 -0000 Subject: [GHC] #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) In-Reply-To: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> References: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> Message-ID: <065.d07bd31b6d4bece261e4dcbe53cb4e5a@haskell.org> #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): `c1` and `c2` are already superclasses of `(c1, c2)`. I suspect the issue is not in how constraint tuples are defined, because it I replace the constraint triple in my program with a hand-rolled one: {{{#!hs class (a, b, c) => CTuple3 a b c instance (a, b, c) => CTuple3 a b c deriving instance (forall a. CTuple3 (Functor (WrappedF a)) (Foldable (WrappedF a)) (Traversable (WrappedF a)) ) => Traversable SomeF }}} Then I still get the same error as before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 19:58:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 19:58:18 -0000 Subject: [GHC] #15283: Locale issue in the testsuite In-Reply-To: <045.dffad18a78b227771753ebab7a4c89b6@haskell.org> References: <045.dffad18a78b227771753ebab7a4c89b6@haskell.org> Message-ID: <060.c4e9e1d95d02f51e223d66e71dd83e24@haskell.org> #15283: Locale issue in the testsuite -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Test Suite | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I think we should just force the locale for the entire testsuite. Afterall, we want the run to be as deterministic as possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 20:11:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 20:11:39 -0000 Subject: [GHC] #14980: Runtime performance regression with binary operations on vectors In-Reply-To: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> References: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> Message-ID: <060.0e48826216638ae006d86bdccd698bd7@haskell.org> #14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: vector | bitwise operations Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): While I've not looked at the program, I would guess `eftIntList`. That allows us to deforest a consumed list produced by `enumFromTo` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 20:15:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 20:15:32 -0000 Subject: [GHC] #15319: Configurable/overridable settings file In-Reply-To: <044.ba7ad8d95aa9a6958eb5b0890b79f3ba@haskell.org> References: <044.ba7ad8d95aa9a6958eb5b0890b79f3ba@haskell.org> Message-ID: <059.b361be7fade74b60ea9dfef9c5a7397b@haskell.org> #15319: Configurable/overridable settings file -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Sigh, yes, the `-no-pie` hack is terrible. Perhaps it would help if we didn't add `-no-pie` to the compiler command line when it has been specified via `-pgmc`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 20:16:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 20:16:51 -0000 Subject: [GHC] #14529: Refactor ConDecl In-Reply-To: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> References: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> Message-ID: <061.4585a7acf5cfedf16ebf0ac0d37b432f@haskell.org> #14529: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4867 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: 8.8.1 => 8.6.1 Comment: Not yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 20:17:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 20:17:52 -0000 Subject: [GHC] #14529: Refactor ConDecl In-Reply-To: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> References: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> Message-ID: <061.2183cdccd15c47189af6d7d2d4c5cf9a@haskell.org> #14529: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4867 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Correction, yes it is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 20:19:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 20:19:09 -0000 Subject: [GHC] #15295: Haddock options should be concatened In-Reply-To: <046.234e50e311e74e13a22a289f266ad26f@haskell.org> References: <046.234e50e311e74e13a22a289f266ad26f@haskell.org> Message-ID: <061.f2ed7da122a68871b7af265a3159b454@haskell.org> #15295: Haddock options should be concatened -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: haddock Operating System: 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): Sounds reasonable to me. Do you intend on fixing this, sjakobi? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 20:22:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 20:22:25 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.0bdb9696fd6e6b0da16717aa4b5dfba7@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): At the moment I'm leaning towards discontinuing use of GCC and accepting the performance hit. I have had a number of Darwin users complain about various toolchain issues which arise from our strange mixture of toolchains. This issue makes me think that the pain that our use of GCC brings far outweighs the cost of Clang's poor TLS performance. It would be nice if someone could quantify the effect, however. Carter, perhaps you could build a GHC using GCC and benchmark this against 8.6.1-alpha1, which was built with Clang? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 20:43:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 20:43:53 -0000 Subject: [GHC] #15328: cpphs: internal error: evacuate(static): strange closure type 8440 In-Reply-To: <044.e7d3083ced1a98874e271c4b45548264@haskell.org> References: <044.e7d3083ced1a98874e271c4b45548264@haskell.org> Message-ID: <059.ea4e651c2be55238f85d1e81585efe40@haskell.org> #15328: cpphs: internal error: evacuate(static): strange closure type 8440 -------------------------------------+------------------------------------- Reporter: cnmne | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Package system | Version: 8.4.3 Resolution: | Keywords: cabal, cpphs, | strange closure Operating System: MacOS X | Architecture: x86 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, this is quite concerning indeed. Which `cpphs` version are you using? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 20:46:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 20:46:25 -0000 Subject: [GHC] #15327: Optimize remainders by powers of two for Integer and Natural In-Reply-To: <047.622e50c19a30545c881539436f767344@haskell.org> References: <047.622e50c19a30545c881539436f767344@haskell.org> Message-ID: <062.d4c30d7408aecd9bc30303fe63f03645@haskell.org> #15327: Optimize remainders by powers of two for Integer and Natural -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14437 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): In general optimizing operations on "small" `Integer`s seems like quite a worthwhile goal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 20:50:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 20:50:33 -0000 Subject: [GHC] #15302: TTG for IPBind wrong extension name In-Reply-To: <044.6aedb86c3fb3b3deb8c5cd1f95b1006a@haskell.org> References: <044.6aedb86c3fb3b3deb8c5cd1f95b1006a@haskell.org> Message-ID: <059.d38c0a502bc2d3b7b16f8d661234f1ca@haskell.org> #15302: TTG for IPBind wrong extension name -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: ttg Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 20:53:30 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 20:53:30 -0000 Subject: [GHC] #9672: Error message too long (full case statement printed) In-Reply-To: <051.99a860bf6093bb48bfa9c98f3e2d6cd2@haskell.org> References: <051.99a860bf6093bb48bfa9c98f3e2d6cd2@haskell.org> Message-ID: <066.ea1e2aae67a0a68d9623d5da7bbaa4a3@haskell.org> #9672: Error message too long (full case statement printed) -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: nadine (added) Comment: Nadine, you may also be interested in this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 21:06:10 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 21:06:10 -0000 Subject: [GHC] #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) In-Reply-To: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> References: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> Message-ID: <065.b613a0bb953d9421ee28a2de3a021b89@haskell.org> #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Read [https://github.com/Gertjan423/ghc-proposals/blob/quantified- constraints/proposals/0000-quantified-constraints.rst the proposal] esp Section 3.2 Would you write {{{ instance (Functor (T a), Traversable (T a), Foldable (T a_)) where ... }}} No! An instance declaration is for a class, and takes the form {{{ instance blah => C t1 .. tn where ... }}} where `C` is a class. Same with quantified constraints, as the syntax (tries to) make clear. I suppose that it's accepted because `(,,)` is a class but really I think it should be rejected. In fact {{{ instance (Eq (T a), Ord (T a)) where {} }}} is not rejected out of hand, but elicits {{{ * No instance for (Ord (T a)) arising from the superclasses of an instance declaration * In the instance declaration for `(Eq (T a), Ord (T a))' }}} which is pretty confusing. I think it's because `(c1, c2)` has superclasses `c1` and `c2`. My conclusion: both in top-level and quantified instances, we should reject a tuple in the head. OK? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 21:06:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 21:06:54 -0000 Subject: [GHC] #15319: Configurable/overridable settings file In-Reply-To: <044.ba7ad8d95aa9a6958eb5b0890b79f3ba@haskell.org> References: <044.ba7ad8d95aa9a6958eb5b0890b79f3ba@haskell.org> Message-ID: <059.458d4a5a8382cb00fcc42b1c2ddf6253@haskell.org> #15319: Configurable/overridable settings file -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mboes): Yes, I think that would be more correct. AFAIU from https://ghc.haskell.org/trac/ghc/ticket/7929#comment:2, clearing the compiler flags is already what GHC does for the other flags. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 21:08:44 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 21:08:44 -0000 Subject: [GHC] #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) In-Reply-To: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> References: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> Message-ID: <065.c69bdf036d8f9695e8d769ea6f0f835e@haskell.org> #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Why are tuples special? After all, the issues persists even if I switch out the tuple for a hand-written class, as shown in comment:2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 21:24:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 21:24:19 -0000 Subject: [GHC] #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) In-Reply-To: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> References: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> Message-ID: <065.106b036855e269510e100135057112b8@haskell.org> #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): If the constraint solver was ever faced with {{{ [W] CTuple3 (Functor (WrappedF ty)) (Foldable (WrappedF ty)) (Traversable (WrappedF ty) }}} it'd probably work (although note the tricky overlap with the top level instance). But will the derived instance give rise to that wanted constraint? I think not. For built-in tuples, I think the constraint solver probably does just decompose them eagerly, rather than look for local instances of tuples. That is special behaviour, I grant you, but I have yet to see a case in which that's not the right thing to do. Where are these strange wanted constraints going to come from? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 2 22:05:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 02 Jul 2018 22:05:12 -0000 Subject: [GHC] #15295: Haddock options should be concatened In-Reply-To: <046.234e50e311e74e13a22a289f266ad26f@haskell.org> References: <046.234e50e311e74e13a22a289f266ad26f@haskell.org> Message-ID: <061.3fcf0d675ac8d9c0a3fdc5c90dd4a142@haskell.org> #15295: Haddock options should be concatened -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: haddock Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sjakobi): As no-one seems to have run into this problem so far, I probably won't get to it before the end of August. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 01:01:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 01:01:42 -0000 Subject: [GHC] #14627: qAddTopDecls: can't convert top-level declarations In-Reply-To: <049.485d47f57c339e482133548d02dc333a@haskell.org> References: <049.485d47f57c339e482133548d02dc333a@haskell.org> Message-ID: <064.322c138c2c496fb0c8b4efdc3bbda6aa@haskell.org> #14627: qAddTopDecls: can't convert top-level declarations -------------------------------------+------------------------------------- Reporter: tianxiaogu | Owner: mgsloan Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4914 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mgsloan): In addition to D4914, which changes this from panic-ing to just a regular error, I've also published https://phabricator.haskell.org/D4923 which improves the error for this specific case. Instead it says "Data constructor not in scope: Bool" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 01:03:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 01:03:55 -0000 Subject: [GHC] #10391: Ability to get export list of TH reified module In-Reply-To: <047.4433cd04132dabf0d7e1565467e79715@haskell.org> References: <047.4433cd04132dabf0d7e1565467e79715@haskell.org> Message-ID: <062.1dbcb6450c083f3d53ed6d992a2ec330@haskell.org> #10391: Ability to get export list of TH reified module -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: mgsloan Type: feature request | Status: new Priority: low | Milestone: Component: Template Haskell | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10842 | Differential Rev(s): Phab:D4925 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mgsloan): * differential: => Phab:D4925 Comment: I've implemented this feature in https://phabricator.haskell.org/D4925 ! I was pleasantly surprised to see that this was fairly straightforward to implement, though there was a fair bit to consider design-wise. Wish I'd known how small the change would be when I was itching for this years ago! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 01:05:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 01:05:01 -0000 Subject: [GHC] #10391: Ability to get export list of TH reified module In-Reply-To: <047.4433cd04132dabf0d7e1565467e79715@haskell.org> References: <047.4433cd04132dabf0d7e1565467e79715@haskell.org> Message-ID: <062.9d618687d99c85b31aca8e0b9ff9d14d@haskell.org> #10391: Ability to get export list of TH reified module -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: mgsloan Type: feature request | Status: patch Priority: low | Milestone: Component: Template Haskell | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10391 Blocked By: | Blocking: Related Tickets: #10842 | Differential Rev(s): Phab:D4925 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mgsloan): * status: new => patch * testcase: => T10391 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 01:06:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 01:06:44 -0000 Subject: [GHC] #1262: RecursiveDo in Template Haskell In-Reply-To: <062.2857e038d8ba06eaa6e83d19ada8ff7e@haskell.org> References: <062.2857e038d8ba06eaa6e83d19ada8ff7e@haskell.org> Message-ID: <077.6dc021235db174b10b7d8a0079ae7b53@haskell.org> #1262: RecursiveDo in Template Haskell -------------------------------------+------------------------------------- Reporter: philip.weaver@… | Owner: mgsloan Type: feature request | Status: patch Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.6 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | th/TH_recursiveDo Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1979 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mgsloan): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 01:11:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 01:11:16 -0000 Subject: [GHC] #14471: Certain do blocks cause TH to barf when ApplicativeDo is enabled In-Reply-To: <050.4f7b341f8e72d76f8691291adb62b498@haskell.org> References: <050.4f7b341f8e72d76f8691291adb62b498@haskell.org> Message-ID: <065.47ec75dc93ae326f67aeadcccd46e844@haskell.org> #14471: Certain do blocks cause TH to barf when ApplicativeDo is enabled -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: mgsloan Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: th/T14471 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4912 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mgsloan): * testcase: => th/T14471 * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 01:12:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 01:12:57 -0000 Subject: [GHC] #14627: qAddTopDecls: can't convert top-level declarations In-Reply-To: <049.485d47f57c339e482133548d02dc333a@haskell.org> References: <049.485d47f57c339e482133548d02dc333a@haskell.org> Message-ID: <064.63a4eaae95227ab8ba72109c09641ac1@haskell.org> #14627: qAddTopDecls: can't convert top-level declarations -------------------------------------+------------------------------------- Reporter: tianxiaogu | Owner: mgsloan Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4914 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mgsloan): * status: new => patch * cc: th/T14627 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 01:13:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 01:13:15 -0000 Subject: [GHC] #14627: qAddTopDecls: can't convert top-level declarations In-Reply-To: <049.485d47f57c339e482133548d02dc333a@haskell.org> References: <049.485d47f57c339e482133548d02dc333a@haskell.org> Message-ID: <064.262d976a1408de86aab70a76a8dbc721@haskell.org> #14627: qAddTopDecls: can't convert top-level declarations -------------------------------------+------------------------------------- Reporter: tianxiaogu | Owner: mgsloan Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: th/T14627 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4914 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mgsloan): * cc: th/T14627 (removed) * testcase: => th/T14627 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 01:40:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 01:40:03 -0000 Subject: [GHC] #15335: Export `findImportUsage` from `rename/RnNames.hs` module Message-ID: <047.137c5faaec024c503e5607145a3daa2f@haskell.org> #15335: Export `findImportUsage` from `rename/RnNames.hs` module -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple imports,refactoring,export | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm writing source plugin for analyzing imports in Haskell source code. I don't want to duplicate code already written in GHC. So I would like to have `findImportUsage` function and `ImportDeclUsage` type aliases exported from `RnNames` module: * [https://github.com/ghc/ghc/blob/ccd8ce405db89142932daea3fdace8814b110798/compiler/rename/RnNames.hs#L1314-L1318 GitHub: ghc/compilier/rename/RnNames] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 02:19:32 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 02:19:32 -0000 Subject: [GHC] #9693: Reloading GHCi with Template Haskell names can panic GHC In-Reply-To: <043.739fde51b47ea4696baf564b0f9ae27e@haskell.org> References: <043.739fde51b47ea4696baf564b0f9ae27e@haskell.org> Message-ID: <058.9df73e8e5df0b4df012e985feced1bdf@haskell.org> #9693: Reloading GHCi with Template Haskell names can panic GHC -------------------------------------+------------------------------------- Reporter: maxs | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mgsloan): @RyanGIScott Sure! It was interesting figuring out a good way to test issues that only reproduce due to reload. The approach I've taken seems pretty clean to me and might be useful for other such recompilation / reload tests. https://phabricator.haskell.org/D4926 It turns out that there is indeed still some funky statefulness going on. Fresh load of the modified version works fine, whereas reload after modification yields ` Data constructor ‘X’ used as a type constructor`. Nice that it's not a panic, but not correct and indicates some spooky statefulness. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 03:57:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 03:57:28 -0000 Subject: [GHC] #15262: GHC and iserv cannot agree on what an Integer is; insanity ensues (was: TH splice containing numeric literal 0 causes heap overflow while cross-compiling) In-Reply-To: <050.8f7705015e16ef64b51a5dbaaaac982c@haskell.org> References: <050.8f7705015e16ef64b51a5dbaaaac982c@haskell.org> Message-ID: <065.4e731fc00f47cfb715f44fff2e7eb21b@haskell.org> #15262: GHC and iserv cannot agree on what an Integer is; insanity ensues -------------------------------------+------------------------------------- Reporter: howtonotwin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by howtonotwin): * architecture: Unknown/Multiple => x86_64 (amd64) Old description: > Tested off commit `9976bed24dda9449ac2e3e95fb4bf8b379114a28`, running on > macOS 10.13.5, trying to compile for iOS. > > 1. Compile a GHC that cross compiles to `x86_64-apple-ios` (i.e. with > `./configure --build=x86_64-apple-darwin --host=x86_64-apple-darwin > --target=x86_64-apple-ios; make`). > 2. Compile a `ghc-iserv` that can run on the build system (i.e. with > `./configure; cd utils/iserv; make`) > 3. Try to cross-compile the following file (i.e `x86_64-apple-ios-ghc > -fexternal-interpreter -pgmi=path/to/ghc-iserv T.hs`): > {{{#!hs > {-# LANGUAGE TemplateHaskell #-} > module T where > $([d| zero = 0 |]) > }}} > > Expected: Compiles fine. > > Actual: > > {{{ > [1 of 1] Compiling T ( T.hs, T.o ) > > T.hs:1:1: error: > Exception when trying to run compile-time code: > heap overflow > Code: [d| zero = 0 |] > | > 1 | {-# LANGUAGE TemplateHaskell #-} > | ^ > }}} > > For more fun: > > * This problem appears to only affect the numeric literal `0`. > * `0.0` is not fine. > * `1` is fine. > * `1 - 1` appears to be a workaround. > * `0.1` is fine. > * "Burying" the `0` inside another expression is not fine (e.g. `zero > = [0]`). > * I can even compile most of `singletons`, and it only chokes when the > `0` literal first appears (`negate x = 0 - x`). > * The `0` has to actually appear in the result. (`$(const [d| |] [d| > zero = 0 |])` is fine.) > * `0#` is not fine. > * This problem only appears when cross-compiling. If I complete the build > of the native GHC above and use it instead of the cross-compiler but > still use `-fexternal-interpreter`, everything is fine. > * Moving the declaration outside of the TH brackets is fine. New description: Tested off `ghc-8.6.1-alpha1`, running on macOS 10.13.5. 1. Compile a GHC that uses `integer-gmp`. 2. Compile a GHC that uses `integer-simple`. 3. Make `Main.hs`: {{{#!hs {-# LANGUAGE TemplateHaskell #-} main = print $([e| 0 |]) }}} 4. Try to compile the file with `integer-gmp` `ghc` and `integer-simple` `ghc-iserv`. * Expected behavior: compiles fine; executable prints `0` * Actual: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:2:14: error: • Exception when trying to run compile-time code: ghc: ghc-iserv terminated (-11) Code: [| 0 |] • In the untyped splice: $([| 0 |]) | 2 | main = print $([e| 0 |]) | ^^^^^^^^^^^ }}} 4. Try to compile the file with `integer-simple` `ghc` and `integer-gmp` `ghc-iserv`. * Expected behavior: compiles fine, executable prints `0`. * Actual: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:2:14: error: • Exception when trying to run compile-time code: heap overflow Code: [| 0 |] • In the untyped splice: $([| 0 |]) | 2 | main = print $([e| 0 |]) | ^^^^^^^^^^^ }}} For more fun, replace the `0` with a `1`. `gmp` `ghc` + `simple` `iserv` continues to explode. This is better than `simple` `ghc` + `gmp` `iserv`: {{{#!bash $ ./Main 283468057265 $ ./Main 283468057265 $ $simple_ghc -fexternal-interpreter -pgmi=$gmp_iserv Main.hs # again # ... $ ./Main 283468057105 }}} Absolutely delicious. There is a similar situation for fractional literals. It would be nice if there was at least a warning for situations like this. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 06:09:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 06:09:49 -0000 Subject: [GHC] #15336: ./System/IO.hs accidentally overridden when running ghci Message-ID: <044.ba3290f444f0e979b7add843365e09fb@haskell.org> #15336: ./System/IO.hs accidentally overridden when running ghci -------------------------------------+------------------------------------- Reporter: luqui | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Keywords: | Operating System: MacOS X Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Running ghci fails if there is a System/IO.hs module present in the current directory. Doesn't seem like desirable behavior. {{{ % mkdir System % touch System/IO.hs % ghci GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help :1:19: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. :1:43: error: Not in scope: ‘System.IO.stdin’ No module named ‘System.IO’ is imported. :1:60: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. :1:99: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. :1:123: error: Not in scope: ‘System.IO.stdout’ No module named ‘System.IO’ is imported. :1:140: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. :1:179: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. :1:203: error: Not in scope: ‘System.IO.stderr’ No module named ‘System.IO’ is imported. :1:220: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 08:14:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 08:14:37 -0000 Subject: [GHC] #15328: cpphs: internal error: evacuate(static): strange closure type 8440 In-Reply-To: <044.e7d3083ced1a98874e271c4b45548264@haskell.org> References: <044.e7d3083ced1a98874e271c4b45548264@haskell.org> Message-ID: <059.fd4c5805215f3b0c31fa717ea77f28a9@haskell.org> #15328: cpphs: internal error: evacuate(static): strange closure type 8440 -------------------------------------+------------------------------------- Reporter: cnmne | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Package system | Version: 8.4.3 Resolution: | Keywords: cabal, cpphs, | strange closure Operating System: MacOS X | Architecture: x86 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): cnmne, if you want to help with debugging this doing the follwoing would be really helpful: - Clone a fresh GHC and cd into the directory - `cp mk/build.mk.sample mk/build.mk` - Edit `mk/build.mk`, add `GhcDebugged = YES` somewhere in that file - Build with `./boot && ./configure && make` - Edit `inplace/bin/ghc-stage2` to add `+RTS -DS -RTS` at the end of the last line (the line starting with `exec ...`) ghc-stage2 is now a debug build with sanity checks enabled. Now install everything again (whatever you need to install to reproduce this) but pass `--with-ghc=path-to-ghc-stage2` to cabal in each command. Hopefully you'll get a better error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 09:16:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 09:16:10 -0000 Subject: [GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin In-Reply-To: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> References: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> Message-ID: <062.4cadeb4e201c4bb81bc94212d4c30cae@haskell.org> #15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | typeable,knownnat Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10348 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, now I understand. I'll add this comment to `TcInteract`: {{{ Note [Typeable for Nat and Symbol] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We have special Typeable instances for Nat and Symbol. Roughly we have this instance, implemented here by doTyLit: instance KnownNat n => Typeable (n :: Nat) where typeRep = tyepNatTypeRep @n where Data.Typeable.Internals.typeNatTypeRep :: KnownNat a => TypeRep a Ultimately typeNatTypeRep uses 'natSing' from KnownNat to get a runtime value 'n'; it turns it into a string with 'show' and uses that to whiz up a TypeRep TyCon for 'n', with mkTypeLitTyCon. See #10348. Because of this rule it's inadvisable (see #15322) to have a constraint f :: (Typeable (n :: Nat)) => blah in a function signature; it gives rise to overlap problems just as if you'd written f :: Eq [a] => blah }}} Note the "inadvisable" part, which is what this ticket is about. It just wasn't at all clear to me, and hence perhaps not to others. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 09:20:32 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 09:20:32 -0000 Subject: [GHC] #15335: Export `findImportUsage` from `rename/RnNames.hs` module In-Reply-To: <047.137c5faaec024c503e5607145a3daa2f@haskell.org> References: <047.137c5faaec024c503e5607145a3daa2f@haskell.org> Message-ID: <062.fd07d16b717c9dd7520c142972250cff@haskell.org> #15335: Export `findImportUsage` from `rename/RnNames.hs` module -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | imports,refactoring,export Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4927 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * differential: => Phab:D4927 Comment: Thanks. Good ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 09:35:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 09:35:02 -0000 Subject: [GHC] #15063: T3001-2 fails on i386 Linux In-Reply-To: <046.fa478fb40ce13bbb24172a958e864762@haskell.org> References: <046.fa478fb40ce13bbb24172a958e864762@haskell.org> Message-ID: <061.b54f12f10f3d5a4817e0b797de85dc36@haskell.org> #15063: T3001-2 fails on i386 Linux -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Profiling | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15087, #15165, | Differential Rev(s): Phab:D4928 #7836 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D4928 Comment: > Closure type 7 is CONSTR_NOCAF, which is indeed invalid. Tracking this down will take some debugging. Why do you think CONSTR_NOCAF is invalid here? We allocate CONSTR_NOCAFs in heap and we need to handle this in `processHeapClosureForDead`. I submitted a patch for this with more explanation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 09:35:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 09:35:30 -0000 Subject: [GHC] #15087: Internal Error with Bibliography Profiling In-Reply-To: <047.4e3533cfbf44e6814004409e34e96335@haskell.org> References: <047.4e3533cfbf44e6814004409e34e96335@haskell.org> Message-ID: <062.b494b37ac675a64572940e0ed7758667@haskell.org> #15087: Internal Error with Bibliography Profiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063, #15165, | Differential Rev(s): Phab:D4928 #7836 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D4928 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 09:35:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 09:35:44 -0000 Subject: [GHC] #15165: GHC 8.2.2: internal error with +RTS -hb In-Reply-To: <043.05bd633e0b8fc1db67420a68577349a9@haskell.org> References: <043.05bd633e0b8fc1db67420a68577349a9@haskell.org> Message-ID: <058.1e383ae72b6e3d556d997a1f9ce3e73c@haskell.org> #15165: GHC 8.2.2: internal error with +RTS -hb -------------------------------------+------------------------------------- Reporter: kfiz | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Profiling | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063, #15087, | Differential Rev(s): Phab:D4928 #7836 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D4928 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 09:35:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 09:35:59 -0000 Subject: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb In-Reply-To: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> References: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> Message-ID: <064.a0ef8d54f64bcc62583a0d7e3bf0bc70@haskell.org> #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063, #15087, | Differential Rev(s): Phab:D4928 #15165 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * differential: Phab:D4567 => Phab:D4928 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 09:38:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 09:38:22 -0000 Subject: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb In-Reply-To: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> References: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> Message-ID: <064.adb0da32fa2a14d6ea583573bb4b264b@haskell.org> #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063, #15087, | Differential Rev(s): Phab:D4928 #15165 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): The bug as originally reported (`Invalid object in processHeapClosureForDead(): 60`) can't happen with modern GHCs as we handle closure 60 already, but the bug in comment:16 is fixed in Phab:D4928. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 10:23:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 10:23:41 -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.c5be1d109d4aeca3b0e8d694d7b6df20@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:44 simonpj]: > * Binary sizes go up 5% when "GHC is compiled with -fno-state-hack". I think that the important thing is that the '''libraries''' (which are linked into the nofib binary) are compiled with -fno-state-hack. I doubt it's caused by the fact that ghc-stage2 is compiled with -fno-state-hack. Can you confirm? > > * And if binary sizes go up by 5% because the libraries are getting bigger, is that a generic 5% increase in .o file size? Or do a few key modules get a lot bigger? It's puzzling because the per-moudule "Module Sizes" stats in the nofib log suggest that there is an essentially-zero effect on nofib module sizes. I did some more analyzing, and unfortunately the answer is "it's complicated". I compared module sizes for every .o in the GHC build tree between the two versions, and I'm getting mixed results. Some modules get significantly smaller when disabling the state hack, on the order of 10-50%, with some outliers as high as 70%. On the other end of the spectrum, there are lots of modules that blow up by several megabytes per module, percentages typically somewhere between 25% and 80%. There is also a large number of modules where the difference is small or zero. The differences aren't isolated in libraries; in all 3 categories, modules are mostly from `/libraries`, `/bootstrapping`, and `/compiler`. So it's definitely not just the libraries that blow up; it seems that GHC actually produces larger modules, but not always. I have not managed to find a pattern to the increase yet. So here's the 30 modules with the biggest shrinkage: {{{ diff diff% hack no hack file -598704 -4% 14142232 13543528 compiler/stage2/build/HsInstances.o -232504 -36% 637000 404496 bootstrapping/Distribution/Simple/Utils.o -222928 -34% 638856 415928 libraries/Cabal/Cabal/dist- boot/build/Distribution/Simple/Utils.o -179816 -17% 1020496 840680 libraries/Cabal/Cabal/dist- boot/build/Distribution/PackageDescription/Check.o -177744 -17% 1015896 838152 bootstrapping/Distribution/PackageDescription/Check.o -144352 -24% 595592 451240 libraries/Cabal/Cabal/dist- boot/build/Distribution/Simple/Haddock.o -142432 -14% 968752 826320 bootstrapping/Distribution/Simple/Configure.o -137632 -14% 973336 835704 libraries/Cabal/Cabal/dist- boot/build/Distribution/Simple/Configure.o -136384 -23% 583088 446704 bootstrapping/Distribution/Simple/Haddock.o -131840 -13% 952160 820320 bootstrapping/Distribution/Simple/GHC.o -125008 -13% 955352 830344 libraries/Cabal/Cabal/dist- boot/build/Distribution/Simple/GHC.o -117728 -27% 422008 304280 bootstrapping/Distribution/Simple/Build.o -116264 -27% 424320 308056 libraries/Cabal/Cabal/dist- boot/build/Distribution/Simple/Build.o -108816 -18% 579808 470992 bootstrapping/Distribution/Simple/GHCJS.o -103808 -11% 884696 780888 utils/ghc-pkg/dist/build/Main.o -103280 -17% 581736 478456 libraries/Cabal/Cabal/dist- boot/build/Distribution/Simple/GHCJS.o -98288 -18% 532488 434200 utils/genprimopcode/dist/build/Main.o -92480 -16% 570120 477640 bootstrapping/Distribution/Simple.o -85024 -14% 573280 488256 libraries/Cabal/Cabal/dist- boot/build/Distribution/Simple.o -83632 -19% 433448 349816 utils/hsc2hs/dist/build/CrossCodegen.o -82520 -29% 281280 198760 bootstrapping/Distribution/Simple/SrcDist.o -81808 -28% 282832 201024 libraries/Cabal/Cabal/dist- boot/build/Distribution/Simple/SrcDist.o -78920 -55% 141696 62776 bootstrapping/Data/Text/Internal/Lazy/Encoding/Fusion.o -77768 -43% 180664 102896 bootstrapping/Data/Text/Encoding.o -72824 -71% 102400 29576 bootstrapping/Data/Text/Internal.o -69456 -49% 140888 71432 bootstrapping/System/FilePath/Posix.o -66136 -39% 168512 102376 bootstrapping/Distribution/PackageDescription/Quirks.o -61280 -15% 392096 330816 libraries/Cabal/Cabal/dist- boot/build/Distribution/Simple/PreProcess.o -59848 -35% 167816 107968 libraries/Cabal/Cabal/dist- boot/build/Distribution/PackageDescription/Quirks.o -58456 -15% 385944 327488 bootstrapping/Distribution/Simple/PreProcess.o }}} And the 30 worst offenders: {{{ diff diff% hack no hack file 242872 +42% 330888 573760 libraries/Cabal/Cabal/dist- boot/build/Distribution/PackageDescription/Parsec.o 252096 +18% 1130080 1382176 libraries/Cabal/Cabal/dist- boot/build/Language/Haskell/Extension.o 276872 +9% 2649696 2926568 libraries/containers/dist- install/build/Data/Sequence/Internal.o 282112 +50% 280448 562560 compiler/stage2/build/TcBackpack.o 286208 +21% 1039800 1326008 bootstrapping/Language/Haskell/Extension.o 293664 +43% 387048 680712 bootstrapping/Distribution/Types/GenericPackageDescription.o 295776 +42% 400880 696656 libraries/Cabal/Cabal/dist- boot/build/Distribution/Types/GenericPackageDescription.o 308792 +40% 462576 771368 libraries/template-haskell/dist- boot/build/Language/Haskell/TH/Ppr.o 320800 +28% 786912 1107712 compiler/stage2/build/PPC/CodeGen.o 326400 +38% 520592 846992 libraries/text/dist- install/build/Data/Text/Lazy/Builder/RealFloat.o 350016 +32% 719512 1069528 compiler/stage2/build/PlatformConstants.o 410272 +2% 14146704 14556976 libraries/base/dist- install/build/HSbase-4.12.0.0.o 413960 +35% 748952 1162912 libraries/Cabal/Cabal/dist- install/build/Distribution/Simple/Haddock.o 430824 +27% 1157400 1588224 compiler/stage2/build/X86/CodeGen.o 450928 +29% 1078688 1529616 compiler/stage2/build/TcRnDriver.o 530216 +100% 0 530216 libraries/xhtml/dist- install/build/HSxhtml-3000.2.2.o 563744 +77% 166952 730696 bootstrapping/Distribution/Types/InstalledPackageInfo/FieldGrammar.o 581784 +77% 170552 752336 libraries/Cabal/Cabal/dist- boot/build/Distribution/Types/InstalledPackageInfo/FieldGrammar.o 583760 +44% 731800 1315560 libraries/ghci/dist- boot/build/GHCi/Message.o 593424 +12% 4286120 4879544 libraries/containers/dist- install/build/HScontainers-0.5.11.0.o 614096 +16% 3213320 3827416 libraries/text/dist- install/build/HStext-1.2.3.0.o 747024 +41% 1063368 1810392 libraries/ghci/dist- boot/build/GHCi/TH/Binary.o 952864 +27% 2503640 3456504 libraries/Cabal/Cabal/dist- boot/build/Distribution/SPDX/LicenseId.o 992784 +29% 2330808 3323592 bootstrapping/Distribution/SPDX/LicenseId.o 1004432 +43% 1328968 2333400 libraries/Cabal/Cabal/dist- install/build/Distribution/Simple/GHC.o 1032072 +72% 382160 1414232 bootstrapping/Distribution/PackageDescription/FieldGrammar.o 1035032 +72% 392264 1427296 libraries/Cabal/Cabal/dist- boot/build/Distribution/PackageDescription/FieldGrammar.o 1212056 +29% 2905776 4117832 libraries/template-haskell/dist- boot/build/Language/Haskell/TH/Syntax.o 2236208 +62% 1317096 3553304 libraries/Cabal/Cabal/dist- install/build/Distribution/Simple/Configure.o 4569096 +10% 38406248 42975344 libraries/Cabal/Cabal/dist- install/build/HSCabal-2.3.0.0.o }}} I'll attach the full comparison log. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 10:24:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 10:24:47 -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.efaaa63e6ce2dd174e25bb78841a96a2@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * Attachment "module-size-comparison" added. Comparing module sizes in a GHC build tree -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 10:41:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 10:41:29 -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.c03368f0828d62e30e39fbadf37d7057@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Oh dear. It turns out my bash script that I used to automatically build the required GHC's and run nofib had a bug that caused it to silently ignore mistyped build flavours, so instead of "GHC compiled with -fno- state-hack", I got "GHC compiled with the default flavour". Which explains the whopping difference: where I thought I was comparing "GHC compiled with -prof -fno-state-hack vs. GHC compiled with -prof", I was actually comparing "GHC release build vs. GHC prof build". Fortunately, the nofib flags were correct, so the part about the effect of `-fno-state-hack` on the nofib suite remains valid. I'll re-run the tests for "GHC compiled with -fno-state-hack", and I'll also throw in "Boot libraries compiled with -fno-state-hack, GHC compiled normally". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 11:56:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 11:56:46 -0000 Subject: [GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin In-Reply-To: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> References: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> Message-ID: <062.96be00bb6e051d2d2f136d7c1d74a674@haskell.org> #15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | typeable,knownnat Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10348 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This seems unfortunate to me. I wonder if it would be better to have {{{#!hs getNat :: TypeRep (n :: Nat) -> Natural }}} and then dispense with `KnownNat`. If I were guessing which were primitive between `KnownNat` and `Typeable`, I would guess `Typeable`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 12:12:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 12:12:19 -0000 Subject: [GHC] #15249: Add support for cmpeq and cmpgt MMX intrinsics In-Reply-To: <047.176ece8eb8a34d6eb4b3724ae61ef561@haskell.org> References: <047.176ece8eb8a34d6eb4b3724ae61ef561@haskell.org> Message-ID: <062.a0b0b7cfb657149e5a6afcb72a1b8bfa@haskell.org> #15249: Add support for cmpeq and cmpgt MMX intrinsics -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: newhoggy Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: primops Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by newhoggy): For motivation, SIMD instructions are really good for writing very high performance parsers. For example, the following C example shows a short C program using AVX2 intrinsics to produce a Rank-Select-Bit-String from a CSV file that can be used to index into the CSV file: https://github.com/haskell-works/hw-dsv/tree/simd The program is able to index a 7G CSV file in under 4s: {{{ $ time ./simd ./simd 1.10s user 2.34s system 89% cpu 3.840 total }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 12:18:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 12:18:09 -0000 Subject: [GHC] #15249: Add support for cmpeq and cmpgt MMX intrinsics In-Reply-To: <047.176ece8eb8a34d6eb4b3724ae61ef561@haskell.org> References: <047.176ece8eb8a34d6eb4b3724ae61ef561@haskell.org> Message-ID: <062.514841f19f493db2e018ab592d3d66b9@haskell.org> #15249: Add support for cmpeq and cmpgt MMX intrinsics -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: newhoggy Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: primops Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by newhoggy): To implement this in pure haskell, I would need equivalent primops for the following CPU intrinsics: {{{ _mm256_set1_epi8 _mm256_cmpeq_epi8 _mm256_movemask_epi8 _mm256_cmpeq_epi8 _mm256_movemask_epi8 _mm256_maskload_epi64 _mm256_maskstore_epi64 }}} See: https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=vpmaskmovq&expand=765,767,802,5241,3295,3296,3297 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 12:25:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 12:25:28 -0000 Subject: [GHC] #15337: Warning not showing up when deprecated variable is explicitly imported Message-ID: <046.eac70ab0086dceacc7da0405feddb32c@haskell.org> #15337: Warning not showing up when deprecated variable is explicitly imported -------------------------------------+------------------------------------- Reporter: alanasp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: deprecation | Operating System: Unknown/Multiple warning | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the case below a deprecation warning does not show up. {{{#!hs {- ModuleA -} module ModuleA where {-# DEPRECATED func "func is deprecated" #-} func :: Int func = 42 {- ModuleB -} module ModuleB where import ModuleA(func) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 12:39:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 12:39:30 -0000 Subject: [GHC] #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) In-Reply-To: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> References: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> Message-ID: <065.3c171face1fff8eb3cd8d485c3d3321f@haskell.org> #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): When I write `foo :: (C a, D a b) => a -> b -> a`, I'm not thinking that my function expects a given tuple. I'm expecting a given `C a` and `D a b`. The parentheses-and-comma are just concrete syntax. I know it's not implemented that way, but that's the programmer's view. Along similar lines, I would expect `forall a b. (C a, D a b)` to be shorthand for `forall a b. C a` and `forall a b. D a b`. There's really no other sensible interpretation (as you point out), so let's just add this as a special case, just as `(C a, D a b) => ...` is a special syntax for `C a => D a b => ...`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 12:46:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 12:46:21 -0000 Subject: [GHC] #14025: Object file of a dependent c-file is put in wrong directory when this dependent is specified with a path (was: Object of a dependent c-file is put in wrong directory when this dependent is specified with a path) In-Reply-To: <046.48759c75ff80de33ebc22ad9a6eaaf3e@haskell.org> References: <046.48759c75ff80de33ebc22ad9a6eaaf3e@haskell.org> Message-ID: <061.f89e30c810fc7f19a06a79e70df3e2eb@haskell.org> #14025: Object file of a dependent c-file is put in wrong directory when this dependent is specified with a path -------------------------------------+------------------------------------- Reporter: literon | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | driver/T14025, driver/T14025a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Pahb: D Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * status: new => patch * testcase: => driver/T14025, driver/T14025a * differential: => Pahb: D Comment: Patch uploaded to https://phabricator.haskell.org/D4930 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 12:47:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 12:47:01 -0000 Subject: [GHC] #14025: Object file of a dependent c-file is put in wrong directory when this dependent is specified with a path In-Reply-To: <046.48759c75ff80de33ebc22ad9a6eaaf3e@haskell.org> References: <046.48759c75ff80de33ebc22ad9a6eaaf3e@haskell.org> Message-ID: <061.aea50d862700b351a302e138b0a27297@haskell.org> #14025: Object file of a dependent c-file is put in wrong directory when this dependent is specified with a path -------------------------------------+------------------------------------- Reporter: literon | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | driver/T14025, driver/T14025a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Pahb: D4930 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * differential: Pahb: D => Pahb: D4930 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 12:47:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 12:47:47 -0000 Subject: [GHC] #14025: Object file of a dependent c-file is put in wrong directory when this dependent is specified with a path In-Reply-To: <046.48759c75ff80de33ebc22ad9a6eaaf3e@haskell.org> References: <046.48759c75ff80de33ebc22ad9a6eaaf3e@haskell.org> Message-ID: <061.799e1751d4349b493f60857d979ec878@haskell.org> #14025: Object file of a dependent c-file is put in wrong directory when this dependent is specified with a path -------------------------------------+------------------------------------- Reporter: literon | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | driver/T14025, driver/T14025a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D4930 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * differential: Pahb: D4930 => Phab: D4930 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 12:53:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 12:53:29 -0000 Subject: [GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin In-Reply-To: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> References: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> Message-ID: <062.4d0d84cb278d08a327539a34d5e8bc95@haskell.org> #15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | typeable,knownnat Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10348 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Dispensing with `KnownNat` would be a worthwhile simplification. How would we implement `getNat`? It might not be hard: just add an extra data constructor to `TyCon` perhaps. But someone would have to think about it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 15:12:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 15:12:24 -0000 Subject: [GHC] #15136: High CPU when asynchronous exception and unblocking retry on TVar raced In-Reply-To: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> References: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> Message-ID: <062.a3294bc4e42f1484de7e83a672f255db@haskell.org> #15136: High CPU when asynchronous exception and unblocking retry on TVar raced -------------------------------------+------------------------------------- Reporter: nshimaza | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * owner: (none) => osa1 Comment: I'll try implementing comment:5 see how it goes. This code path is not tested enough so I'll also try to port some of concurrency tests that use MVar and async exceptions (exercising `raiseAsync()`) to STM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 15:21:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 15:21:57 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.d418518d87d4e4702d2a6a690639f072@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > I've made it a little further in my experiments with unboxed tuples in > the `packed` library. However, I've run into another issue that I > strongly suspect is the result of bad behavior of unboxed tuples. To > replicate this issue (with GHC 8.4.3), do the following: > > {{{ > git clone https://github.com/andrewthad/packed > cd packed > cabal new-build > }}} > > We use `cabal new-build` for its side effect of creating a > `.ghc.environment.xyz` file. Now, create a minimal example in the > directory called `eol.hs` with the following contents: > > {{{ > import Packed.Bytes.Parser (Parser) > import Data.Word > import Packed.Bytes (Bytes) > import GHC.Exts (RealWorld) > import Packed.Bytes.Stream.IO (ByteStream) > import qualified Packed.Bytes as B > import qualified Data.Char > import qualified Packed.Bytes.Parser as P > import qualified Packed.Bytes.Stream.IO as Stream > > main :: IO () > main = do > r <- runExampleParser > ( do P.takeBytesUntilEndOfLineConsume > P.takeBytesUntilEndOfLineConsume > P.takeBytesUntilEndOfLineConsume > ) (foldMap Stream.singleton (map charToWord8 > "the\nemporium\rhas\narrived")) > print r > > runExampleParser :: Parser e () a -> ByteStream RealWorld -> IO (Maybe a, > Maybe String) > runExampleParser parser stream = do > P.Result mleftovers r _ <- P.parseStreamIO stream () parser > mextra <- case mleftovers of > Nothing -> return Nothing > Just (P.Leftovers chunk remainingStream) -> do > bs <- Stream.unpack remainingStream > return (Just (map word8ToChar (B.unpack chunk ++ bs))) > return (either (const Nothing) Just r,mextra) > > word8ToChar :: Word8 -> Char > word8ToChar = Data.Char.chr . fromIntegral > > charToWord8 :: Char -> Word8 > charToWord8 = fromIntegral . Data.Char.ord > > s2b :: String -> Bytes > s2b = B.pack . map charToWord8 > > c2w :: Char -> Word8 > c2w = charToWord8 > }}} > > Finally, build this with `ghc -O2 eol.hs`, and then run the executable > this produces to get the following: > > {{{ > (Nothing,Just "\rhas\narrived") > eol: internal error: stg_ap_n_ret > (GHC version 8.4.3 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > Aborted (core dumped) > }}} > > Things worth noting: > > 1. I think the program fails in the final GC that runs right before the > program terminates. We can see that it produces a correct result of > `(Nothing,Just "\rhas\narrived")`, but something on the heap has > definitely been corrupted. > 2. This only happens with `-O2` turned on. > 3. This only happens when the parser does not successfully parse its > input. > > Here's some more context around this. I've been working on a parser that > uses unboxed sums instead of continuations. After #15038 was fixed, > everything had been going well. Then, I took the parser type and added > two things to it: (1) context and (2) typed errors. Context is basically > like throwing `StateT` on top and errors are like throwing `ExceptT` on > top. After this, everything in my test suite kept working except for a > single test, which now consistently crashes my test suite. So, I > originally had this: > > {{{ > type Bytes# = (# ByteArray#, Int#, Int# #) > type Maybe# (a :: TYPE r) = (# (# #) | a #) > type Leftovers# s = (# Bytes# , ByteStream s #) > type Result# s (r :: RuntimeRep) (a :: TYPE r) = > (# Maybe# (Leftovers# s), Maybe# a #) > newtype ParserLevity (r :: RuntimeRep) (a :: TYPE r) = ParserLevity > { getParserLevity :: forall s. > Maybe# (Leftovers# s) > -> State# s > -> (# State# s, Result# s r a #) > } > }}} > > But I changed it to this: > > {{{ > type Bytes# = (# ByteArray#, Int#, Int# #) > type Maybe# (a :: TYPE r) = (# (# #) | a #) > type Either# a (b :: TYPE r) = (# a | b #) > type Leftovers# s = (# Bytes# , ByteStream s #) > type Result# e c s (r :: RuntimeRep) (a :: TYPE r) = > (# Maybe# (Leftovers# s), Either# (Maybe e) a, c #) > > newtype ParserLevity e c (r :: RuntimeRep) (a :: TYPE r) = ParserLevity > { getParserLevity :: forall s. > c > -> Maybe# (Leftovers# s) > -> State# s > -> (# State# s, Result# e c s r a #) > } > }}} > > Specifically, the function causing trouble is (as currently defined): > > {{{ > {-# NOINLINE takeBytesUntilEndOfLineConsumeUnboxed #-} > takeBytesUntilEndOfLineConsumeUnboxed :: ParserLevity e c BytesRep Bytes# > takeBytesUntilEndOfLineConsumeUnboxed = ParserLevity (go (# (# #) | #)) > where > go :: Maybe# Bytes# -> c -> Maybe# (Leftovers# s) -> State# s -> (# > State# s, Result# e c s BytesRep Bytes# #) > go !_ c (# (# #) | #) s0 = (# s0, (# (# (# #) | #), (# Nothing | #), c > #) #) > go !mbytes c (# | (# bytes0@(# arr0, off0, len0 #), > !stream0@(ByteStream streamFunc) #) #) s0 = case BAW.findAnyByte2 (I# > off0) (I# len0) 10 13 (ByteArray arr0) of > Nothing -> case streamFunc s0 of > (# s1, r #) -> go (# | appendMaybeBytes mbytes bytes0 #) c r s1 > Just (I# ix, W8# theByte) -> case theByte of > 10## -> (# s0, (# (# | (# unsafeDrop# ((ix -# off0) +# 1# ) bytes0, > stream0 #) #), (# | appendMaybeBytes mbytes (# arr0, off0, ix -# off0 #) > #), c #) #) > -- second case means it was 13 > _ -> case ix <# (off0 +# len0 -# 1#) of > 1# -> case indexWord8Array# arr0 (ix +# 1# ) of > 10## -> (# s0, (# (# | (# unsafeDrop# ((ix -# off0) +# 2# ) > bytes0, stream0 #) #), (# | appendMaybeBytes mbytes (# arr0, off0, ix -# > off0 #) #), c #) #) > _ -> (# s0, (# (# | (# unsafeDrop# (ix -# off0) bytes0, stream0 > #) #), (# Nothing | #), c #) #) > _ -> case nextNonEmpty stream0 s0 of > (# s1, m #) -> case m of > (# (# #) | #) -> (# s1, (# (# | (# unboxBytes (B.singleton > 13), Stream.empty #) #), (# Nothing | #), c #) #) > (# | (# bytes1@(# arr1, _, _ #), stream1 #) #) -> case > indexWord8Array# arr1 0# of > 10## -> (# s1, (# (# | (# unsafeDrop# 1# bytes1, stream1 #) > #), (# | appendMaybeBytes mbytes (# arr0, off0, ix -# off0 #) #), c #) #) > _ -> (# s1, (# (# | (# unboxBytes (B.cons 13 (boxBytes > bytes1)), stream1 #) #), (# Nothing | #), c #) #) > }}} > > That's all I've got for now. If no one's able to make headway, I'll > probably come back to this and try to make a more minimal example at some > point. I won't have time to do this soon though. New description: I've made it a little further in my experiments with unboxed tuples in the `packed` library. However, I've run into another issue that I strongly suspect is the result of bad behavior of unboxed tuples. To replicate this issue (with GHC 8.4.3), do the following: {{{ git clone https://github.com/andrewthad/packed cd packed cabal new-build }}} We use `cabal new-build` for its side effect of creating a `.ghc.environment.xyz` file. Now, create a minimal example in the directory called `eol.hs` with the following contents: {{{#!hs import Packed.Bytes.Parser (Parser) import Data.Word import Packed.Bytes (Bytes) import GHC.Exts (RealWorld) import Packed.Bytes.Stream.IO (ByteStream) import qualified Packed.Bytes as B import qualified Data.Char import qualified Packed.Bytes.Parser as P import qualified Packed.Bytes.Stream.IO as Stream main :: IO () main = do r <- runExampleParser ( do P.takeBytesUntilEndOfLineConsume P.takeBytesUntilEndOfLineConsume P.takeBytesUntilEndOfLineConsume ) (foldMap Stream.singleton (map charToWord8 "the\nemporium\rhas\narrived")) print r runExampleParser :: Parser e () a -> ByteStream RealWorld -> IO (Maybe a, Maybe String) runExampleParser parser stream = do P.Result mleftovers r _ <- P.parseStreamIO stream () parser mextra <- case mleftovers of Nothing -> return Nothing Just (P.Leftovers chunk remainingStream) -> do bs <- Stream.unpack remainingStream return (Just (map word8ToChar (B.unpack chunk ++ bs))) return (either (const Nothing) Just r,mextra) word8ToChar :: Word8 -> Char word8ToChar = Data.Char.chr . fromIntegral charToWord8 :: Char -> Word8 charToWord8 = fromIntegral . Data.Char.ord s2b :: String -> Bytes s2b = B.pack . map charToWord8 c2w :: Char -> Word8 c2w = charToWord8 }}} Finally, build this with `ghc -O2 eol.hs`, and then run the executable this produces to get the following: {{{ (Nothing,Just "\rhas\narrived") eol: internal error: stg_ap_n_ret (GHC version 8.4.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} Things worth noting: 1. I think the program fails in the final GC that runs right before the program terminates. We can see that it produces a correct result of `(Nothing,Just "\rhas\narrived")`, but something on the heap has definitely been corrupted. 2. This only happens with `-O2` turned on. 3. This only happens when the parser does not successfully parse its input. Here's some more context around this. I've been working on a parser that uses unboxed sums instead of continuations. After #15038 was fixed, everything had been going well. Then, I took the parser type and added two things to it: (1) context and (2) typed errors. Context is basically like throwing `StateT` on top and errors are like throwing `ExceptT` on top. After this, everything in my test suite kept working except for a single test, which now consistently crashes my test suite. So, I originally had this: {{{#!hs type Bytes# = (# ByteArray#, Int#, Int# #) type Maybe# (a :: TYPE r) = (# (# #) | a #) type Leftovers# s = (# Bytes# , ByteStream s #) type Result# s (r :: RuntimeRep) (a :: TYPE r) = (# Maybe# (Leftovers# s), Maybe# a #) newtype ParserLevity (r :: RuntimeRep) (a :: TYPE r) = ParserLevity { getParserLevity :: forall s. Maybe# (Leftovers# s) -> State# s -> (# State# s, Result# s r a #) } }}} But I changed it to this: {{{#!hs type Bytes# = (# ByteArray#, Int#, Int# #) type Maybe# (a :: TYPE r) = (# (# #) | a #) type Either# a (b :: TYPE r) = (# a | b #) type Leftovers# s = (# Bytes# , ByteStream s #) type Result# e c s (r :: RuntimeRep) (a :: TYPE r) = (# Maybe# (Leftovers# s), Either# (Maybe e) a, c #) newtype ParserLevity e c (r :: RuntimeRep) (a :: TYPE r) = ParserLevity { getParserLevity :: forall s. c -> Maybe# (Leftovers# s) -> State# s -> (# State# s, Result# e c s r a #) } }}} Specifically, the function causing trouble is (as currently defined): {{{#!hs {-# NOINLINE takeBytesUntilEndOfLineConsumeUnboxed #-} takeBytesUntilEndOfLineConsumeUnboxed :: ParserLevity e c BytesRep Bytes# takeBytesUntilEndOfLineConsumeUnboxed = ParserLevity (go (# (# #) | #)) where go :: Maybe# Bytes# -> c -> Maybe# (Leftovers# s) -> State# s -> (# State# s, Result# e c s BytesRep Bytes# #) go !_ c (# (# #) | #) s0 = (# s0, (# (# (# #) | #), (# Nothing | #), c #) #) go !mbytes c (# | (# bytes0@(# arr0, off0, len0 #), !stream0@(ByteStream streamFunc) #) #) s0 = case BAW.findAnyByte2 (I# off0) (I# len0) 10 13 (ByteArray arr0) of Nothing -> case streamFunc s0 of (# s1, r #) -> go (# | appendMaybeBytes mbytes bytes0 #) c r s1 Just (I# ix, W8# theByte) -> case theByte of 10## -> (# s0, (# (# | (# unsafeDrop# ((ix -# off0) +# 1# ) bytes0, stream0 #) #), (# | appendMaybeBytes mbytes (# arr0, off0, ix -# off0 #) #), c #) #) -- second case means it was 13 _ -> case ix <# (off0 +# len0 -# 1#) of 1# -> case indexWord8Array# arr0 (ix +# 1# ) of 10## -> (# s0, (# (# | (# unsafeDrop# ((ix -# off0) +# 2# ) bytes0, stream0 #) #), (# | appendMaybeBytes mbytes (# arr0, off0, ix -# off0 #) #), c #) #) _ -> (# s0, (# (# | (# unsafeDrop# (ix -# off0) bytes0, stream0 #) #), (# Nothing | #), c #) #) _ -> case nextNonEmpty stream0 s0 of (# s1, m #) -> case m of (# (# #) | #) -> (# s1, (# (# | (# unboxBytes (B.singleton 13), Stream.empty #) #), (# Nothing | #), c #) #) (# | (# bytes1@(# arr1, _, _ #), stream1 #) #) -> case indexWord8Array# arr1 0# of 10## -> (# s1, (# (# | (# unsafeDrop# 1# bytes1, stream1 #) #), (# | appendMaybeBytes mbytes (# arr0, off0, ix -# off0 #) #), c #) #) _ -> (# s1, (# (# | (# unboxBytes (B.cons 13 (boxBytes bytes1)), stream1 #) #), (# Nothing | #), c #) #) }}} That's all I've got for now. If no one's able to make headway, I'll probably come back to this and try to make a more minimal example at some point. I won't have time to do this soon though. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 15:30:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 15:30:54 -0000 Subject: [GHC] #15059: ghcpkg05 fails In-Reply-To: <046.1f7d576a8754e183a4eb98c291d7d3d3@haskell.org> References: <046.1f7d576a8754e183a4eb98c291d7d3d3@haskell.org> Message-ID: <061.776ec7962ee006f4a954229903906856@haskell.org> #15059: ghcpkg05 fails -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): We are a bit stuck on this one because we can't reproduce it reliably (or even, currently, at all). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 15:30:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 15:30:59 -0000 Subject: [GHC] #15262: GHC and iserv cannot agree on what an Integer is; insanity ensues In-Reply-To: <050.8f7705015e16ef64b51a5dbaaaac982c@haskell.org> References: <050.8f7705015e16ef64b51a5dbaaaac982c@haskell.org> Message-ID: <065.a372fae47e8d99d3a48adca3d4fa5bad@haskell.org> #15262: GHC and iserv cannot agree on what an Integer is; insanity ensues -------------------------------------+------------------------------------- Reporter: howtonotwin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by howtonotwin: Old description: > Tested off `ghc-8.6.1-alpha1`, running on macOS 10.13.5. > > 1. Compile a GHC that uses `integer-gmp`. > 2. Compile a GHC that uses `integer-simple`. > 3. Make `Main.hs`: > {{{#!hs > {-# LANGUAGE TemplateHaskell #-} > main = print $([e| 0 |]) > }}} > 4. Try to compile the file with `integer-gmp` `ghc` and `integer-simple` > `ghc-iserv`. > * Expected behavior: compiles fine; executable prints `0` > * Actual: > {{{ > [1 of 1] Compiling Main ( Main.hs, Main.o ) > > Main.hs:2:14: error: > • Exception when trying to run compile-time code: > ghc: ghc-iserv terminated (-11) > Code: [| 0 |] > • In the untyped splice: $([| 0 |]) > | > 2 | main = print $([e| 0 |]) > | ^^^^^^^^^^^ > }}} > > 4. Try to compile the file with `integer-simple` `ghc` and `integer-gmp` > `ghc-iserv`. > * Expected behavior: compiles fine, executable prints `0`. > * Actual: > {{{ > [1 of 1] Compiling Main ( Main.hs, Main.o ) > > Main.hs:2:14: error: > • Exception when trying to run compile-time code: > heap overflow > Code: [| 0 |] > • In the untyped splice: $([| 0 |]) > | > 2 | main = print $([e| 0 |]) > | ^^^^^^^^^^^ > }}} > > For more fun, replace the `0` with a `1`. `gmp` `ghc` + `simple` `iserv` > continues to explode. This is better than `simple` `ghc` + `gmp` `iserv`: > > {{{#!bash > $ ./Main > 283468057265 > $ ./Main > 283468057265 > $ $simple_ghc -fexternal-interpreter -pgmi=$gmp_iserv Main.hs # again > # ... > $ ./Main > 283468057105 > }}} > > Absolutely delicious. There is a similar situation for fractional > literals. > > It would be nice if there was at least a warning for situations like > this. New description: Tested off `ghc-8.6.1-alpha1`, running on macOS 10.13.5. 1. Compile a GHC that uses `integer-gmp`. 2. Compile a GHC that uses `integer-simple`. 3. Make `Main.hs`: {{{#!hs {-# LANGUAGE TemplateHaskell #-} main = print $([e| 0 |]) }}} 4. Try to compile the file with `integer-gmp` `ghc` and `integer-simple` `ghc-iserv`. * Expected behavior: (compiles fine and executable prints `0`) or (outputs to-the-point error message) * Actual: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:2:14: error: • Exception when trying to run compile-time code: ghc: ghc-iserv terminated (-11) Code: [| 0 |] • In the untyped splice: $([| 0 |]) | 2 | main = print $([e| 0 |]) | ^^^^^^^^^^^ }}} 4. Try to compile the file with `integer-simple` `ghc` and `integer-gmp` `ghc-iserv`. * Expected behavior: (compiles fine and executable prints `0`) or (outputs to-the-point error message) * Actual: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:2:14: error: • Exception when trying to run compile-time code: heap overflow Code: [| 0 |] • In the untyped splice: $([| 0 |]) | 2 | main = print $([e| 0 |]) | ^^^^^^^^^^^ }}} For more fun, replace the `0` with a `1`. `gmp` `ghc` + `simple` `iserv` continues to explode. This is better than `simple` `ghc` + `gmp` `iserv`: {{{#!bash $ ./Main 283468057265 $ ./Main 283468057265 $ $simple_ghc -fexternal-interpreter -pgmi=$gmp_iserv Main.hs # again # ... $ ./Main 283468057105 }}} Absolutely delicious. There is a similar situation for fractional literals. It would be nice if there was at least a warning for situations like this. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 15:34:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 15:34:13 -0000 Subject: [GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 In-Reply-To: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> References: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> Message-ID: <066.77c43ffd95d323bd3b6ebbf618a2b77f@haskell.org> #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 15:41:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 15:41:24 -0000 Subject: [GHC] #15321: Typed holes in Template Haskell splices produce bewildering error messages In-Reply-To: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> References: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> Message-ID: <065.34634c28a7b466e3ea3d5c3bb82bb0ea@haskell.org> #15321: Typed holes in Template Haskell splices produce bewildering error messages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.8.1 => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 15:41:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 15:41:35 -0000 Subject: [GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker In-Reply-To: <049.2656489ff85910f6a80bbfa971643315@haskell.org> References: <049.2656489ff85910f6a80bbfa971643315@haskell.org> Message-ID: <064.d8a2a1d795797bee2aeeaa83bafefdfd@haskell.org> #15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11547 #14052 | Differential Rev(s): #15202 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.8.1 => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 15:42:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 15:42:37 -0000 Subject: [GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 In-Reply-To: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> References: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> Message-ID: <066.531aa99c470a1b6aedfa6387925113f2@haskell.org> #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * owner: (none) => tdammers -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 3 21:09:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 03 Jul 2018 21:09:59 -0000 Subject: [GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin In-Reply-To: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> References: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> Message-ID: <062.899eba63e2493ccc4c0b77dde7748e48@haskell.org> #15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | typeable,knownnat Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10348 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by diatchki): Well, the evidence for `KnownNat` is just a simple integer, while the corresponding `TypeRep` is a much more heavy-weight structure, containing hashes, strings, etc. Since these are created on demand for type- literals, we would be doing additional allocation and hashing at run-time. There are many cases where `KnowNat` is useful without the additional functionality provided by `Typeable`, so I think that the current system makes sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 02:24:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 02:24:00 -0000 Subject: [GHC] #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 Message-ID: <047.0e132514379b72c39d1662f2412d5748@haskell.org> #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 -------------------------------------+------------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: m68k | Type of failure: Incorrect result | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We have observed in Debian that GHC can produce a erratically behaving version of ghc-pkg which causes issues when piping it's output to another program. Example: {{{ make_setup_recipe Running ghc --make Setup.hs -o debian/hlibrary.setup [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking debian/hlibrary.setup ... . /usr/share/haskell-devscripts/Dh_Haskell.sh && \ configure_recipe Running debian/hlibrary.setup configure --ghc -v2 --package- db=/var/lib/ghc/package.conf.d --prefix=/usr --libdir=/usr/lib/haskell- packages/ghc/lib --libexecdir=/usr/lib --builddir=dist-ghc --ghc-option =-optl-Wl\,-z\,relro --haddockdir=/usr/lib/ghc-doc/haddock/base-prelude-/ --datasubdir=base-prelude --htmldir=/usr/share/doc/libghc-base-prelude- doc/html/ --enable-library-profiling Configuring base-prelude-1.2.1... Warning: cannot determine version of /usr/bin/ghc-pkg : "" hlibrary.setup: The program 'ghc-pkg' is required but the version of /usr/bin/ghc-pkg could not be determined. }}} (Full log: https://buildd.debian.org/status/fetch.php?pkg=haskell-base- prelude&arch=m68k&ver=1.2.1-1&stamp=1530588494&raw=0) Examining the behavior of the affected ghc-pkg binary on m68k shows what's going on: {{{ root at pacman:~# uname -a Linux pacman 4.16.0-2-m68k #1 Debian 4.16.16-1 (2018-06-19) m68k GNU/Linux root at pacman:~# ghc-pkg --version GHC package manager version 8.2.2 root at pacman:~# ghc-pkg --version | cat root at pacman:~# }}} Comparing that to an x86_64 machine shows that piping to cat should actually output something: {{{ glaubitz at epyc:~$ uname -a Linux epyc 4.16.0-2-amd64 #1 SMP Debian 4.16.12-1 (2018-05-27) x86_64 GNU/Linux glaubitz at epyc:~$ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.2.2 glaubitz at epyc:~$ ghc --version | cat The Glorious Glasgow Haskell Compilation System, version 8.2.2 glaubitz at epyc:~$ }}} Further investigation shows that the problem is partially resolved when building GHC with reduced optimization: {{{ echo "SRC_HC_OPTS += -O0 -H64m" >> mk/build.mk echo "GhcStage1HcOpts = -O" >> mk/build.mk echo "GhcStage2HcOpts = -O0" >> mk/build.mk echo "GhcLibHcOpts = -O" >> mk/build.mk }}} The above issue goes away, but ghc-pkg itself still shows some strange behavior: {{{ make_setup_recipe Running ghc --make Setup.hs -o debian/hlibrary.setup [1 of 1] Compiling Main ( Setup.hs, Setup.o ) Linking debian/hlibrary.setup ... . /usr/share/haskell-devscripts/Dh_Haskell.sh && \ configure_recipe Running debian/hlibrary.setup configure --ghc -v2 --package- db=/var/lib/ghc/package.conf.d --prefix=/usr --libdir=/usr/lib/haskell- packages/ghc/lib --libexecdir=/usr/lib --builddir=dist-ghc --ghc-option =-optl-Wl\,-z\,relro --haddockdir=/usr/lib/ghc-doc/haddock/microlens- ghc-0.4.8.0/ --datasubdir=microlens-ghc --htmldir=/usr/share/doc/libghc- microlens-ghc-doc/html/ --enable-library-profiling Configuring microlens-ghc-0.4.8.0... hlibrary.setup: ghc-pkg dump failed: dieVerbatim: user error (hlibrary.setup: '/usr/bin/ghc-pkg' exited with an error: ghc-pkg: : commitBuffer: invalid argument (invalid character) ) }}} (Full log: https://buildd.debian.org/status/fetch.php?pkg=haskell- microlens-ghc&arch=m68k&ver=0.4.8.0-2&stamp=1529960552&raw=0) To reproduce the issue, GHC can be tested using QEMU which has pretty good support for the m68k target these days. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 06:12:41 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 06:12:41 -0000 Subject: [GHC] #15061: print022 testcase fails on i386 In-Reply-To: <046.070201c29a49dce5435517538bdcfad1@haskell.org> References: <046.070201c29a49dce5435517538bdcfad1@haskell.org> Message-ID: <061.9eda55e67cbb993cc7e346cdc6958a14@haskell.org> #15061: print022 testcase fails on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4906 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"15bb4e0b6c08b1f8f5511f04af14242f13833ed1/ghc" 15bb4e0b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="15bb4e0b6c08b1f8f5511f04af14242f13833ed1" Fix nptr field alignment in RtClosureInspect `extractSubTerms` (which is extracting pointer and non-pointer fields of a closure) was computing the alignment incorrectly when aligning a 64-bit value (e.g. a Double) on i386 by aligning it to 64-bits instead of to word size (32-bits). This is documented in `mkVirtHeapOffsetsWithPadding`: > Align the start offset (eg, 2-byte value should be 2-byte aligned). > But not more than to a word. Fixes #15061 Test Plan: Validated on both 32-bit and 64-bit. 32-bit fails with various unrelated stat failures, but no actual test failures. Reviewers: hvr, bgamari Reviewed By: bgamari Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #15061 Differential Revision: https://phabricator.haskell.org/D4906 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 06:13:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 06:13:15 -0000 Subject: [GHC] #15061: print022 testcase fails on i386 In-Reply-To: <046.070201c29a49dce5435517538bdcfad1@haskell.org> References: <046.070201c29a49dce5435517538bdcfad1@haskell.org> Message-ID: <061.0af895a087e8f68ca1ba208f7cc9f672@haskell.org> #15061: print022 testcase fails on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: osa1 Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4906 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 06:22:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 06:22:46 -0000 Subject: [GHC] #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 In-Reply-To: <047.0e132514379b72c39d1662f2412d5748@haskell.org> References: <047.0e132514379b72c39d1662f2412d5748@haskell.org> Message-ID: <062.99805d61c20ddb02f60a812fd47d3c57@haskell.org> #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 -------------------------------------+------------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 07:09:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 07:09:28 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.ae4df6d245968f27d3288797385fc699@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): andrewthad, why do you think `takeBytesUntilEndOfLineConsumeUnboxed` is the problematic function here? This is currently hard to debug as the reproducer is huge. A smaller reproducer would be very helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 07:11:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 07:11:01 -0000 Subject: [GHC] #14231: Core lint error "in result of Static argument" In-Reply-To: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> References: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> Message-ID: <064.3c0d272464964ee911cbd11394f14cd6@haskell.org> #14231: Core lint error "in result of Static argument" -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: > Whilst investigating #14211 I encountered a core lint error. > > {{{ > {-# LANGUAGE CPP #-} > {-# LANGUAGE RankNTypes #-} > > module Async where > > data AsyncT m a = > AsyncT { > runAsyncT :: forall r. > Maybe Int -- state > -> m r -- stop > -> (a -> Maybe Int -> Maybe (AsyncT m a) -> m r) -- yield > -> m r > } > > ------------------------------------------------------------------------------ > -- Monad > ------------------------------------------------------------------------------ > > {-# INLINE bindWith #-} > bindWith > :: (forall c. AsyncT m c -> AsyncT m c -> AsyncT m c) > -> AsyncT m a > -> (a -> AsyncT m b) > -> AsyncT m b > bindWith k (AsyncT m) f = AsyncT $ \_ stp yld -> > m Nothing stp (\a _ m -> (\x -> (runAsyncT x) Nothing stp yld) $ maybe (f > a) (\r -> f a `k` (bindWith k r f)) m ) > }}} > > Compile with `ghc -O2 -fno-worker-wrapper -fstatic-argument- > transformation -dcore-lint`. > > Error: > {{{ > *** Core Lint errors : in result of Static argument *** > : warning: > In the expression: bindWith @ m_aV5 @ a_aV6 @ b_aV7 k_aSU x_aX3 f_aSW > Mismatch in type between binder and occurrence > Var: bindWith_rpi > Binder type: forall (m1 :: * -> *) a1 b1 . > > (forall c . AsyncT m_aV5 c -> AsyncT m_aV5 c -> AsyncT m_aV5 c) > -> AsyncT m_aV5 a_aV6 -> (a_aV6 -> AsyncT m_aV5 b_aV7) -> AsyncT > m_aV5 b_aV7 > Occurrence type: forall (m :: * -> *) a b . > > (forall c . AsyncT m c -> AsyncT m c -> AsyncT m c) > -> AsyncT m a -> (a -> AsyncT m b) -> AsyncT m b > Before subst: forall (m :: * -> *) a b . > > (forall c . AsyncT m c -> AsyncT m c -> AsyncT m c) > -> AsyncT m a -> (a -> AsyncT m b) -> AsyncT m b > *** Offending Program *** > }}} New description: Whilst investigating #14211 I encountered a core lint error. {{{ {-# LANGUAGE CPP #-} {-# LANGUAGE RankNTypes #-} module Async where data AsyncT m a = AsyncT { runAsyncT :: forall r. Maybe Int -- state -> m r -- stop -> (a -> Maybe Int -> Maybe (AsyncT m a) -> m r) -- yield -> m r } ------------------------------------------------------------------------------ -- Monad ------------------------------------------------------------------------------ {-# INLINE bindWith #-} bindWith :: (forall c. AsyncT m c -> AsyncT m c -> AsyncT m c) -> AsyncT m a -> (a -> AsyncT m b) -> AsyncT m b bindWith k (AsyncT m) f = AsyncT $ \_ stp yld -> m Nothing stp (\a _ m -> (\x -> (runAsyncT x) Nothing stp yld) $ maybe (f a) (\r -> f a `k` (bindWith k r f)) m ) }}} Compile with `ghc -O2 -fno-worker-wrapper -fstatic-argument-transformation -dcore-lint`. Error: {{{ *** Core Lint errors : in result of Static argument *** : warning: In the expression: bindWith @ m_aV5 @ a_aV6 @ b_aV7 k_aSU x_aX3 f_aSW Mismatch in type between binder and occurrence Var: bindWith_rpi Binder type: forall (m1 :: * -> *) a1 b1 . (forall c . AsyncT m_aV5 c -> AsyncT m_aV5 c -> AsyncT m_aV5 c) -> AsyncT m_aV5 a_aV6 -> (a_aV6 -> AsyncT m_aV5 b_aV7) -> AsyncT m_aV5 b_aV7 Occurrence type: forall (m :: * -> *) a b . (forall c . AsyncT m c -> AsyncT m c -> AsyncT m c) -> AsyncT m a -> (a -> AsyncT m b) -> AsyncT m b Before subst: forall (m :: * -> *) a b . (forall c . AsyncT m c -> AsyncT m c -> AsyncT m c) -> AsyncT m a -> (a -> AsyncT m b) -> AsyncT m b *** Offending Program *** }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 07:22:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 07:22:08 -0000 Subject: [GHC] #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) In-Reply-To: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> References: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> Message-ID: <065.65fc9bd49ebe5935b2386354c3f94cb2@haskell.org> #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 07:34:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 07:34:18 -0000 Subject: [GHC] #14231: Core lint error "in result of Static argument" In-Reply-To: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> References: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> Message-ID: <064.f3ef12b2be2bdd306694b2ed7e862e3e@haskell.org> #14231: Core lint error "in result of Static argument" -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Looking at this again; I realized that we don't need any flags to trigger some lint warnings in the original program (the `Async` module): {{{ $ ghc-stage2 Async.hs -dcore-lint -fforce-recomp -O0 [1 of 1] Compiling Async ( Async.hs, Async.o ) *** Core Lint warnings : in result of Simplifier *** Async.hs:25:1: warning: [RHS of bindWith :: forall (m :: * -> *) a b. (forall c. AsyncT m c -> AsyncT m c -> AsyncT m c) -> AsyncT m a -> (a -> AsyncT m b) -> AsyncT m b] INLINE binder is (non-rule) loop breaker: bindWith *** Core Lint warnings : in result of Simplifier *** Async.hs:25:1: warning: [RHS of bindWith :: forall (m :: * -> *) a b. (forall c. AsyncT m c -> AsyncT m c -> AsyncT m c) -> AsyncT m a -> (a -> AsyncT m b) -> AsyncT m b] INLINE binder is (non-rule) loop breaker: bindWith }}} This warning disappears if I remove the `INLINE` pragma. Not sure if this is a bug (it's a warning, not an error) but maybe useful to know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 07:34:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 07:34:42 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.ed81771772bf1614f939b99254248229@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * Attachment "nofib-gn-gnl.analyze.log" added. nofib analyse output: effect of NSH on libraries only vs. NSH on all of GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 07:35:19 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 07:35:19 -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.2dc6997a56f81db0a2c221ecbaf91338@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * Attachment "nofib-ns-nn.analyze.log" added. nofib analyse output: nofib compiled with NSH vs. normally, on a vanilla GHC build -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 07:35:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 07:35:54 -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.70e75f0e87170e627c919b14e16eee8d@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * Attachment "nofib-ns-nn-gnl.analyze.log" added. nofib analyse output: nofib compiled with NSH vs. normally, on a GHC build with NSH libraries -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 07:38:04 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 07:38:04 -0000 Subject: [GHC] #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints In-Reply-To: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> References: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> Message-ID: <059.6099d1e1ed1913335714a9fc98bb7c10@haskell.org> #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 07:51:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 07:51:15 -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.3d3aec8a7993f02ee4aa2e22142de5a1@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): New nofib results. - `nofib-gn-gnl`: GHC and boot libraries compiled with `-fno-state-hack` compiling nofib normally, vs. GHC compiled normally and boot libraries compiled with `-fno-state-hack` compiling nofib normally. This measures the effect of compiling GHC itself with `-fno-state-hack`. - `nofib-ns-nn`: GHC compiled normally compiling nofib normally vs. GHC compiled normally compiling nofib with `-fno-state-hack`. This measures the effect of the state hack on nofib when using a vanilla compiler. - `nofib-ns-nn-gnl`: GHC compiled normally with boot libraries compiled with `-fno-state-hack` compiling nofib normally vs. GHC compiled normally with boot libraries compiled with `-fno-state-hack` compiling nofib with `-fno-state-hack`. This measures the effect of the state hack on nofib when using a vanilla compiler with state-hack-free boot libraries. Key observations: - Differences are now much closer to what we expect, specifically, whether we compile GHC and / or boot libraries with or without the state hack does not significantly change nofib performance (< 1%). - Compiling GHC itself and boot libraries without the state hack makes nofib compilation slightly slower than compiling only boot libraries without the state hack (~4%). - Compiling nofib without the state hack makes compilation significantly faster (~25%) than compiling nofib with the state hack, regardless of how GHC itself and the boot libraries were compiled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 08:53:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 08:53:52 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM4NjExOiBub2ZpYuKAmXMgY2FjaGVwcm9m4oCZ?= =?utf-8?q?s_allocations_nondeterminisitic?= In-Reply-To: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> References: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> Message-ID: <061.c2049e867ef315fbda99638b2b2e863a@haskell.org> #8611: nofib’s cacheprof’s allocations nondeterminisitic -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 8.5 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) * version: 7.6.3 => 8.5 Comment: This has been tainting nofib results since years, should we maybe prioritize and fix this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 09:05:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 09:05:13 -0000 Subject: [GHC] #15219: Implement UnliftedNewtypes proposal In-Reply-To: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> References: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> Message-ID: <064.ac89d8c60c852944a15d33946ce9dcdf@haskell.org> #15219: Implement UnliftedNewtypes proposal -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | UnliftedNewtypes, GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by LeanderK): Question: Would it be possible to introduce UnliftedNewtypes in one of the following releases (something like 8.6.3?)? I have a use-case where levity-polymorphism would help, but it crucially relies on having levity polymorphic newtypes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 09:42:31 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 09:42:31 -0000 Subject: [GHC] #15219: Implement UnliftedNewtypes proposal In-Reply-To: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> References: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> Message-ID: <064.7636b3af7a7810a00624ee730ae0d10d@haskell.org> #15219: Implement UnliftedNewtypes proposal -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | UnliftedNewtypes, GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): No, new releases are for bug fixes. 8.8 will not be a very long time away. I don't even think the feature is implemented yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 10:58:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 10:58:22 -0000 Subject: [GHC] #15219: Implement UnliftedNewtypes proposal In-Reply-To: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> References: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> Message-ID: <064.ef3740f11af3b99af53b54d5a7f095fa@haskell.org> #15219: Implement UnliftedNewtypes proposal -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | UnliftedNewtypes, GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): We will definitely need to wait until 8.8. I've made some attempts at it on https://phabricator.haskell.org/D4777, but it still doesn't work right. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 11:01:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 11:01:57 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.cd0d6dfafd5b483fa360ff5ab503723d@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): I don't have any suspicions about why that specific function is the only one that causes problems. I can put together a smaller reproducer though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 11:30:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 11:30:05 -0000 Subject: [GHC] #14231: Core lint error "in result of Static argument" In-Reply-To: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> References: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> Message-ID: <064.33af9adeec14afe3d3a580c789ce6a01@haskell.org> #14231: Core lint error "in result of Static argument" -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): This module has a few problems: - The nofib results in the module documentation are not valid anymore. I just run nofib with GHC 8.4.2 and this pass made 0 difference in allocations. - The running example used in documentation doesn't really work anymore. For some reason this pass doesn't transform the `map` function. - The pass reuses ids in binder position (i.e. binds same ids with same uniques etc. multiple times), without cloning them (probably to avoid renaming). I think this may break invariants in other places in the compiler although I'm not sure. Now, for this specific ticket, here's the function before SAT: {{{ bindWith :: forall a. (a -> a) -> a -> a bindWith = \ (@ a_a17W) (k_atr :: a_a17W -> a_a17W) (f_ats :: a_a17W) -> k_atr (bindWith @ a_a17W k_atr f_ats) }}} After SAT: {{{ bindWith :: forall a. (a -> a) -> a -> a bindWith = \ (@ a_a17W) (k_atr :: a_a17W -> a_a17W) (f_ats :: a_a17W) -> letrec { sat_worker_s198 :: a_a17W [LclId] sat_worker_s198 = let { bindWith_r1 :: forall a. (a_a17W -> a_a17W) -> a_a17W -> a_a17W [LclId] bindWith_r1 = \ (@ a_s195) (k_s196 :: a_a17W -> a_a17W) (f_s197 :: a_a17W) -> sat_worker_s198 } in k_atr (bindWith @ a_a17W k_atr f_ats); } in sat_worker_s198, }}} (The printer doesn't make it clear but `bindWith_r1` and `bindWith` have the same unique) The problem is if you ignore uniques all those `a` type variables are the same, but from the type checker's perspective they're not, which can be seen in the linter error. With `-dsuppress-uniques`: {{{ Mismatch in type between binder and occurrence Var: bindWith Binder type: forall a. (a -> a) -> a -> a Occurrence type: forall a. (a -> a) -> a -> a Before subst: forall a. (a -> a) -> a -> a }}} With uniques: {{{ Mismatch in type between binder and occurrence Var: bindWith_r1 Binder type: forall a. (a_a17W -> a_a17W) -> a_a17W -> a_a17W Occurrence type: forall a. (a -> a) -> a -> a Before subst: forall a. (a -> a) -> a -> a }}} SAT never actually builds types, it builds terms and then calls `exprType`. The incorrect type `forall a. (a_a17W -> a_a17W) -> a_a17W -> a_a17W` is given to this term by `exprType`: {{{ \ (@ a_s195) (k_s196 :: a_a17W -> a_a17W) (f_s197 :: a_a17W) -> sat_worker_s198 }}} Arguments of this lambda is generated by this (probably broken) clone function: {{{ clone (bndr, NotStatic) = return bndr clone (bndr, _ ) = do { uniq <- newUnique ; return (setVarUnique bndr uniq) } }}} Where the second element of the pair is defined like this: {{{ data App = VarApp Id | TypeApp Type | CoApp Coercion data Staticness = Static App | NotStatic }}} So this clones types, coercion, and term binders just by generating a new unique for them. I'm not sure if this is right way to clone binders. Then, as I said above, it reuses some ids in binder position without cloning them. I suspect one or both of them are causing this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 11:43:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 11:43:10 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.5d6a585b94cd257ec4491efba634b911@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nfrisby Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 | Differential Rev(s): Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): It took me quite some time, but [https://github.com/sgraf812/ghc/tree/c1f16ac245ca8f8c8452a5b3c1f116237adcb577 this commit] passes `./validate` (modulo 4 compiler perf tests). Fixing the testsuite was rather simple, but investigating various performance regressions to see which knobs we could turn is really time consuming, so I figured I better post now than never. I updated the wiki page with a summary of changes I made. For completeness: - A hopefully faithful rebase, removing previous LNE (= join point) detection logic - Activate all LLF flags (see the above llf-nr10-r6 configuration) by default - Actually use the `-fllf-nonrec-lam-limit` setting - Don't stabilise Unfoldings mentioning `makeStatic` - Respect RULEs and Unfoldings in the identifier we abstract over (previously, when SpecConstr added a RULE mentioning an otherwise absent specialised join point, we would ignore it, which is not in line with how CoreFVs works) - Stabilise Unfoldings only when we lifted something out of a function (Not doing so led to a huge regression in veritas' Edlib.lhs) I'll attach nofib results in a following post. Here's the summary: {{{ Program Allocs Allocs Instrs Instrs no-llf llf no-llf llf -------------------------------------------------------------------------------- Min -20.3% -20.3% -7.8% -16.5% Max +2.0% +1.6% +18.4% +18.4% Geometric Mean -0.4% -1.0% +0.3% -0.0% }}} `llf` is a plain benchmark run, whereas `no-llf` means libraries compiled with `-fllf`, but benchmarks compiled with `-fno-llf`. This is a useful baseline, as it allows to detect test cases where the regression actually happens in the test case rather than somewhere in the boot libraries. Hardly surprising, allocations go down. More surprisingly, not in a consistent fashion. The most illustrating test case is `real/pic`: {{{ no-llf llf pic -0.0% +1.0% +0.0% -3.4% }}} The lifting of some functions results in functions of rather big result arity (6 and 7), which no longer can be fast called. Appearently, there's no `stg_ap_pppnn` variant matching the call pattern. Also, counted instructions went up in some cases, so that there's no real win to be had. If I completely refrain from lifting non-recursive join points, things look better wrt. to counted instructions: {{{ Program Allocs Allocs Instrs Instrs no-llf llf no-llf llf -------------------------------------------------------------------------------- Min -20.3% -20.3% -3.4% -17.1% Max +2.0% +1.6% +6.4% +6.4% Geometric Mean -0.3% -1.0% +0.1% -0.4% }}} But I recently questioned using cachegrind results (such as the very relevant counted memory reads/writes) as a reliable metric (#15333). There are some open things that should be measured: - Is it worthwhile at all to lift join points? (Related: don't we rather want 'custom calling conventions' that inherits register/closure configurations to top-level bindings?) - Isn't a reduction in allocations a lie when all we did is spill more on to the stack? Imagine we lift a (non-tail-recursive) function to top-level that would have arity > 5. Arguments would have to be passed on the stack, for each recursive call. I'd expect that to be worse than the status quo. So maybe don't just count the number of free ids we abstract over, but rather bound the resulting arity? Finally, the whole transformation feels more like it belongs in the STG layer: We very brittly anticipate CorePrep and have to pull in really low- level stuff into the analysis, all while having to preserve unfoldings when we change anything. Seems like a very local optimization (except for enabling intra-module inlining opportunities) that doesn't enable many other core2core optimizations (nor should it, that's why we lift late). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 11:48:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 11:48:47 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.db4a57e3e6abe613bb9ab1f7efe127db@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nfrisby Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 | Differential Rev(s): Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): [http://pasted.co/f407cea9 plain base, no-llf, llf] [http://pasted.co/62927f9b same without lifting non-rec join points] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 11:50:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 11:50:33 -0000 Subject: [GHC] #15339: Add function equality instance for finite functions to base Message-ID: <045.f5bbef36b20a797130d19467b6f78cbc@haskell.org> #15339: Add function equality instance for finite functions to base -------------------------------------+------------------------------------- Reporter: madgen | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: | Version: 8.4.3 libraries/base | Keywords: base, | Operating System: Unknown/Multiple equality, function | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If the input type is bounded and enumerable and the result type can be compared for equality, functions can be checked for equality. Basically this instance: {{{#!hs instance (Bounded a, Enum a, Eq b) => Eq (a -> b) where f == g = all (\x -> f x == g x) [ minBound..maxBound ] }}} I often work with functions with finite domains and find [(a,b)] awkward. I thought this is generic enough that it might belong to base. I'd also submit a patch, but I couldn't quite figure out where it should live. GHC.Base doesn't have Enum and Bounded; Enum is not where -> or Eq are declared; Eq is not declared anywhere; and Data.Function is only for combinators. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 12:09:41 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 12:09:41 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.5a6083b93af455546c63e05cb3c5a4d5@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): For a smaller reproducer, I've reused https://github.com/andrewthad /corrupted-memory-example. On master, I've basically got a copy of `packed` with everything stripped out that isn't needed to demonstrate this particular problem. I'm going to try to golf it down a little more today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 12:39:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 12:39:14 -0000 Subject: [GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker In-Reply-To: <049.2656489ff85910f6a80bbfa971643315@haskell.org> References: <049.2656489ff85910f6a80bbfa971643315@haskell.org> Message-ID: <064.556341ec676ed7b3841fa67c48a09be1@haskell.org> #15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11547 #14052 | Differential Rev(s): Phab:D4909 #15202 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D4909 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 12:40:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 12:40:27 -0000 Subject: [GHC] #15321: Typed holes in Template Haskell splices produce bewildering error messages In-Reply-To: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> References: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> Message-ID: <065.46b7a5a6b0d70edc00d7896b89bc7f99@haskell.org> #15321: Typed holes in Template Haskell splices produce bewildering error messages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4909 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D4909 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 12:46:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 12:46:34 -0000 Subject: [GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker In-Reply-To: <049.2656489ff85910f6a80bbfa971643315@haskell.org> References: <049.2656489ff85910f6a80bbfa971643315@haskell.org> Message-ID: <064.f002e648bd0926b192dbf24fd8e5c83b@haskell.org> #15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11547 #14052 | Differential Rev(s): Phab:D4909 #15202 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => new Comment: Reverting this back to "new". It seems to me that the patch doesn't actually fix this problem, but works around it. Please make the status "patch" again if I'm wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 12:48:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 12:48:14 -0000 Subject: [GHC] #15321: Typed holes in Template Haskell splices produce bewildering error messages In-Reply-To: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> References: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> Message-ID: <065.0dfaa8de61ba118352598ed18fcc9867@haskell.org> #15321: Typed holes in Template Haskell splices produce bewildering error messages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4909 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"39de4e3d33dd9879398062620ad00b1e3b8481ce/ghc" 39de4e3d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="39de4e3d33dd9879398062620ad00b1e3b8481ce" Fix errors caused by invalid candidates leaking from hole fits This is a one line fix (and a note) that fixes four tickets, #15007, #15321 and #15202, #15314 The issue was that errors caused by illegal candidates (according to GHC stage or being internal names) were leaking to the user, causing bewildering error messages. If a candidate causes the type checker to error, it is not a valid hole fit, and should be discarded. As mentioned in #15321, this can cause a pattern of omissions, which might be hard to discover. A better approach would be to gather the error messages, and ask users to report them as GHC bugs. This will be implemented in a subsequent change. Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #15007, #15321, #15202, #15314 Differential Revision: https://phabricator.haskell.org/D4909 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 12:48:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 12:48:15 -0000 Subject: [GHC] #15314: Internal error during typechecking of a hole in GHCi when there's shadowed identifiers In-Reply-To: <044.a38cb36cce530ca78b0769c47739ba35@haskell.org> References: <044.a38cb36cce530ca78b0769c47739ba35@haskell.org> Message-ID: <059.6d7ee3ee1e0342eff0196b11e59b671a@haskell.org> #15314: Internal error during typechecking of a hole in GHCi when there's shadowed identifiers -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #15007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"39de4e3d33dd9879398062620ad00b1e3b8481ce/ghc" 39de4e3d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="39de4e3d33dd9879398062620ad00b1e3b8481ce" Fix errors caused by invalid candidates leaking from hole fits This is a one line fix (and a note) that fixes four tickets, #15007, #15321 and #15202, #15314 The issue was that errors caused by illegal candidates (according to GHC stage or being internal names) were leaking to the user, causing bewildering error messages. If a candidate causes the type checker to error, it is not a valid hole fit, and should be discarded. As mentioned in #15321, this can cause a pattern of omissions, which might be hard to discover. A better approach would be to gather the error messages, and ask users to report them as GHC bugs. This will be implemented in a subsequent change. Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #15007, #15321, #15202, #15314 Differential Revision: https://phabricator.haskell.org/D4909 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 12:48:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 12:48:15 -0000 Subject: [GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker In-Reply-To: <049.2656489ff85910f6a80bbfa971643315@haskell.org> References: <049.2656489ff85910f6a80bbfa971643315@haskell.org> Message-ID: <064.133904cdf5cbd8bf1085ad6da9ea3992@haskell.org> #15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11547 #14052 | Differential Rev(s): Phab:D4909 #15202 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"39de4e3d33dd9879398062620ad00b1e3b8481ce/ghc" 39de4e3d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="39de4e3d33dd9879398062620ad00b1e3b8481ce" Fix errors caused by invalid candidates leaking from hole fits This is a one line fix (and a note) that fixes four tickets, #15007, #15321 and #15202, #15314 The issue was that errors caused by illegal candidates (according to GHC stage or being internal names) were leaking to the user, causing bewildering error messages. If a candidate causes the type checker to error, it is not a valid hole fit, and should be discarded. As mentioned in #15321, this can cause a pattern of omissions, which might be hard to discover. A better approach would be to gather the error messages, and ask users to report them as GHC bugs. This will be implemented in a subsequent change. Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #15007, #15321, #15202, #15314 Differential Revision: https://phabricator.haskell.org/D4909 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 12:48:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 12:48:15 -0000 Subject: [GHC] #15202: Internal error showing typed hole in GHCi In-Reply-To: <045.7429a5cde007875512b47f53bc5766b7@haskell.org> References: <045.7429a5cde007875512b47f53bc5766b7@haskell.org> Message-ID: <060.b284c19854cf7e4289d6927088cebdb1@haskell.org> #15202: Internal error showing typed hole in GHCi -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: duplicate | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"39de4e3d33dd9879398062620ad00b1e3b8481ce/ghc" 39de4e3d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="39de4e3d33dd9879398062620ad00b1e3b8481ce" Fix errors caused by invalid candidates leaking from hole fits This is a one line fix (and a note) that fixes four tickets, #15007, #15321 and #15202, #15314 The issue was that errors caused by illegal candidates (according to GHC stage or being internal names) were leaking to the user, causing bewildering error messages. If a candidate causes the type checker to error, it is not a valid hole fit, and should be discarded. As mentioned in #15321, this can cause a pattern of omissions, which might be hard to discover. A better approach would be to gather the error messages, and ask users to report them as GHC bugs. This will be implemented in a subsequent change. Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #15007, #15321, #15202, #15314 Differential Revision: https://phabricator.haskell.org/D4909 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 12:48:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 12:48:35 -0000 Subject: [GHC] #15321: Typed holes in Template Haskell splices produce bewildering error messages In-Reply-To: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> References: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> Message-ID: <065.1aaf618e892c450ce90db039b822f035@haskell.org> #15321: Typed holes in Template Haskell splices produce bewildering error messages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4909 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 13:16:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 13:16:08 -0000 Subject: [GHC] #14231: Core lint error "in result of Static argument" In-Reply-To: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> References: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> Message-ID: <064.145559e1ee6f1b4ef8ca61265d8035f4@haskell.org> #14231: Core lint error "in result of Static argument" -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): Replying to [comment:7 osa1]: > Looking at this again; I realized that we don't need any flags to trigger some lint warnings in the original program (the `Async` module): This is a different issue; GHC won't inline a self-recursive definition (e.g. `x :: a; x = x`) even if it's marked as INLINE. We could have better messaging about this, I believe this is ticket #9418. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 13:30:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 13:30:28 -0000 Subject: [GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker In-Reply-To: <049.2656489ff85910f6a80bbfa971643315@haskell.org> References: <049.2656489ff85910f6a80bbfa971643315@haskell.org> Message-ID: <064.5035a8941500b535bd94ce61f74b92b1@haskell.org> #15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11547 #14052 | Differential Rev(s): Phab:D4909 #15202 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I don't see a regression test -- please add one? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 13:30:58 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 13:30:58 -0000 Subject: [GHC] #15321: Typed holes in Template Haskell splices produce bewildering error messages In-Reply-To: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> References: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> Message-ID: <065.7c527d4c3a6e21914562493afd8cfbe3@haskell.org> #15321: Typed holes in Template Haskell splices produce bewildering error messages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4909 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks -- can we add a regression test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 13:31:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 13:31:32 -0000 Subject: [GHC] #15314: Internal error during typechecking of a hole in GHCi when there's shadowed identifiers In-Reply-To: <044.a38cb36cce530ca78b0769c47739ba35@haskell.org> References: <044.a38cb36cce530ca78b0769c47739ba35@haskell.org> Message-ID: <059.2ca6af1d3727cd30e66b68c6fdab83d3@haskell.org> #15314: Internal error during typechecking of a hole in GHCi when there's shadowed identifiers -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #15007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks -- can we add a regression test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 13:31:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 13:31:56 -0000 Subject: [GHC] #15202: Internal error showing typed hole in GHCi In-Reply-To: <045.7429a5cde007875512b47f53bc5766b7@haskell.org> References: <045.7429a5cde007875512b47f53bc5766b7@haskell.org> Message-ID: <060.b42ec396efc4e6c56abedc491b422084@haskell.org> #15202: Internal error showing typed hole in GHCi -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: duplicate | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks -- can we add a regression test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 13:43:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 13:43:33 -0000 Subject: [GHC] #15321: Typed holes in Template Haskell splices produce bewildering error messages In-Reply-To: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> References: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> Message-ID: <065.23100e397465091bcbd053bc223d6f3b@haskell.org> #15321: Typed holes in Template Haskell splices produce bewildering error messages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4909 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"e835fdb18cca66820728afce9c924a1c71f17fee/ghc" e835fdb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e835fdb18cca66820728afce9c924a1c71f17fee" Add regression test for #15321 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 13:47:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 13:47:28 -0000 Subject: [GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker In-Reply-To: <049.2656489ff85910f6a80bbfa971643315@haskell.org> References: <049.2656489ff85910f6a80bbfa971643315@haskell.org> Message-ID: <064.32aff79ae6596702a70b23d81c5d907d@haskell.org> #15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11547 #14052 | Differential Rev(s): Phab:D4909 #15202 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): This ticket isn't fixed by Phab:D4909. With a debug-enabled stage2 compiler, for the script in description, we will get a panic: {{{ Prelude> 1 1 (0.02 secs, 65,728 bytes) Prelude> 1 1 (0.00 secs, 64,352 bytes) Prelude> _ ghc-stage2.exe: panic! (the 'impossible' happened) (GHC version 8.7.20180629 for x86_64-unknown-mingw32): ASSERT failed! Cur lvl = 1 Imp lvl = 1 Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler\utils\Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler\utils\Outputable.hs:1223:5 in ghc:Outputable assertPprPanic, called at compiler\\typecheck\\TcSimplify.hs:1548:120 in ghc:TcSimplify CallStack (from -prof): HscMain.ioMsgMaybe (compiler\main\HscMain.hs:(252,1)-(257,128)) HscMain.hscParsedStmt (compiler\main\HscMain.hs:(1548,1)-(1564,36)) HscMain.hscStmtWithLocation (compiler\main\HscMain.hs:(1533,1)-(1541,50)) GHC.withCleanupSession (compiler\main\GHC.hs:(469,1)-(477,27)) GHC.runGhc (compiler\main\GHC.hs:(444,1)-(449,26)) GHC.defaultErrorHandler (compiler\main\GHC.hs:(384,1)-(416,7)) }}} Besides, this ticket is intend to solve the problem described in #11547, the ` GHC internal error` (for script reported by #11547) still occurs after Phab:D4909. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 13:49:58 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 13:49:58 -0000 Subject: [GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker In-Reply-To: <049.2656489ff85910f6a80bbfa971643315@haskell.org> References: <049.2656489ff85910f6a80bbfa971643315@haskell.org> Message-ID: <064.f9bdfd4fd8b52e056f0dbfb09261221c@haskell.org> #15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11547 #14052 | Differential Rev(s): Phab:D4909 #15202 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): The program in #15314 now triggers the same assertion failure as comment:14 after Phab:D4909. {{{ Prelude> let x = () Prelude> let x = () Prelude> :t _ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 13:50:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 13:50:11 -0000 Subject: [GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker In-Reply-To: <049.2656489ff85910f6a80bbfa971643315@haskell.org> References: <049.2656489ff85910f6a80bbfa971643315@haskell.org> Message-ID: <064.0dca144b624e639605ba97e5acdf43ae@haskell.org> #15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11547 #14052 | Differential Rev(s): Phab:D4909 #15202 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"f6ac0833b733afa628955cdcf6e31171a53e2222/ghc" f6ac0833/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f6ac0833b733afa628955cdcf6e31171a53e2222" Add regression test for #15007 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 13:53:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 13:53:03 -0000 Subject: [GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker In-Reply-To: <049.2656489ff85910f6a80bbfa971643315@haskell.org> References: <049.2656489ff85910f6a80bbfa971643315@haskell.org> Message-ID: <064.60b8adb67b054f175b433dabc89f1b22@haskell.org> #15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11547 #14052 | Differential Rev(s): Phab:D4909 #15202 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): sighingnow, are you sure you rebuilt it correctly? I'm also using a debug- enabled compiler and here are the outputs I'm getting: {{{ ~ $ ghc-stage2 --interactive GHCi, version 8.7.20180704: http://www.haskell.org/ghc/ :? for help Prelude> 1 1 Prelude> 1 1 Prelude> _ :3:1: error: • Found hole: _ :: t Where: ‘t’ is a rigid type variable bound by the inferred type of it :: t at :3:1 • In the expression: _ In an equation for ‘it’: it = _ • Relevant bindings include it :: t (bound at :3:1) Prelude> }}} {{{ ~ $ ghc-stage2 --interactive GHCi, version 8.7.20180704: http://www.haskell.org/ghc/ :? for help Prelude> let x = () Prelude> let x = () Prelude> :t _ :1:1: error: • Found hole: _ :: t Where: ‘t’ is a rigid type variable bound by the inferred type of it :: t at :1:1 • In the expression: _ Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 14:28:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 14:28:12 -0000 Subject: [GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker In-Reply-To: <049.2656489ff85910f6a80bbfa971643315@haskell.org> References: <049.2656489ff85910f6a80bbfa971643315@haskell.org> Message-ID: <064.d55994e28296f103284a4b96ca3a262c@haskell.org> #15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11547 #14052 | Differential Rev(s): Phab:D4909 #15202 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): I have rebuilt the stage2 compiler after manually delete all `.o` and `.hi` files in compiler/stage2/build and still get the same panic. I will try a fresh build later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 14:54:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 14:54:37 -0000 Subject: [GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker In-Reply-To: <049.2656489ff85910f6a80bbfa971643315@haskell.org> References: <049.2656489ff85910f6a80bbfa971643315@haskell.org> Message-ID: <064.7552f0f6d6c4e92ec1656d5a336a4c9e@haskell.org> #15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11547 #14052 | Differential Rev(s): Phab:D4909 #15202 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I just validated with the regression tests so it should be fine after a `make clean`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 14:59:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 14:59:40 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM4NjExOiBub2ZpYuKAmXMgY2FjaGVwcm9m4oCZ?= =?utf-8?q?s_allocations_nondeterminisitic?= In-Reply-To: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> References: <046.9452bfe64045e297fcab99166dcd73b9@haskell.org> Message-ID: <061.8e0c1d5798cd69c59f46b7b83aa4e675@haskell.org> #8611: nofib’s cacheprof’s allocations nondeterminisitic -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 8.5 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): It just needs someone determined enough to find the cause… -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 15:18:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 15:18:38 -0000 Subject: [GHC] #8263: allow duplicate deriving / standalone deriving In-Reply-To: <045.bba713620ff6c6ed638444c7e9f46806@haskell.org> References: <045.bba713620ff6c6ed638444c7e9f46806@haskell.org> Message-ID: <060.2705151c5882c5cc4928daf9447bc246@haskell.org> #8263: allow duplicate deriving / standalone deriving -------------------------------------+------------------------------------- Reporter: aavogt | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: wontfix | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => closed * resolution: => wontfix Comment: In the specific case of Typeable, since GHC 8.2 every data type is an instance of Typeable and we're ignoring "deriving instance Typeable" altogether. In general case, there's the problem of deriving strategies from [comment:3 comment:3]. We could, in principle, allow the declaration "deriving S instance T" if T was derived using the same strategy S elsewhere. However, this only solves the issue if the T was derived; if there's an "instance" declaration, I don't see any nice way to do it. So this feature would be rather limited in power; we don't have examples other than Typeable, and in the meantime #8100 was fixed. I'm closing the ticket; please reopen if you still need this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 15:23:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 15:23:32 -0000 Subject: [GHC] #15340: Investigate using Ward on RTS Message-ID: <046.17517c0d14ed055045d9c0a9bfaad364@haskell.org> #15340: Investigate using Ward on RTS -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While debugging a locking issue a few weeks ago I found myself pining for static analysis tooling. Today I briefly looked at the options and one stood out: [[https://github.com/evincarofautumn/Ward|Ward]]. It sits in a very nice point in the design space, allowing the user to specify the universe of privileges and annotate functions using standard C attributes. I think this would be a very helpful tool for GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 16:21:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 16:21:45 -0000 Subject: [GHC] #15341: :info prints kinds in closed type family equations without enabling -fprint-explicit-kinds Message-ID: <050.0a6e915f611ee596161321a86f26e2cc@haskell.org> #15341: :info prints kinds in closed type family equations without enabling -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Load this file into GHCi: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Bug where type family Foo (a :: k) :: k where Foo a = a }}} And run `:info` on `Foo`: {{{ $ /opt/ghc/8.4.3/bin/ghci Bug.hs GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, one module loaded. λ> :i Foo type family Foo (a :: k) :: k where Foo k a = a -- Defined at Bug.hs:5:1 }}} Note that when printing the equation for `Foo`, the kind `k` is treated as though it were the first visible argument to `Foo`, even though `-fprint- explicit-kinds` is not enabled. This is because `ppr_tc_args` in `IfaceType` does not take `-fprint-explicit-kinds` into account. Patch incoming (pending a `./validate`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 16:26:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 16:26:03 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.cb9cb315d464e01be92b713c2c706855@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ningning): - Overall changes so far: 1. Removed {{{Refl r ty}}} and {{{CoherenceCo}}} 2. Introduced {{{Refl ty}}} and {{{GRefl r ty MCoercion}}} - {{{Refl ty :: ty ~n ty}}}, note that {{{Refl ty}}} is always nominal. - {{{GRefl r ty MRefl :: ty ~r ty}}}. If {{{r == Nominal}}}, {{{use Refl}}}. - {{{GRefl r ty (MCo co) :: ty ~r ty |>co}}}. 3. Replaced original {{{Refl Nominal ty}}} with {{{Refl ty}}}. 4. Given {{{g1 :: s ~r t}}}, to construct {{{s |> g2 ~r t}}} we used {{{CoherenceCo g1 g2}}}. It is now replaced with {{{Sym (GRefl r s g2) ; g1}}}. Similar for {{{s ~ t |> g3}}}. 5. It turns out that the explicit patten match in {{{homogenise_result}}} in TcFlatten triggers some optimization of GHC and improves the performance. However it is not useful in master branch. 6. Added a small regression for T9872d (the added number is the allocation of current master on T9872d). 7. Added note about {{{flatten_exact_fam_app_fully}}} performance in TcFlatten. - Performance summary 1. This patch intends to improve the overall performance about coercions. 2. It does perform better in all cases under perf/compiler, except T9872b (0.6%), T9872d(3.7%), and T14683(0.02%). 3. It failed T9872d, thus we added a small regression. 4. It seems to perform better to compile large packages, e.g. Cabal. - TODO: Further analysis of the performance: a step-by-step replay of the refactor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 16:45:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 16:45:42 -0000 Subject: [GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin In-Reply-To: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> References: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> Message-ID: <062.515f1dee49db2c7128f26bcb56b38a72@haskell.org> #15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | typeable,knownnat Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10348 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Well, the evidence for KnownNat is just a simple integer, while the corresponding TypeRep is a much more heavy-weight structure That's a fair point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 16:47:31 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 16:47:31 -0000 Subject: [GHC] #15341: :info prints kinds in closed type family equations without enabling -fprint-explicit-kinds In-Reply-To: <050.0a6e915f611ee596161321a86f26e2cc@haskell.org> References: <050.0a6e915f611ee596161321a86f26e2cc@haskell.org> Message-ID: <065.92ecc8cb3ef52ff83420d58af1cb3c10@haskell.org> #15341: :info prints kinds in closed type family equations without enabling -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4932 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4932 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 16:51:09 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 16:51:09 -0000 Subject: [GHC] #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) In-Reply-To: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> References: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> Message-ID: <065.e3c06259b03c398141a33eb6b36f7ff6@haskell.org> #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I would expect forall a b. (C a, D a b) to be shorthand for forall a b. C a and forall a b. D a b I agree that there is no other sensible interpretation, but it's a pretty significant implicit rewriting of types. I'm not yet convinced that it pays its way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 17:17:16 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 17:17:16 -0000 Subject: [GHC] #12674: GHC doesn't handle ./ prefixed paths correctly In-Reply-To: <047.897ae5e9c5c47ed13f84034ccb7c5729@haskell.org> References: <047.897ae5e9c5c47ed13f84034ccb7c5729@haskell.org> Message-ID: <062.3519e64bf91390b859d914779d372b45@haskell.org> #12674: GHC doesn't handle ./ prefixed paths correctly -------------------------------------+------------------------------------- Reporter: dobenour | Owner: RolandSenn Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RolandSenn): == The Problem I have looked into this and found the following: Assume we use: {{{ ghc ./-Module.hs }}} In the module ''ghc/Main.hs'' we have the following code in the function ''main' '' : {{{ let -- To simplify the handling of filepaths, we normalise all filepaths right -- away - e.g., for win32 platforms, backslashes are converted -- into forward slashes. normal_fileish_paths = map (normalise . unLoc) fileish_args (srcs, objs) = partition_args normal_fileish_paths [] [] <-- --- some lines dropped --- --> ---------------- Final sanity checking ----------- liftIO $ checkOptions postLoadMode dflags6 srcs objs }}} In the ''normalise'' function the FilePath **./-Module.hs** get normalised to **-Module.hs**. Then the ''checkOptions'' function reports an error, because ''-Module.hs'' is not a valid flag and processing stops! I see two possible solutions to fix this: == The hacky solution: We send non-normalised filenames to the ''checkOptions'' function. Then the processing continues. But we get problems, when we send the ''-Module.hs'' file to the preprocessor or the ''-Module.o'' file to the linker. At these locations (and maybe at some more) we have to prepend the ./ to the module name again, but only if it starts with a hyphen. == The radical solution: We extend the function ''library/filepath/System/FilePath/Internal/normalise'' so it works the following way: **./Module.hs** is normalised to **Module.hs** (as it does now) **./-Module.hs** is not normalised and remains **./-Module.hs** (this is new!!) This change in the library is a little bit more dangerous. With both solutions, only users with filenames starting with a hyphen should be affected. Please advice! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 17:18:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 17:18:38 -0000 Subject: [GHC] #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) In-Reply-To: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> References: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> Message-ID: <065.cef8ea80a5dc52a6b77b2dbf0ccacaab@haskell.org> #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): But this is done for ordinary constraints, right in the parser. Here is s slice of RdrHsSyn: {{{#!hs checkContext :: LHsType GhcPs -> P ([AddAnn],LHsContext GhcPs) checkContext (L l orig_t) = check [] (L l orig_t) where check anns (L lp (HsTupleTy _ HsBoxedOrConstraintTuple ts)) -- (Eq a, Ord b) shows up as a tuple type. Only boxed tuples can -- be used as context constraints. = return (anns ++ mkParensApiAnn lp,L l ts) -- Ditto () ... }}} Sadly, I don't think we can just do this in the parser, as it would really complicate the AST. But then we should perhaps directly reject `forall x. ( ... , ... )` as it won't mean what the user wants. I still favor the rewrite, but I think that, failing that, we should error more cleanly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 17:28:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 17:28:32 -0000 Subject: [GHC] #15342: Mark -XAutoDeriveTypeable as deprecated Message-ID: <047.58435d34138b96a2bf714e154c899347@haskell.org> #15342: Mark -XAutoDeriveTypeable as deprecated -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The language extension `-XAutoDeriveTypeable` is not needed since #9858. It was earlier marked as redundant in GHC documentation. I propose that GHC gives a clear deprecation message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 17:32:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 17:32:48 -0000 Subject: [GHC] #15342: Mark -XAutoDeriveTypeable as deprecated In-Reply-To: <047.58435d34138b96a2bf714e154c899347@haskell.org> References: <047.58435d34138b96a2bf714e154c899347@haskell.org> Message-ID: <062.874ff7a2ed524154dbe2c5019c32a993@haskell.org> #15342: Mark -XAutoDeriveTypeable as deprecated -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4933 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => patch * differential: => D4933 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 17:52:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 17:52:28 -0000 Subject: [GHC] #15342: Mark -XAutoDeriveTypeable as deprecated In-Reply-To: <047.58435d34138b96a2bf714e154c899347@haskell.org> References: <047.58435d34138b96a2bf714e154c899347@haskell.org> Message-ID: <062.920d49a59e3d3ec59a6f3b641f40a9b4@haskell.org> #15342: Mark -XAutoDeriveTypeable as deprecated -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4933 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: D4933 => Phab:D4933 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 18:08:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 18:08:37 -0000 Subject: [GHC] #15343: Implicitly quantifying a kind variable causes GHC 8.6 to panic (coercionKind) Message-ID: <050.0e8877c07406b2b81b1a5431ef627da1@haskell.org> #15343: Implicitly quantifying a kind variable causes GHC 8.6 to panic (coercionKind) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program panics on GHC 8.6 and later: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind import Data.Type.Equality data family Sing :: forall k. k -> Type data SomeSing :: Type -> Type where SomeSing :: Sing (a :: k) -> SomeSing k class SingKind k where type Demote k :: Type fromSing :: Sing (a :: k) -> Demote k toSing :: Demote k -> SomeSing k data instance Sing (z :: a :~~: b) where SHRefl :: Sing HRefl instance SingKind (a :~~: b) where type Demote (a :~~: b) = a :~~: b fromSing SHRefl = HRefl toSing HRefl = SomeSing SHRefl data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 (~>:~~:) :: forall (j :: Type) (k :: Type) (a :: j) (b :: k) (p :: forall (z :: Type) (y :: z). (a :~~: y) ~> Type) (r :: a :~~: b). Sing r -> Apply p HRefl -> Apply p r (~>:~~:) SHRefl pHRefl = pHRefl type family Why (a :: j) (e :: a :~~: (y :: z)) :: Type where Why a (_ :: a :~~: y) = y :~~: a data WhySym (a :: j) :: forall (y :: z). (a :~~: y) ~> Type -- data WhySym (a :: j) :: forall z (y :: z). (a :~~: y) ~> Type -- The version above does NOT panic type instance Apply (WhySym a) e = Why a e hsym :: forall (j :: Type) (k :: Type) (a :: j) (b :: k). a :~~: b -> b :~~: a hsym eq = case toSing eq of SomeSing (singEq :: Sing r) -> (~>:~~:) @j @k @a @b @(WhySym a) @r singEq HRefl }}} {{{ $ /opt/ghc/8.6.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.6.0.20180627 for x86_64-unknown-linux): coercionKind Nth:3 (Inst {co_a1jI} (Coh _N (Nth:0 (Sym {co_a1jI})))) Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/types/Coercion.hs:1887:9 in ghc:Coercion }}} As noted in the comments, replacing `WhySym` with a version that explicitly quantifies `z` avoids the panic. This is a regression from GHC 8.4.3, in which the program simply errored: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:56:38: error: • Expected kind ‘forall z (y :: z). (a1 :~~: y) ~> *’, but ‘WhySym a’ has kind ‘forall (y :: z0). TyFun (a1 :~~: y) * -> *’ • In the type ‘(WhySym a)’ In the expression: (~>:~~:) @j @k @a @b @(WhySym a) @r singEq HRefl In a case alternative: SomeSing (singEq :: Sing r) -> (~>:~~:) @j @k @a @b @(WhySym a) @r singEq HRefl • Relevant bindings include singEq :: Sing a2 (bound at Bug.hs:55:23) eq :: a1 :~~: b (bound at Bug.hs:54:6) hsym :: (a1 :~~: b) -> b :~~: a1 (bound at Bug.hs:54:1) | 56 | (~>:~~:) @j @k @a @b @(WhySym a) @r singEq HRefl | ^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 18:37:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 18:37:18 -0000 Subject: [GHC] #15343: Implicitly quantifying a kind variable causes GHC 8.6 to panic (coercionKind) In-Reply-To: <050.0e8877c07406b2b81b1a5431ef627da1@haskell.org> References: <050.0e8877c07406b2b81b1a5431ef627da1@haskell.org> Message-ID: <065.587e6a8636d83a1f2d632d85fb61de27@haskell.org> #15343: Implicitly quantifying a kind variable causes GHC 8.6 to panic (coercionKind) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here's a smaller example: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind data HEq :: forall j k. j -> k -> Type where HRefl :: HEq a a data Sing :: forall j k (a :: j) (b :: k). HEq a b -> Type where SHRefl :: Sing HRefl elimSing :: forall (j :: Type) (k :: Type) (a :: j) (b :: k) (p :: forall (z :: Type) (y :: z). HEq a y -> Type) (r :: HEq a b). Sing r -> p HRefl -> p r elimSing SHRefl pHRefl = pHRefl data WhySym (a :: j) :: forall (y :: z). HEq a y -> Type -- data WhySym (a :: j) :: forall z (y :: z). (a :~~: y) ~> Type -- The version above does NOT panic hsym :: forall (j :: Type) (k :: Type) (a :: j) (b :: k) (r :: HEq a b). Sing r -> WhySym a r hsym singEq = elimSing @j @k @a @b @(WhySym a) @r singEq undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 18:47:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 18:47:11 -0000 Subject: [GHC] #15343: Implicitly quantifying a kind variable causes GHC 8.6 to panic (coercionKind) In-Reply-To: <050.0e8877c07406b2b81b1a5431ef627da1@haskell.org> References: <050.0e8877c07406b2b81b1a5431ef627da1@haskell.org> Message-ID: <065.6ff483e56a0b3f16f9a49716b146323b@haskell.org> #15343: Implicitly quantifying a kind variable causes GHC 8.6 to panic (coercionKind) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire (added) Comment: This started panicking in commit e3dbb44f53b2f9403d20d84e27f187062755a089 (Fix #12919 by making the flattener homegeneous.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 21:16:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 21:16:18 -0000 Subject: [GHC] #15343: Implicitly quantifying a kind variable causes GHC 8.6 to panic (coercionKind) In-Reply-To: <050.0e8877c07406b2b81b1a5431ef627da1@haskell.org> References: <050.0e8877c07406b2b81b1a5431ef627da1@haskell.org> Message-ID: <065.ee894c8ca90753fd6ccd27b9971b386c@haskell.org> #15343: Implicitly quantifying a kind variable causes GHC 8.6 to panic (coercionKind) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): Simplification: {{{ #!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind elimSing :: forall (p :: forall z. z). p elimSing = undefined data WhySym :: Type -> Type hsym = elimSing @WhySym }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 22:07:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 22:07:05 -0000 Subject: [GHC] #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 In-Reply-To: <047.0e132514379b72c39d1662f2412d5748@haskell.org> References: <047.0e132514379b72c39d1662f2412d5748@haskell.org> Message-ID: <062.1fc4b117a9b8103144b5a7ec1b0f2fce@haskell.org> #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 -------------------------------------+------------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): I think I can reproduce it in qemu-sh4 on ghc-HEAD. Will look at it. {{{ $ file utils/ghc-pkg/dist-install/build/tmp/ghc-pkg utils/ghc-pkg/dist-install/build/tmp/ghc-pkg: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), dynamically linked, interpreter /lib/ld- linux.so.2, for GNU/Linux 3.2.0, not stripped $ LD_LIBRARY_PATH="$(pwd)/rts/dist/build:"$(for d in $(find -name '*.so' | fgrep dist-install); do dirname "$(pwd)/$d"; done | tr '$\n' ':') utils /ghc-pkg/dist-install/build/tmp/ghc-pkg --version GHC package manager version 8.7.20180704 $ LD_LIBRARY_PATH="$(pwd)/rts/dist/build:"$(for d in $(find -name '*.so' | fgrep dist-install); do dirname "$(pwd)/$d"; done | tr '$\n' ':') utils /ghc-pkg/dist-install/build/tmp/ghc-pkg --version | cat }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 23:53:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 23:53:59 -0000 Subject: [GHC] #15344: ApplicativeDo seems to prevent the fail method from being used Message-ID: <045.128f442b671dce29e648c88eaa28e644@haskell.org> #15344: ApplicativeDo seems to prevent the fail method from being used -------------------------------------+------------------------------------- Reporter: kccqzy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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 am not sure if this is intended, but I came across this issue when debugging a runtime exception. It seems like an incomplete pattern match in a do-block with ApplicativeDo enabled will not use the fail method. If I have a module like this {{{#!hs {-# LANGUAGE ApplicativeDo #-} {-# OPTIONS_ghc -ddump-simpl #-} module M where f :: Maybe (Maybe Int) -> Maybe Int -> Maybe Int f mgs mid = do _ <- mid (Just moi) <- mgs pure (moi + 42) main :: IO () main = print (f (Just Nothing) (Just 2)) }}} This will result in a runtime exception: {{{ Just *** Exception: repro.hs:(6,13)-(9,17): Non-exhaustive patterns in lambda }}} But if I remove the ApplicativeDo extension, this code works as normal, producing Nothing as the output. On a theoretical level I understand why this is happening, but I still find it quite unexpected, especially since the documentation at https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #things-to-watch-out-for claims that > Your code should just work as before when ApplicativeDo is enabled, provided you use conventional Applicative instances. If this is not a defect in GHC itself, I'd say it is a defect in documentation in not pointing out this gotcha. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 4 23:54:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 04 Jul 2018 23:54:30 -0000 Subject: [GHC] #15344: ApplicativeDo seems to prevent the fail method from being used In-Reply-To: <045.128f442b671dce29e648c88eaa28e644@haskell.org> References: <045.128f442b671dce29e648c88eaa28e644@haskell.org> Message-ID: <060.350d086197484c63bedab2be6593a0ab@haskell.org> #15344: ApplicativeDo seems to prevent the fail method from being used -------------------------------------+------------------------------------- Reporter: kccqzy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kccqzy): * Attachment "repro.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 01:02:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 01:02:15 -0000 Subject: [GHC] #14941: Switching direct type family application to EqPred (~) prevents inlining in code using vector (10x slowdown) In-Reply-To: <042.0e3de7917bdd684aac8357b129fd4898@haskell.org> References: <042.0e3de7917bdd684aac8357b129fd4898@haskell.org> Message-ID: <057.d42cdf40e6132814bce01a7d44a0baf8@haskell.org> #14941: Switching direct type family application to EqPred (~) prevents inlining in code using vector (10x slowdown) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 nh2): This seems to be unrelated to type families and only a problem with `~` in general, because: I now also found a case where using `(val ~ Int) =>` produces slower code than subsituting `val` with `Int` syntactically, or using `SPECIALISE`. {{{ myfun :: forall val . (Eq val, Show val, val ~ Int) => Mytype1 val -> Mytype2 val -> Mytype3 -> Mytype4 -> Mytype5 -> Mytype6 -> IO () }}} is slow, but {{{ {-# SPECIALIZE myfun :: Mytype1 Int -> Mytype2 Int -> Mytype3 -> Mytype4 -> Mytype5 -> Mytype6 -> IO () #-} myfun :: forall val . (Eq val, Show val, val ~ Int) => Mytype1 val -> Mytype2 val -> Mytype3 -> Mytype4 -> Mytype5 -> Mytype6 -> IO () }}} is fast (in my case, a 30% performance difference). Diffing the output of `-ddump-simpl -ddump-to-file -dsuppress-idinfo -dsuppress-coercions -dsuppress-module-prefixes -dsuppress-uniques` shows how the call looks different from a module that calls `myfun`: `val ~ Int` version: {{{ $d~~ :: (Int :: *) ~~ (Int :: *) $d~~ = Eq# @ * @ * @ Int @ Int @~ ... ... $wmyfun @ Int $fEqInt ($d~~ `cast` ...) y wild mything1 ipv7 mything2 ww1 w9) ... }}} `SPECIALISE`d `val ~ Int` version: {{{ myfun y wild mything1 ipv7 mything2 ww1 }}} I would have expect that after the simplifier has run, GHC would have used all information it has to produce the best core (e.g. use the fact that it knows `val ~ Int` even without `SPECIALISE`), but it did not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 02:44:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 02:44:21 -0000 Subject: [GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker In-Reply-To: <049.2656489ff85910f6a80bbfa971643315@haskell.org> References: <049.2656489ff85910f6a80bbfa971643315@haskell.org> Message-ID: <064.4f5e347ad35f9acf4a689b1771f436d4@haskell.org> #15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11547 #14052 | Differential Rev(s): Phab:D4909 #15202 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): osa1: I still get the same assertion failure with comment:14 after a fresh debug-enabled build. My build flavors is: {{{ SRC_HC_OPTS = -O -H64m GhcStage1HcOpts = -O GhcStage2HcOpts = -O -DDEBUG GhcLibHcOpts = -O -dcore-lint BUILD_PROF_LIBS = YES SplitObjs = NO SplitSections = NO HADDOCK_DOCS = NO BUILD_SPHINX_HTML = NO BUILD_SPHINX_PDF = NO BUILD_MAN = NO LAX_DEPENDENCIES = YES GhcProfiled = YES INTEGER_LIBRARY = integer-simple }}} If I remove the `-DDEBUG` in `GhcStage2HcOpts` and rebuild ghc-stage2, I can get the same error message with comment:17. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 06:33:58 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 06:33:58 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.b96a64b574b537acce0ac06caec865cb@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aaronvargo): Replying to [comment:14 simonpj]: > In this case, do you think that there is a finite tower of superclasses? I get > {{{ > [G] Category p > +-> {add superclasses} > Functor p > Dom p ~ Op p > Cod p ~ Nat p (->) > Ob (Op p) ~ Ob p > > +-> {add superclasse of Functor} > Category (Dom p) > Cateogory (Cod p) > }}} > and now we merrily go round. Adding `p ~ Op (Op p)` will help, because `Dom p ~ Op p`. But we are still going to get `Cateogry (Cod p)`, `Category (Cod (Cod p))` and so on. Is that really what you intend? What if you take instances into account in considering when to terminate? Then the tower is finite, since `Category (Cod p)` is a consequence of: {{{#!hs Category p Cod p ~ Nat p (->) instance (Category p, Category q) => Category (Nat p q) instance Category (->) }}} and so the fact that `Category (Cod p)` is a superclass provides no new information, and thus there's no need to go any further. This also suggests a slightly ugly work-around, which indeed seems to work (at least in this case): {{{#!hs -- Functor without Category (Cod f) class Category (Dom f) => Functor' (f :: i -> j) -- Functor with Category (Cod f) class (Functor' f, Category (Cod f)) => Functor f instance (Functor' f, Category (Cod f)) => Functor f -- only require Functor', since Category (Cod p) is already implied class ( Functor' p , Dom p ~ Op p , Cod p ~ Nat p (->) , Ob (Op p) ~ Ob p , Op (Op p) ~ p ) => Category (p :: Cat i) }}} Tangentially, there's also really no need for `Op p`, since it's just equal to `Dom p`, and so `Category` can be simplified to: {{{#!hs class ( Functor' p , Cod p ~ Nat p (->) , Dom (Dom p) ~ p , Ob (Dom p) ~ Ob p ) => Category (p :: Cat i) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 06:44:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 06:44:55 -0000 Subject: [GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker In-Reply-To: <049.2656489ff85910f6a80bbfa971643315@haskell.org> References: <049.2656489ff85910f6a80bbfa971643315@haskell.org> Message-ID: <064.68c48b0de100b6dc8faecb549baba41c@haskell.org> #15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11547 #14052 | Differential Rev(s): Phab:D4909 #15202 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I was using `GhcDebugged = YES` but apparently that doesn't add `-DDEBUG`, it just adds `-debug`. It seems this ticket needs more work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 06:57:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 06:57:21 -0000 Subject: [GHC] #11547: Accessing shadowed definitions in GHCi In-Reply-To: <044.71011ab462b5fa37155c58f145f7265b@haskell.org> References: <044.71011ab462b5fa37155c58f145f7265b@haskell.org> Message-ID: <059.0db44625bb8ebeed3f681f45febfd087@haskell.org> #11547: Accessing shadowed definitions in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 8.0.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14052 | Differential Rev(s): Phab:D2447 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: => #14052 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 07:05:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 07:05:23 -0000 Subject: [GHC] #15344: ApplicativeDo seems to prevent the fail method from being used In-Reply-To: <045.128f442b671dce29e648c88eaa28e644@haskell.org> References: <045.128f442b671dce29e648c88eaa28e644@haskell.org> Message-ID: <060.b719de49c45d9450a4bae0c2c68e7391@haskell.org> #15344: ApplicativeDo seems to prevent the fail method from being used -------------------------------------+------------------------------------- Reporter: kccqzy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: simonmar (added) * keywords: => ApplicativeDo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 07:27:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 07:27:10 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.a9230ca2b26cab992d3a8e898b3adea7@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > What if you take instances into account in considering when to terminate? That's a very interesting point. Currently, for each new "Given" (of which the potential superclasses are an example), GHC 1. Rewrites it with currently available Given equalities, a kind of normalisation step 2. And then sees if it is syntactically equal to one of the existing Givens. You are suggesting changing Step 2 to 2. See if it is ''completely provable from'' the existing Givens and top- level instances That is an intriguing thought. I say "completely" provable from because suppose you had {{{ instance (C a, D a) => D (T a) [G] C a }}} and you were about to add `[G] D (T a)`. The instance declaration applies, yielding sub-goals `(C a, D a)`. We have `(C a)`, but not `D a`. So I think we then must abandon the attempt -- even if only one out of hundreds of sub-goals fails -- and add the proposed new Given after all. I worry a bit about solve order. In the original example, suppose we added `[G] Category (Cod p)` ''before'' we added `Category p`. If we were going to be solidly robust to solve order, whenever we added a new Given we'd have to check all the ''existing'' Givens to see if any of them could be proved from the new one (and the others). But perhaps we could apply this magic only to the superclass expansion step; for "normal" Givens it's at most an optimisation. Interesting! I wonder if there are any other compelling examples. Edward?? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 09:18:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 09:18:11 -0000 Subject: [GHC] #14941: Switching direct type family application to EqPred (~) prevents inlining in code using vector (10x slowdown) In-Reply-To: <042.0e3de7917bdd684aac8357b129fd4898@haskell.org> References: <042.0e3de7917bdd684aac8357b129fd4898@haskell.org> Message-ID: <057.0771a22589df662557f37c8b54a6c015@haskell.org> #14941: Switching direct type family application to EqPred (~) prevents inlining in code using vector (10x slowdown) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 think I see. Can you offer a small example? I think something like this is happening. We have {{{ ...(\(g :: Int ~ val). ...f (d |> Num g)... ) ... where d :: Num Int }}} Now, we can't float that call up to the definition of `f` because it mentions `g`. But we could in principle specialise `f` for `Num Int`, and then use that specialised version at the call. I'm not certain this is exactly what is happening for you. Hence wanting a test case. (You don't need to exhibit worse perf; just that a specialisation is created and used without the equality, but not with.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 09:30:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 09:30:08 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.acf3079053979cc0d2e656330569f271@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aaronvargo): Are `QuantifiedConstraints` another thing to consider here? The proposed magic would properly account for them as well, while the current rules presumably ignore them the same way they ignore top-level instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 09:46:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 09:46:41 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.0473c5ee9edb1891ea49029b40b9c7d0@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I guess so. Can you offer an example? So far we we have precisely one example needing the magic... more examples would strengthen the case for making a change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 09:52:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 09:52:16 -0000 Subject: [GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin In-Reply-To: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> References: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> Message-ID: <062.4ddfa19407a9569c44121fdbceb18031@haskell.org> #15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | typeable,knownnat Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10348 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7ce6f642a2806c425ba21d48a077d997703cf25b/ghc" 7ce6f642/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7ce6f642a2806c425ba21d48a077d997703cf25b" Add comments on Typeable (n :: Nat) See Note [Typeable for Nat and Symbol] in TcInteract, which I added after discussion on Trac #15322 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 09:52:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 09:52:16 -0000 Subject: [GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin In-Reply-To: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> References: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> Message-ID: <062.084f81ff6bc37810db82b4cdd31339a9@haskell.org> #15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | typeable,knownnat Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10348 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"45f44e2c9d5db2f25c52abb402f197c20579400f/ghc" 45f44e2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="45f44e2c9d5db2f25c52abb402f197c20579400f" Refactor validity checking for constraints There are several changes here. * TcInteract has gotten too big, so I moved all the class-instance matching out of TcInteract into a new module ClsInst. It parallels the FamInst module. The main export of ClsInst is matchGlobalInst. This now works in TcM not TcS. * A big reason to make matchGlobalInst work in TcM is that we can then use it from TcValidity.checkSimplifiableClassConstraint. That extends checkSimplifiableClassConstraint to work uniformly for built-in instances, which means that we now get a warning if we have givens (Typeable x, KnownNat n); see Trac #15322. * This change also made me refactor LookupInstResult, in particular by adding the InstanceWhat field. I also changed the name of the type to ClsInstResult. Then instead of matchGlobalInst reporting a staging error (which is inappropriate for the call from TcValidity), we can do so in TcInteract.checkInstanceOK. * In TcValidity, we now check quantified constraints for termination. For example, this signature should be rejected: f :: (forall a. Eq (m a) => Eq (m a)) => blah as discussed in Trac #15316. The main change here is that TcValidity.check_pred_help now uses classifyPredType, and has a case for ForAllPred which it didn't before. This had knock-on refactoring effects in TcValidity. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 09:52:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 09:52:16 -0000 Subject: [GHC] #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints In-Reply-To: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> References: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> Message-ID: <059.0ecb8df0a529858520b0bc58ab65315a@haskell.org> #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"45f44e2c9d5db2f25c52abb402f197c20579400f/ghc" 45f44e2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="45f44e2c9d5db2f25c52abb402f197c20579400f" Refactor validity checking for constraints There are several changes here. * TcInteract has gotten too big, so I moved all the class-instance matching out of TcInteract into a new module ClsInst. It parallels the FamInst module. The main export of ClsInst is matchGlobalInst. This now works in TcM not TcS. * A big reason to make matchGlobalInst work in TcM is that we can then use it from TcValidity.checkSimplifiableClassConstraint. That extends checkSimplifiableClassConstraint to work uniformly for built-in instances, which means that we now get a warning if we have givens (Typeable x, KnownNat n); see Trac #15322. * This change also made me refactor LookupInstResult, in particular by adding the InstanceWhat field. I also changed the name of the type to ClsInstResult. Then instead of matchGlobalInst reporting a staging error (which is inappropriate for the call from TcValidity), we can do so in TcInteract.checkInstanceOK. * In TcValidity, we now check quantified constraints for termination. For example, this signature should be rejected: f :: (forall a. Eq (m a) => Eq (m a)) => blah as discussed in Trac #15316. The main change here is that TcValidity.check_pred_help now uses classifyPredType, and has a case for ForAllPred which it didn't before. This had knock-on refactoring effects in TcValidity. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 11:05:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 11:05:04 -0000 Subject: [GHC] #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints In-Reply-To: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> References: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> Message-ID: <059.3efa3d68f11fdc32ee4be55c9b214b35@haskell.org> #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: quantified- invalid program | constraints/T15316 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => quantified-constraints/T15316 Comment: OK, so now you need `UndecidableInstances` to have bad quantified constraints, just as the original proposal said. Probably worth merging, not crucial -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 11:11:30 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 11:11:30 -0000 Subject: [GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin In-Reply-To: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> References: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> Message-ID: <062.6ceb3d1012add62b2a2718c75dfcecdb@haskell.org> #15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | typeable,knownnat Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10348 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): My patch makes the reporting of unnecessary constraints more consistent -- in particular, accounting for built-in constraints. The original program still fails in the same way, for the reason explained in comment:1. What is the "real" fix? Well, despite comment:1 ''we'' know that `Typeable (n+1)` is never going to simplify to `Typeable n` (at least, not without using instances), because we know that `n+1 /= n`. But doesn't know that. The plug-in, I imagine, allows GHC to solve `KnownNat (n+1)` from `KnownNat n`. We want the plugin ''also'' to be able to say that `n` '''is apart from''' `n+1`; that is, they can never be equal. This is a property of `(+)`. So I think that perhaps domain-specific apartness should be part of what a typechecker plugin can specify. I'll leave this ticket open to discuss that idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 11:59:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 11:59:56 -0000 Subject: [GHC] #15136: High CPU when asynchronous exception and unblocking retry on TVar raced In-Reply-To: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> References: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> Message-ID: <062.0e165e4be28d59ce9a873b83fe686bbd@haskell.org> #15136: High CPU when asynchronous exception and unblocking retry on TVar raced -------------------------------------+------------------------------------- Reporter: nshimaza | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Just to repeat comment:1 and comment:2 with my words: Thread 1 kills Thread 2 which is blocked on a TVar operation. For this it calls raiseAsync() and for that it has to lock Thread 2 (lockTSO). Then to abort the transaction it needs to lock the TVar (lock_tvar). At the same time Thread 3 succeeds to modify the TVar and to unblock any threads blocked on this TVar it needs to lock the TVar (lock_tvar), and then to actually unblock the thread it needs to lock the TSO (lockTSO). When the order of locking goes like this: - Thread 1 locks the TSO (lockTSO) - Thread 3 locks the TVar (lock_tvar) We get a deadlock because Thread 1 now wants to lock the TVar and Thread 3 wants to lock the TSO, both of which are locked already. > Perhaps we should switch to using an owner semantics for BlockedOnSTM too - > that is, if we see BlockedOnSTM in raiseAsync, we attempt to lock the TVar > pointed to by tso->block_info. I only get `END_TSO_QUEUE` in `tso->block_info`. I think the TVar is only reachable from the array list `tso->trec->current_chunk`. I guess we could do this: - Lock the TSO - If BlockedOnSTM then check tso->trec entries. Expect to see only one TVar there (can we have more than on TVars here?). Lock the TVar and release the TSO. - Continue with raiseAsync() I don't know if we can see more than one TVar in tso->trec entries. Also, we need to modify stmAbortTransaction because we'll have the TVar locked already, but it still needs to lock it when it's called from other call sites (e.g. from `raise#`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 12:29:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 12:29:39 -0000 Subject: [GHC] #15234: WARNING in hptSomeThingsBelowUs when using a source plugin In-Reply-To: <049.15722b69a2f4eb74d7898931a7d1b55a@haskell.org> References: <049.15722b69a2f4eb74d7898931a7d1b55a@haskell.org> Message-ID: <064.8eca01ecd2fc428511d5138833b2ad2b@haskell.org> #15234: WARNING in hptSomeThingsBelowUs when using a source plugin -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | SourcePlugins, plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by darchon): It seems that the combination of plugins, TH, and ghc861rc1 just completely fails; this is me trying to compile `clash-prelude` on ghc861rc: {{{ WARNING in hptSomeThingsBelowUs missing module GHC.TypeLits.KnownNat.Solver Probable cause: out-of-date interface files WARNING in hptSomeThingsBelowUs missing module GHC.TypeLits.Normalise Probable cause: out-of-date interface files WARNING in hptSomeThingsBelowUs missing module GHC.TypeLits.KnownNat.Solver Probable cause: out-of-date interface files [34 of 67] Compiling Clash.Signal.Bundle ( src/Clash/Signal/Bundle.hs, /home/christiaan/devel/clash-prelude/dist- newstyle/build/x86_64-linux/ghc-8.6.0.20180627/clash- prelude-0.99/build/Clash/Signal/Bundle.o ) src/Clash/Signal/Bundle.hs:1:1: fatal: cannot find object file for module ‘GHC.TypeLits.KnownNat.Solver’ while linking an interpreted expression }}} I could open a new issue, but they probably have same root cause, so I'm just reporting it here. I'll see if I can make a smaller test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 13:51:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 13:51:59 -0000 Subject: [GHC] #15308: Error message prints explicit kinds when it shouldn't In-Reply-To: <050.8a60180d637a0d8f09dfd184e0f165b6@haskell.org> References: <050.8a60180d637a0d8f09dfd184e0f165b6@haskell.org> Message-ID: <065.7ac2544ae72ab459a362ad7bc980d2fe@haskell.org> #15308: Error message prints explicit kinds when it shouldn't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4891 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"93b7ac8d73885369f61f6eb6147352d45de4e957/ghc" 93b7ac8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="93b7ac8d73885369f61f6eb6147352d45de4e957" Fix #15308 by suppressing invisble args more rigorously Summary: There was a buglet in `stripInvisArgs` (which is part of the pretty-printing pipeline for types) in which only invisble arguments which came before any visible arguments would be suppressed, but any invisble arguments that came //after// visible ones would still be printed, even if `-fprint-explicit-kinds` wasn't enabled. The fix is simple: make `stripInvisArgs` recursively process the remaining types even after a visible argument is encountered. Test Plan: make test TEST=T15308 Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #15308 Differential Revision: https://phabricator.haskell.org/D4891 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 13:51:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 13:51:59 -0000 Subject: [GHC] #15307: Incorrect -ddump-deriv parenthesization for GND'd fmap implementation In-Reply-To: <050.5a1160e153a31f1bbdd2d69e21505079@haskell.org> References: <050.5a1160e153a31f1bbdd2d69e21505079@haskell.org> Message-ID: <065.4c24d4d59f0462a71f43a1d24cda8198@haskell.org> #15307: Incorrect -ddump-deriv parenthesization for GND'd fmap implementation -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4890 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"59a15a56e180b59656e45df04f7df61de8298881/ghc" 59a15a5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="59a15a56e180b59656e45df04f7df61de8298881" Fix #15307 by making nlHsFunTy parenthesize more Summary: `nlHsFunTy` wasn't parenthesizing its arguments at all, which led to `-ddump-deriv` producing incorrectly parenthesized types (since it uses `nlHsFunTy` to construct those types), as demonstrated in #15307. Fix this by changing `nlHsFunTy` to add parentheses à la `ppr_ty`: always parenthesizing the argument type with function precedence, and recursively processing the result type, adding parentheses for each function type it encounters. Test Plan: make test TEST=T14578 Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15307 Differential Revision: https://phabricator.haskell.org/D4890 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 13:51:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 13:51:59 -0000 Subject: [GHC] #14883: QuantifiedConstraints don't kick in when used in TypeApplications In-Reply-To: <050.9ae7dfd18c1aed745c56cdebbc78f3e8@haskell.org> References: <050.9ae7dfd18c1aed745c56cdebbc78f3e8@haskell.org> Message-ID: <065.f3254d94fc10f87a51855b7a12eff530@haskell.org> #14883: QuantifiedConstraints don't kick in when used in TypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #15290 | Differential Rev(s): Phab:D4895 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"132273f34e394bf7e900d0c15e01e91edd711890/ghc" 132273f3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="132273f34e394bf7e900d0c15e01e91edd711890" Instantiate GND bindings with an explicit type signature Summary: Before, we were using visible type application to apply impredicative types to `coerce` in `GeneralizedNewtypeDeriving`-generated bindings. This approach breaks down when combined with `QuantifiedConstraints` in certain ways, which #14883 and #15290 provide examples of. See Note [GND and QuantifiedConstraints] for all the gory details. To avoid this issue, we instead use an explicit type signature to instantiate each GND binding, and use that to bind any type variables that might be bound by a class method's type signature. This reduces the need to impredicative type applications, and more importantly, makes the programs from #14883 and #15290 work again. Test Plan: make test TEST="T15290b T15290c T15290d T14883" Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14883, #15290 Differential Revision: https://phabricator.haskell.org/D4895 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 13:51:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 13:51:59 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.67d2ac1ce2556fc67f8ba893de6515e9@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15290, T15290a Blocked By: | Blocking: 9123 Related Tickets: | Differential Rev(s): Phab:D4895 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"132273f34e394bf7e900d0c15e01e91edd711890/ghc" 132273f3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="132273f34e394bf7e900d0c15e01e91edd711890" Instantiate GND bindings with an explicit type signature Summary: Before, we were using visible type application to apply impredicative types to `coerce` in `GeneralizedNewtypeDeriving`-generated bindings. This approach breaks down when combined with `QuantifiedConstraints` in certain ways, which #14883 and #15290 provide examples of. See Note [GND and QuantifiedConstraints] for all the gory details. To avoid this issue, we instead use an explicit type signature to instantiate each GND binding, and use that to bind any type variables that might be bound by a class method's type signature. This reduces the need to impredicative type applications, and more importantly, makes the programs from #14883 and #15290 work again. Test Plan: make test TEST="T15290b T15290c T15290d T14883" Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14883, #15290 Differential Revision: https://phabricator.haskell.org/D4895 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 13:51:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 13:51:59 -0000 Subject: [GHC] #15318: Core Lint error involving newtype family instances with wrappers In-Reply-To: <050.5e4047b16b9f07feb6a762d8a4dad8f6@haskell.org> References: <050.5e4047b16b9f07feb6a762d8a4dad8f6@haskell.org> Message-ID: <065.162128d795a7241c5d9d4d08dca8d8c7@haskell.org> #15318: Core Lint error involving newtype family instances with wrappers -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4902 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"927518668111584a06f12bd9eb1b0910a38acf4f/ghc" 9275186/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="927518668111584a06f12bd9eb1b0910a38acf4f" Fix newtype instance GADTs Summary: This was taken from Richard's branch, which in turn was submitted to Phab by Matthew, which in turn was commandeered by Ryan. This fixes an issue with newtype instances in which too many coercions were being applied in the worker. This fixes the issue by removing the data family instance axiom from the worker and moving to the wrapper. Moreover, we now require all newtype instances to have wrappers, for symmetry with data instances. Reviewers: goldfire, bgamari, simonpj, mpickering Reviewed By: mpickering Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #15318 Differential Revision: https://phabricator.haskell.org/D4902 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 13:51:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 13:51:59 -0000 Subject: [GHC] #15324: -ddump-splices does not parenthesize rank-n contexts correctly In-Reply-To: <050.ee7a8b6246f694a0997d3f3ae67f6212@haskell.org> References: <050.ee7a8b6246f694a0997d3f3ae67f6212@haskell.org> Message-ID: <065.39f9f1c3da0ab8a00f32c41d08ac4a87@haskell.org> #15324: -ddump-splices does not parenthesize rank-n contexts correctly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4910 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"57733978482dc1e566a7d4cd90d4cbbd1315e3b2/ghc" 57733978/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="57733978482dc1e566a7d4cd90d4cbbd1315e3b2" Parenthesize rank-n contexts in Convert Summary: A simple oversight. Test Plan: make test TEST=T15324 Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15324 Differential Revision: https://phabricator.haskell.org/D4910 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 13:51:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 13:51:59 -0000 Subject: [GHC] #15331: -ddump-splices does not parenthesize visible type applications correctly In-Reply-To: <050.5bac58b457c421337e97e68faa19a271@haskell.org> References: <050.5bac58b457c421337e97e68faa19a271@haskell.org> Message-ID: <065.3571ea8465e8f4bf63a9856580bce3d2@haskell.org> #15331: -ddump-splices does not parenthesize visible type applications correctly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4920 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"b6a3386186b77333b7a6cdc163499d7dae0dad1c/ghc" b6a3386/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b6a3386186b77333b7a6cdc163499d7dae0dad1c" Fix #15331 with careful blasts of parenthesizeHsType Summary: Another `-ddump-splices` bug that can be solved with more judicious use of parentheses. Test Plan: make test TEST=T15331 Reviewers: goldfire, bgamari, alanz, tdammers Reviewed By: tdammers Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15331 Differential Revision: https://phabricator.haskell.org/D4920 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 13:51:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 13:51:59 -0000 Subject: [GHC] #15341: :info prints kinds in closed type family equations without enabling -fprint-explicit-kinds In-Reply-To: <050.0a6e915f611ee596161321a86f26e2cc@haskell.org> References: <050.0a6e915f611ee596161321a86f26e2cc@haskell.org> Message-ID: <065.4d519a58791c58b3b46252146369d9bf@haskell.org> #15341: :info prints kinds in closed type family equations without enabling -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4932 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"dbdcacfc55f28d8a85484cc1cf13dd78c45bf7ee/ghc" dbdcacf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dbdcacfc55f28d8a85484cc1cf13dd78c45bf7ee" Make ppr_tc_args aware of -fprint-explicit-kinds Summary: `ppr_tc_args` was printing invisible kind arguments even when `-fprint-explicit-kinds` wasn't enabled. Easily fixed. Test Plan: make test TEST=T15341 Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #15341 Differential Revision: https://phabricator.haskell.org/D4932 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 13:58:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 13:58:52 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.579c5e4f4e81b0577d63942bc59377bd@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15290{,a,b}, | deriving/should_compile/T15290{c,d}, | deriving/should_compile/T14883 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4895 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: quantified-constraints/T15290, T15290a => quantified-constraints/T15290{,a,b}, deriving/should_compile/T15290{c,d}, deriving/should_compile/T14883 * blocking: 9123 => Comment: With the commit in comment:37, that should take care of business. As far as which commits to merge, my understanding is that you would need everything mentioned in this ticket, which encompasses: * 32eb41994f7448caf5fb6b06ed0678d79d029deb * 9fc40c733ba8822a04bd92883801b214dee099ca * 261dd83cacec71edd551e9c581d05285c9ea3226 * 132273f34e394bf7e900d0c15e01e91edd711890 Does that sound right? Also, I apologize in advance to Ben :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 14:00:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 14:00:26 -0000 Subject: [GHC] #9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.067d674e3a9b4aebc515b022cd130a49@haskell.org> #9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Roles, Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T9123{,a} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm slightly more optimistic about the likelihood of this working, but I would like to hear an algorithmic description of how this "anticipating the need for role-based implication constraint and then providing it" business would work before I'm fully onboard with the idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 14:01:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 14:01:29 -0000 Subject: [GHC] #15331: -ddump-splices does not parenthesize visible type applications correctly In-Reply-To: <050.5bac58b457c421337e97e68faa19a271@haskell.org> References: <050.5bac58b457c421337e97e68faa19a271@haskell.org> Message-ID: <065.8c4ee18ce911539ac5e1148e5f480376@haskell.org> #15331: -ddump-splices does not parenthesize visible type applications correctly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T15331 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4920 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge * testcase: => th/T15331 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 14:02:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 14:02:32 -0000 Subject: [GHC] #15324: -ddump-splices does not parenthesize rank-n contexts correctly In-Reply-To: <050.ee7a8b6246f694a0997d3f3ae67f6212@haskell.org> References: <050.ee7a8b6246f694a0997d3f3ae67f6212@haskell.org> Message-ID: <065.6bb33e53aaca10f5104918ded5ed12a7@haskell.org> #15324: -ddump-splices does not parenthesize rank-n contexts correctly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T15324 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4910 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge * testcase: => th/T15324 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 14:03:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 14:03:46 -0000 Subject: [GHC] #15341: :info prints kinds in closed type family equations without enabling -fprint-explicit-kinds In-Reply-To: <050.0a6e915f611ee596161321a86f26e2cc@haskell.org> References: <050.0a6e915f611ee596161321a86f26e2cc@haskell.org> Message-ID: <065.6a51da7f1b0b98a66f050c86d613d122@haskell.org> #15341: :info prints kinds in closed type family equations without enabling -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T15341 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4932 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge * testcase: => ghci/scripts/T15341 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 14:04:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 14:04:52 -0000 Subject: [GHC] #15318: Core Lint error involving newtype family instances with wrappers In-Reply-To: <050.5e4047b16b9f07feb6a762d8a4dad8f6@haskell.org> References: <050.5e4047b16b9f07feb6a762d8a4dad8f6@haskell.org> Message-ID: <065.39277f534352d29fdb308899df16343c@haskell.org> #15318: Core Lint error involving newtype family instances with wrappers -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: indexed- crash or panic | types/should_compile/T15318 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4902 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => merge * testcase: => indexed-types/should_compile/T15318 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 14:05:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 14:05:45 -0000 Subject: [GHC] #15307: Incorrect -ddump-deriv parenthesization for GND'd fmap implementation In-Reply-To: <050.5a1160e153a31f1bbdd2d69e21505079@haskell.org> References: <050.5a1160e153a31f1bbdd2d69e21505079@haskell.org> Message-ID: <065.754d12e5d24d0ef3c22d8ffd468d2218@haskell.org> #15307: Incorrect -ddump-deriv parenthesization for GND'd fmap implementation -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T14578 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4890 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge * testcase: => deriving/should_compile/T14578 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 14:08:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 14:08:22 -0000 Subject: [GHC] #14883: QuantifiedConstraints don't kick in when used in TypeApplications In-Reply-To: <050.9ae7dfd18c1aed745c56cdebbc78f3e8@haskell.org> References: <050.9ae7dfd18c1aed745c56cdebbc78f3e8@haskell.org> Message-ID: <065.81ef04cdb6c2c913430c68621a7e2610@haskell.org> #14883: QuantifiedConstraints don't kick in when used in TypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: fixed | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #15290 | Differential Rev(s): Phab:D4895 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 Comment: As noted in comment:6, #15290 completely obviates the need for a setup like the `Traversable'` instance for `T2`, so this issue can be closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 14:19:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 14:19:03 -0000 Subject: [GHC] #15308: Error message prints explicit kinds when it shouldn't In-Reply-To: <050.8a60180d637a0d8f09dfd184e0f165b6@haskell.org> References: <050.8a60180d637a0d8f09dfd184e0f165b6@haskell.org> Message-ID: <065.ec9a2821e4ab81fa457680278c85a422@haskell.org> #15308: Error message prints explicit kinds when it shouldn't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | dependent/should_fail/T15308 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4891 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => dependent/should_fail/T15308 * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 14:39:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 14:39:44 -0000 Subject: [GHC] #15234: WARNING in hptSomeThingsBelowUs when using a source plugin In-Reply-To: <049.15722b69a2f4eb74d7898931a7d1b55a@haskell.org> References: <049.15722b69a2f4eb74d7898931a7d1b55a@haskell.org> Message-ID: <064.76e71657b5ca93ae1509d001f27777ac@haskell.org> #15234: WARNING in hptSomeThingsBelowUs when using a source plugin -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | SourcePlugins, plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by darchon): * Attachment "0001-Plugin-dependency-information-is-stored- separately.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 14:41:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 14:41:24 -0000 Subject: [GHC] #15234: WARNING in hptSomeThingsBelowUs when using a source plugin In-Reply-To: <049.15722b69a2f4eb74d7898931a7d1b55a@haskell.org> References: <049.15722b69a2f4eb74d7898931a7d1b55a@haskell.org> Message-ID: <064.f46161e9d986e0c069c7a67d412c012c@haskell.org> #15234: WARNING in hptSomeThingsBelowUs when using a source plugin -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | SourcePlugins, plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by darchon): The attached patch, when applied on top of the GHC 8.6 branch, fixes both the warnings and the errors for me. I'll see how it fares on master and supply a phab patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 14:44:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 14:44:51 -0000 Subject: [GHC] #15234: WARNING in hptSomeThingsBelowUs when using a source plugin In-Reply-To: <049.15722b69a2f4eb74d7898931a7d1b55a@haskell.org> References: <049.15722b69a2f4eb74d7898931a7d1b55a@haskell.org> Message-ID: <064.5a535a5a1dd6957973a26c4a34a674c2@haskell.org> #15234: WARNING in hptSomeThingsBelowUs when using a source plugin -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | SourcePlugins, plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by darchon): * milestone: 8.8.1 => 8.6.1 Comment: Given that I simply cannot build my packages because of this bug I hope there's room to include the patch into 8.6 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 14:47:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 14:47:57 -0000 Subject: [GHC] #15234: WARNING in hptSomeThingsBelowUs when using a source plugin In-Reply-To: <049.15722b69a2f4eb74d7898931a7d1b55a@haskell.org> References: <049.15722b69a2f4eb74d7898931a7d1b55a@haskell.org> Message-ID: <064.5f8e2749899bdc7a98d4fcfa2f0e236a@haskell.org> #15234: WARNING in hptSomeThingsBelowUs when using a source plugin -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | SourcePlugins, plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * priority: normal => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 14:57:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 14:57:41 -0000 Subject: [GHC] #15234: WARNING in hptSomeThingsBelowUs when using a source plugin In-Reply-To: <049.15722b69a2f4eb74d7898931a7d1b55a@haskell.org> References: <049.15722b69a2f4eb74d7898931a7d1b55a@haskell.org> Message-ID: <064.23cc6c5da0dac555ee4e8bed4c3e96ad@haskell.org> #15234: WARNING in hptSomeThingsBelowUs when using a source plugin -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | SourcePlugins, plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4937 Wiki Page: | -------------------------------------+------------------------------------- Changes (by darchon): * differential: => Phab:D4937 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 16:11:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 16:11:55 -0000 Subject: [GHC] #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints In-Reply-To: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> References: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> Message-ID: <059.e09cfb8192fc18c2d83f296e4dd48cc1@haskell.org> #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: quantified- invalid program | constraints/T15316 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mniip): Replying to [comment:9 simonpj]: > OK, so now you need `UndecidableInstances` to have bad quantified constraints, just as the original proposal said. Doesn't `UndecidableInstances` imply the typechecking might not terminate, as opposed to a finite typechecking process resulting in a program nonterminating due to poor case of context elaboration? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 16:35:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 16:35:22 -0000 Subject: [GHC] #15345: Duplication between `CoreSubst` and `SimplEnv` is very unfortunate Message-ID: <049.83412aee209f6050ef82852307b4fd66@haskell.org> #15345: Duplication between `CoreSubst` and `SimplEnv` is very unfortunate -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There are lots of very similar functions in `SimplEnv` and `CoreSubst`. For example, in `SimpleEnv` there is a function `substIdType` and likewise in `CoreSubst` but they are different to each other. There is also a `substIdBndr` function in both modules but the one in `SimplEnv` calls `SimpleEnv.substIdType`, the one in `CoreSubst` doesn't call `CoreSubst.substIdType` but has its own inlined version. This means there's at least three different versions of `substIdType` floating around. The correctness of this function is crucial so it would be better not to duplicate it. Can we remove this duplication? Help me Simon! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 16:56:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 16:56:01 -0000 Subject: [GHC] #15231: UndecidableInstances validity checking is wrong in the presence of QuantifiedConstraints In-Reply-To: <050.e69160ac4e3631edefda13f39672a247@haskell.org> References: <050.e69160ac4e3631edefda13f39672a247@haskell.org> Message-ID: <065.8e04d91b1ff4fddf8598ac0c8e0e0973@haskell.org> #15231: UndecidableInstances validity checking is wrong in the presence of QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: fixed | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: quantified- valid program | constraints/T15231 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4819 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => quantified-constraints/T15231 * status: patch => closed * resolution: => fixed * milestone: 8.8.1 => 8.6.1 Comment: Actually, this is //in// GHC 8.6, so this is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 16:57:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 16:57:32 -0000 Subject: [GHC] #15235: GHCi's claim of infixr 0 (->) is a lie In-Reply-To: <050.1dea13c2dffcf4fb3726d468418c6455@haskell.org> References: <050.1dea13c2dffcf4fb3726d468418c6455@haskell.org> Message-ID: <065.2fb24875b8b77fabcc4f3de59b8afd47@haskell.org> #15235: GHCi's claim of infixr 0 (->) is a lie -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15236 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch Comment: See https://github.com/ghc/ghc/pull/158 for a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 19:34:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 19:34:20 -0000 Subject: [GHC] #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression Message-ID: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program typechecks on GHC 8.6.1-alpha1: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE EmptyCase #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module SGenerics where import Data.Kind import Data.Type.Equality import Data.Void ----- -- singletons machinery ----- data family Sing :: forall k. k -> Type data instance Sing :: () -> Type where STuple0 :: Sing '() type Refuted a = a -> Void data Decision a = Proved a | Disproved (Refuted a) ----- -- A stripped down version of GHC.Generics ----- data U1 = MkU1 data instance Sing (z :: U1) where SMkU1 :: Sing MkU1 ----- class Generic (a :: Type) where type Rep a :: Type from :: a -> Rep a to :: Rep a -> a class PGeneric (a :: Type) where type PFrom (x :: a) :: Rep a type PTo (x :: Rep a) :: a class SGeneric k where sFrom :: forall (a :: k). Sing a -> Sing (PFrom a) sTo :: forall (a :: Rep k). Sing a -> Sing (PTo a :: k) sTof :: forall (a :: k). Sing a -> PTo (PFrom a) :~: a sFot :: forall (a :: Rep k). Sing a -> PFrom (PTo a :: k) :~: a ----- instance Generic () where type Rep () = U1 from () = MkU1 to MkU1 = () instance PGeneric () where type PFrom '() = MkU1 type PTo 'MkU1 = '() instance SGeneric () where sFrom STuple0 = SMkU1 sTo SMkU1 = STuple0 sTof STuple0 = Refl sFot SMkU1 = Refl ----- class SDecide k where -- | Compute a proof or disproof of equality, given two singletons. (%~) :: forall (a :: k) (b :: k). Sing a -> Sing b -> Decision (a :~: b) default (%~) :: forall (a :: k) (b :: k). (SGeneric k, SDecide (Rep k)) => Sing a -> Sing b -> Decision (a :~: b) s1 %~ s2 = case sFrom s1 %~ sFrom s2 of Proved (Refl :: PFrom a :~: PFrom b) -> let r :: PTo (PFrom a) :~: PTo (PFrom b) r = Refl sTof1 :: PTo (PFrom a) :~: a sTof1 = sTof s1 sTof2 :: PTo (PFrom b) :~: b sTof2 = sTof s2 in Proved (sym sTof1 `trans` r `trans` sTof2) Disproved contra -> Disproved (\Refl -> contra Refl) instance SDecide U1 where SMkU1 %~ SMkU1 = Proved Refl instance SDecide () }}} However, it throws a Core Lint error with `-dcore-lint`. The full error is absolutely massive, so I'll attach it separately. Here is the top-level bit: {{{ *** Core Lint errors : in result of Simplifier *** : warning: In the expression: From-type of Cast differs from type of enclosed expression From-type: U1 Type of enclosed expr: Rep () Actual enclosed expr: PFrom a_a1Fm Coercion used in cast: Sym (D:R:Rep()[0]) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 19:35:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 19:35:34 -0000 Subject: [GHC] #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression In-Reply-To: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> References: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> Message-ID: <065.5405c163ebdde787d4e76f4a83ca8c29@haskell.org> #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "core-lint-error.txt" added. -dcore-lint error output -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 19:37:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 19:37:14 -0000 Subject: [GHC] #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression In-Reply-To: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> References: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> Message-ID: <065.5c177b6959d8a22450b484a39eef7264@haskell.org> #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): That being said, `Rep ()` should be equivalent to `U1`, so I don't understand why the Core Lint error happens in the first place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 20:28:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 20:28:32 -0000 Subject: [GHC] #15330: Error message prints invisible kind arguments in a visible matter In-Reply-To: <050.7a0d11dfbc8ef3463c27a79c9bdf89a1@haskell.org> References: <050.7a0d11dfbc8ef3463c27a79c9bdf89a1@haskell.org> Message-ID: <065.20747d4aac262a3d25e853694aaa78a2@haskell.org> #15330: Error message prints invisible kind arguments in a visible matter -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4938 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4938 Comment: I quite like Simon's suggestion of reusing `IfaceTcArgs` (renaming it to `IfaceAppArgs`), so I implemented just that in Phab:D4938. In particular, I decided not to mess with any of this `@` or `VisDep` stuff for now—we can leave that in a future patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 21:19:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 21:19:16 -0000 Subject: [GHC] #15347: QuantifiedConstraints: Implication constraints with type families don't work Message-ID: <049.446b77184844bcadda01810c8c61d990@haskell.org> #15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This may be related to #14860, but I think it's different. The following code fails to compile: {{{#!hs {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE ConstraintKinds #-} import Prelude() import Data.Kind data Dict c = c => Dict type family F a :: Constraint foo :: forall a b. (a => F b, a) => Dict (F b) foo = Dict }}} {{{ • Could not deduce: F b arising from a use of ‘Dict’ from the context: (a => F b, a) }}} Yet the following all do compile: {{{#!hs bar :: forall a. F a => Dict (F a) bar = Dict baz :: forall a b. (a => b, a) => Dict b baz = Dict qux :: forall a b c. (a => c, a, c ~ F b) => Dict (F b) qux = Dict }}} It seems that a wanted `F b` can be solved with a given `F b`, but not with a given `a => F b`, which is bizarre. The fact that `qux` still works is also strange, as it means that you get a different result if you first simplify by substituting `c = F b`. As a more practical example, the following similarly fails to compile, due to the `Cod f` type family: {{{#!hs -- in addition to the above extensions {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} class Ob p a class (forall a. Ob (Dom f) a => Ob (Cod f) (f a)) => Functor f where type Dom f type Cod f liftOb :: forall f a. (Functor f, Ob (Dom f) a) => Dict (Ob (Cod f) (f a)) liftOb = Dict }}} While a version which uses fundeps instead does compile: {{{#!hs class (forall a. Ob dom a => Ob cod (f a)) => Functor dom cod f | f -> dom cod liftOb :: forall f a dom cod. (Functor dom cod f, Ob dom a) => Dict (Ob cod (f a)) liftOb = Dict }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 21:43:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 21:43:15 -0000 Subject: [GHC] #15347: QuantifiedConstraints: Implication constraints with type families don't work In-Reply-To: <049.446b77184844bcadda01810c8c61d990@haskell.org> References: <049.446b77184844bcadda01810c8c61d990@haskell.org> Message-ID: <064.ec80a27d9baf02558c269e45c6d7d2c5@haskell.org> #15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > This may be related to #14860, but I think it's different. > > The following code fails to compile: > > {{{#!hs > {-# LANGUAGE QuantifiedConstraints #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE AllowAmbiguousTypes #-} > {-# LANGUAGE RankNTypes #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE ConstraintKinds #-} > > import Prelude() > import Data.Kind > > data Dict c = c => Dict > > type family F a :: Constraint > > foo :: forall a b. (a => F b, a) => Dict (F b) > foo = Dict > }}} > > {{{ > • Could not deduce: F b arising from a use of ‘Dict’ > from the context: (a => F b, a) > }}} > > Yet the following all do compile: > > {{{#!hs > bar :: forall a. F a => Dict (F a) > bar = Dict > > baz :: forall a b. (a => b, a) => Dict b > baz = Dict > > qux :: forall a b c. (a => c, a, c ~ F b) => Dict (F b) > qux = Dict > }}} > > It seems that a wanted `F b` can be solved with a given `F b`, but not > with a given `a => F b`, which is bizarre. The fact that `qux` still > works is also strange, as it means that you get a different result if you > first simplify by substituting `c = F b`. > > As a more practical example, the following similarly fails to compile, > due to the `Cod f` type family: > > {{{#!hs > -- in addition to the above extensions > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE FunctionalDependencies #-} > > class Ob p a > > class (forall a. Ob (Dom f) a => Ob (Cod f) (f a)) => Functor f where > type Dom f > type Cod f > > liftOb :: forall f a. (Functor f, Ob (Dom f) a) => Dict (Ob (Cod f) (f > a)) > liftOb = Dict > }}} > > While a version which uses fundeps instead does compile: > > {{{#!hs > class (forall a. Ob dom a => Ob cod (f a)) => Functor dom cod f | f -> > dom cod > > liftOb :: forall f a dom cod. (Functor dom cod f, Ob dom a) => Dict (Ob > cod (f a)) > liftOb = Dict > }}} New description: This may be related to #14860, but I think it's different. The following code fails to compile: {{{#!hs {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE ConstraintKinds #-} import Prelude() import Data.Kind data Dict c = c => Dict type family F a :: Constraint foo :: forall a b. (a => F b, a) => Dict (F b) foo = Dict }}} {{{ • Could not deduce: F b arising from a use of ‘Dict’ from the context: (a => F b, a) }}} Yet the following all do compile: {{{#!hs bar :: forall a. F a => Dict (F a) bar = Dict baz :: forall a b. (a => b, a) => Dict b baz = Dict qux :: forall a b c. (a => c, a, c ~ F b) => Dict (F b) qux = Dict }}} It seems that a wanted `F b` can be solved with a given `F b`, but not with a given `a => F b`, which is bizarre. The fact that `qux` still works is also strange, as it means that you get a different result if you first simplify by substituting `c = F b`. As a more practical example, the following similarly fails to compile, due to the `Cod f` type family: {{{#!hs -- in addition to the above extensions {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} class Ob p a class (forall a. Ob (Dom f) a => Ob (Cod f) (f a)) => Functor f where type Dom f type Cod f liftOb :: forall f a. (Functor f, Ob (Dom f) a) => Dict (Ob (Cod f) (f a)) liftOb = Dict }}} While a version which uses fundeps instead does compile: {{{#!hs class (forall a. Ob dom a => Ob cod (f a)) => Functor dom cod f | f -> dom cod liftOb :: forall f a dom cod. (Functor dom cod f, Ob dom a) => Dict (Ob cod (f a)) liftOb = Dict }}} -- Comment (by aaronvargo): Actually, the `Functor` example with type families can be fixed by replacing: {{{#!hs forall a. Ob (Dom f) a => Ob (Cod f) (f a) }}} with {{{#!hs forall a cod. (Ob (Dom f) a, cod ~ Cod f) => Ob cod (f a) }}} Perhaps the compiler could do this rewrite automatically? It rightly doesn't in the case of instance declarations, but perhaps it's fine for quantified constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 22:05:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 22:05:59 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.d476828026df734bf7f2ee8d7f2a6347@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by aaronvargo): * cc: aaronvargo (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 23:27:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 23:27:07 -0000 Subject: [GHC] #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression In-Reply-To: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> References: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> Message-ID: <065.aec8640b32ff86f03bfcb16da677e4fb@haskell.org> #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): Here's a smaller version: {{{ #!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeApplications #-} module SGenerics where import Data.Kind import Data.Proxy ----- type family Rep (a :: Type) :: Type type instance Rep () = () type family PFrom (x :: a) :: Rep a ----- class SDecide k where test :: forall (a :: k). Proxy a instance SDecide () where test = undefined test1 :: forall (a :: k). SDecide (Rep k) => Proxy a test1 = seq (test @_ @(PFrom a)) Proxy test2 :: forall (a :: ()). Proxy a test2 = test1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 5 23:28:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 05 Jul 2018 23:28:42 -0000 Subject: [GHC] #15347: QuantifiedConstraints: Implication constraints with type families don't work In-Reply-To: <049.446b77184844bcadda01810c8c61d990@haskell.org> References: <049.446b77184844bcadda01810c8c61d990@haskell.org> Message-ID: <064.bafe7bd0ff33faf5f4e6338e037543d7@haskell.org> #15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aaronvargo): So I guess what I want is for the given `a => F b` (in `foo`) to be replaced with the givens: {{{ a => x x ~ F b }}} (as in `qux`) and for the given {{{#!hs forall a. Ob (Dom f) a => Ob (Cod f) (f a) }}} to be replaced with: {{{#!hs forall a. Ob (Dom f) a => Ob x (f a) x ~ Cod f }}} or something like that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 02:30:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 02:30:36 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD Message-ID: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> #15348: Enable two-step allocator on FreeBSD ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: FreeBSD Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Currently the two-step allocator is disabled on FreeBSD as the `MEM_NORESERVE` macro is undefined. It seems that FreeBSD provided this macro until 2014, when it was [[https://reviews.freebsd.org/D848|removed]] as it wasn't implemented in the kernel. Regardless, Viktor Dukhovni reports empirical evidence on `ghc-devs` that just plain `mmap` does what we want. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 02:32:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 02:32:49 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.387bbb0e2cf4b5c37740c2b0cd0e682b@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4939 Comment: Could someone test Phab:D4939 on FreeBSD? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 03:52:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 03:52:38 -0000 Subject: [GHC] #15063: T3001-2 fails on i386 Linux In-Reply-To: <046.fa478fb40ce13bbb24172a958e864762@haskell.org> References: <046.fa478fb40ce13bbb24172a958e864762@haskell.org> Message-ID: <061.07c8e677f1d36654ef808b76b74c5974@haskell.org> #15063: T3001-2 fails on i386 Linux -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Profiling | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15087, #15165, | Differential Rev(s): Phab:D4928 #7836 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Why do you think CONSTR_NOCAF is invalid here? I'm afraid I can't recall my exact reasoning but I was under the impression that this was a static closure type. If you have observed these being heap allocated then I'm clearly mistaken. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 03:55:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 03:55:28 -0000 Subject: [GHC] #15336: ./System/IO.hs accidentally overridden when running ghci In-Reply-To: <044.ba3290f444f0e979b7add843365e09fb@haskell.org> References: <044.ba3290f444f0e979b7add843365e09fb@haskell.org> Message-ID: <059.9bf4fc25fd75180cb10fdd52154259f1@haskell.org> #15336: ./System/IO.hs accidentally overridden when running ghci -------------------------------------+------------------------------------- Reporter: luqui | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed this is quite unfortunate. I believe the cause is the Haskell- syntax `import`s that GHCi injects at the beginning of its execution (see `GHCi.UI.initInterpBuffering`). I suppose we'll need a more principled way to accomplish this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 05:39:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 05:39:59 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.4da6136e34b35c7c52fed23b39594eeb@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Comment (by vdukhovni): Specifically, one can reserve a contiguous address range with: {{{ heap = mmap(NULL, heapmax, PROT_NONE, MAP_GUARD, -1, 0); }}} and then incrementally populate segments of that range: {{{ mmap(base, len, PROT_READ|PROT_WRITE, MAP_ANON|MAP_PRIVATE|MAP_FIXED, -1, 0); }}} With `base == heap` for the initial block of pages, and then to the first address not yet mapped for subsequent increments. What we don't get is protection from overcommit OOM, unless the system is configured to disallow overcommit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 08:51:30 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 08:51:30 -0000 Subject: [GHC] #15345: Duplication between `CoreSubst` and `SimplEnv` is very unfortunate In-Reply-To: <049.83412aee209f6050ef82852307b4fd66@haskell.org> References: <049.83412aee209f6050ef82852307b4fd66@haskell.org> Message-ID: <064.f5b64bed4981decf7f7b752a89d037f9@haskell.org> #15345: Duplication between `CoreSubst` and `SimplEnv` is very unfortunate -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): And I found another function which is rather like `substIdBnd`, `CoreOpt.subst_opt_id_bndr`. I don't think there should be four functions doing this very similar task of applying a substitution to a binder. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 09:12:03 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 09:12:03 -0000 Subject: [GHC] #15336: ./System/IO.hs accidentally overridden when running ghci In-Reply-To: <044.ba3290f444f0e979b7add843365e09fb@haskell.org> References: <044.ba3290f444f0e979b7add843365e09fb@haskell.org> Message-ID: <059.a76ed1c621e6152a367b9353b5d7f2f8@haskell.org> #15336: ./System/IO.hs accidentally overridden when running ghci -------------------------------------+------------------------------------- Reporter: luqui | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Would using `PackageImports` in `initInterpBuffering` be sufficient to fix this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 09:16:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 09:16:48 -0000 Subject: [GHC] #15336: ./System/IO.hs accidentally overridden when running ghci In-Reply-To: <044.ba3290f444f0e979b7add843365e09fb@haskell.org> References: <044.ba3290f444f0e979b7add843365e09fb@haskell.org> Message-ID: <059.1f245f81d9cb2aaf92dd595968c21eaa@haskell.org> #15336: ./System/IO.hs accidentally overridden when running ghci -------------------------------------+------------------------------------- Reporter: luqui | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Isn't the principled solution to use `compileParsedExprRemote` and use `Orig` names for the identifiers? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 12:08:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 12:08:05 -0000 Subject: [GHC] #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression In-Reply-To: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> References: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> Message-ID: <065.f895e9f02f214ac1e4883c4baeba6dc6@haskell.org> #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thanks, monoidal. Your program also exhibits the same Core Lint error in GHC 8.4, unlike the original program. I think it's actually easier to see what goes wrong if you add a second method to `SDecide` so that there's not as many coercions cluttering up the `-dcore-lint` output: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeApplications #-} module SGenerics where import Data.Kind import Data.Proxy ----- type family Rep (a :: Type) :: Type type instance Rep () = () type family PFrom (x :: a) :: Rep a ----- class SDecide k where test :: forall (a :: k). Proxy a dummy :: k instance SDecide () where test = undefined dummy = undefined test1 :: forall (a :: k). SDecide (Rep k) => Proxy a test1 = seq (test @_ @(PFrom a)) Proxy test2 :: forall (a :: ()). Proxy a test2 = test1 }}} {{{ $ /opt/ghc/8.6.1/bin/ghci Bug.hs -dcore-lint -ddump-tc [1 of 1] Compiling SGenerics ( Bug.hs, interpreted ) TYPE SIGNATURES dummy :: forall k. SDecide k => k test :: forall k (a :: k). SDecide k => Proxy a test1 :: forall k (a :: k). SDecide (Rep k) => Proxy a test2 :: forall (a :: ()). Proxy a TYPE CONSTRUCTORS type family PFrom (x :: a) :: Rep a open type family Rep a :: * open class SDecide k where test :: forall (a :: k). Proxy a dummy :: k {-# MINIMAL test, dummy #-} COERCION AXIOMS axiom SGenerics.D:R:Rep() :: Rep () = () -- Defined at Bug.hs:15:15 INSTANCES instance SDecide () -- Defined at Bug.hs:25:10 FAMILY INSTANCES type instance Rep () Dependent modules: [] Dependent packages: [base-4.12.0.0, ghc-prim-0.5.3, integer-gmp-1.0.2.0] ==================== Typechecker ==================== *** Core Lint errors : in result of Simplifier *** Bug.hs:32:1: warning: [in body of lambda with binder a_a1UE :: ()] Kind application error in coercion ‘(Proxy (Sym (D:R:Rep()[0])) _P)_R’ Function kind = forall k. k -> * Arg kinds = [(Rep (), *), (a_a1Dx, ())] Fun: Rep () (a_a1Dx, ()) Bug.hs:32:1: warning: [in body of lambda with binder a_a1UE :: ()] From-type of Cast differs from type of enclosed expression From-type: () Type of enclosed expr: Rep () Actual enclosed expr: PFrom a_a1UE Coercion used in cast: Sym (D:R:Rep()[0]) *** Offending Program *** test2 :: forall (a :: ()). Proxy a [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 10 10}] test2 = \ (@ (a_a1UE :: ())) -> break<1>() break<0>() case ($ctest_a1UM @ (PFrom a_a1UE |> D:R:Rep()[0])) `cast` (Inst (forall (a :: Sym (D:R:Rep()[0])). (Proxy (Sym (D:R:Rep()[0])) _P)_R) (Coh _N (Sym (D:R:Rep()[0]))) :: Proxy (PFrom a_a1UE |> Sym (D:R:Rep()[0])) ~R# Proxy (PFrom a_a1UE |> D:R:Rep()[0])) of { Proxy -> Proxy @ () @ a_a1UE } }}} Here, we can see exactly what goes wrong: * In the definition of `test2, we have the casted type `Proxy (PFrom a_a1UE |> Sym (D:R:Rep()[0]))`, where `a_a1UE :: ()`. * As can be seen in the `-ddump-tc` output, `D:R:Rep()[0] :: Rep () ~# ()`. Therefore, `Sym (D:R:Rep()[0]) :: () ~# Rep ()`. * However, `PFrom a_a1UE :: Rep ()`, so the coercion `Sym (D:R:Rep()[0])` is oriented the wrong way! ----- There's another tiny buglet here in that Core Lint is calling `PFrom a_a1UE` an exclosed "expression", but it's actually a type. This is probably worth fixing separately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 12:58:41 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 12:58:41 -0000 Subject: [GHC] #14083: ? In-Reply-To: <044.25fd060c4f1d487121c29dd02e554eab@haskell.org> References: <044.25fd060c4f1d487121c29dd02e554eab@haskell.org> Message-ID: <059.19cf4d037b7fe5166cf5c21e3e8d6c82@haskell.org> #14083: ? -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: Closing as duplicate of #14004. #9334 is also relevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 12:58:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 12:58:55 -0000 Subject: [GHC] #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression In-Reply-To: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> References: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> Message-ID: <065.e9b577bfdb20c154c3cc6ca8ab877515@haskell.org> #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Phab:D4940 changes the Core Lint error for kind coercions, as suggested in the bottom of comment:3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 13:08:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 13:08:28 -0000 Subject: [GHC] #15336: ./System/IO.hs accidentally overridden when running ghci In-Reply-To: <044.ba3290f444f0e979b7add843365e09fb@haskell.org> References: <044.ba3290f444f0e979b7add843365e09fb@haskell.org> Message-ID: <059.ccc1fdba52c242289717677a53088dbc@haskell.org> #15336: ./System/IO.hs accidentally overridden when running ghci -------------------------------------+------------------------------------- Reporter: luqui | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): Fixing this will likely also fix #12509. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 14:56:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 14:56:58 -0000 Subject: [GHC] #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression In-Reply-To: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> References: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> Message-ID: <065.8b2737e657f76d161768760377ac63f2@haskell.org> #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"18cedbb55c7a0bdbfade4d28d3bb8927277df8d8/ghc" 18cedbb5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="18cedbb55c7a0bdbfade4d28d3bb8927277df8d8" Make a variant of mkCastErr for kind coercions Summary: I discovered when debugging #15346 that the Core Lint error message for ill typed casts always mentions types of enclosed //expressions//, even if the thing being casted is actually a type. This generalizes `mkCastErr` a bit to allow it to give the proper labelling for kind coercions. Test Plan: Run on failing program in #15346, read the Core Lint error Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4940 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 15:07:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 15:07:26 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.1b55a190f8ffa94d96a31dc464d21d77@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | roles/should_compile/Roles2 Blocked By: | Blocking: Related Tickets: #9164 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dominic): {{{ *Numeric.Sundials.CVode.ODE> (coerce ((V.fromList [1,2]) :: Vector CInt)) :: Vector Int [8589934593,4426664329] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 15:08:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 15:08:38 -0000 Subject: [GHC] #15213: 32 bit Haddock runs out of memory compiling 32 bit GHC In-Reply-To: <044.953b3633442fb5d6beadb7e79e6f44ca@haskell.org> References: <044.953b3633442fb5d6beadb7e79e6f44ca@haskell.org> Message-ID: <059.7e66c3ad7e16b19c79a3ad2623f00ce2@haskell.org> #15213: 32 bit Haddock runs out of memory compiling 32 bit GHC ----------------------------------------+------------------------------ Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by bgamari): Indeed I am also seeing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 15:11:01 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 15:11:01 -0000 Subject: [GHC] #14025: Object file of a dependent c-file is put in wrong directory when this dependent is specified with a path In-Reply-To: <046.48759c75ff80de33ebc22ad9a6eaaf3e@haskell.org> References: <046.48759c75ff80de33ebc22ad9a6eaaf3e@haskell.org> Message-ID: <061.b28ac16589c2d9fb8cc53071bc1b0a19@haskell.org> #14025: Object file of a dependent c-file is put in wrong directory when this dependent is specified with a path -------------------------------------+------------------------------------- Reporter: literon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * testcase: driver/T14025, driver/T14025a => * status: patch => new * differential: Phab: D4930 => * owner: RolandSenn => (none) Comment: Patch in Phab D4930 abandoned due to issues with Cabal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 15:14:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 15:14:15 -0000 Subject: [GHC] #14025: Object file is put in wrong directory when any source has absolute path (was: Object file of a dependent c-file is put in wrong directory when this dependent is specified with a path) In-Reply-To: <046.48759c75ff80de33ebc22ad9a6eaaf3e@haskell.org> References: <046.48759c75ff80de33ebc22ad9a6eaaf3e@haskell.org> Message-ID: <061.2700c16cc10e4b75cb31b2658eb8a381@haskell.org> #14025: Object file is put in wrong directory when any source has absolute path -------------------------------------+------------------------------------- Reporter: literon | Owner: RolandSenn Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn Comment: I'll develop a new solution,just fixing the issue with the absolute path. I'll not change the difference with the use of subdirectories in odir between *.hs and *.c source files. Using again original ticket title. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 15:16:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 15:16:50 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.e54835f4021c5b9b1a406a099578e9eb@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): vdukhovni, I've updated Phab:D4939 to account for your comment. Do you suppose you could test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 15:46:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 15:46:35 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.e6078237975690f3bc8dd838f0b6ec68@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Comment (by vdukhovni): I can try to test, but the patch is not ready yet. FreeBSD does not support combining `MAP_GUARD` with other flags such as `MAP_ANON` or `MAP_PRIVATE`, it must stand alone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 15:56:17 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 15:56:17 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.ea24bba6c32915b585b331c1530c27ed@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Comment (by vdukhovni): From `kern_mmap()` in `/usr/src/sys/vm/vm_mmap.c`: {{{ if ((flags & MAP_GUARD) != 0 && (prot != PROT_NONE || fd != -1 || pos != 0 || (flags & (MAP_SHARED | MAP_PRIVATE | MAP_PREFAULT | MAP_PREFAULT_READ | MAP_ANON | MAP_STACK)) != 0)) return (EINVAL); }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 18:05:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 18:05:32 -0000 Subject: [GHC] #15349: fixST is a bit wrong Message-ID: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> #15349: fixST is a bit wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.5 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Lazy blackholing lets some `ST` calculations complete that shouldn't. {{{#!hs import Control.Monad.ST.Strict import Control.Monad.Fix import Data.STRef foo :: ST s Int foo = do ref <- newSTRef True mfix $ \res -> do x <- readSTRef ref if x then do writeSTRef ref False return $! (res + 5) else return 10 main = print $ runST foo }}} When this is compiled with `-O -feager-blackholing`, it produces a `<>` exception as expected. When it's compiled with `-O0` or with `-fno-eager-blackholing`, it prints `15`. Should we reimplement `fixST` to do something like what `fixIO` does? Or should we consider this sometimes-lost bottom tolerable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 18:08:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 18:08:46 -0000 Subject: [GHC] #14470: CircleCI: Detect number of processors In-Reply-To: <046.012116c89dd22a1fbfc06a0f6d331f82@haskell.org> References: <046.012116c89dd22a1fbfc06a0f6d331f82@haskell.org> Message-ID: <061.7ce09522dbd38fa94c3931b13a1d111e@haskell.org> #14470: CircleCI: Detect number of processors -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Continuous | Version: 8.2.1 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4897 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"de95bf40ee0af0e7da4cb6cc4e0ad33694234bb9/ghc" de95bf4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="de95bf40ee0af0e7da4cb6cc4e0ad33694234bb9" circleci: Detect core count Test Plan: Try `./validate`, CircleCI build; make sure core count detection works in both cases. Reviewers: alpmestan Reviewed By: alpmestan Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14470 Differential Revision: https://phabricator.haskell.org/D4897 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 18:09:18 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 18:09:18 -0000 Subject: [GHC] #15342: Mark -XAutoDeriveTypeable as deprecated In-Reply-To: <047.58435d34138b96a2bf714e154c899347@haskell.org> References: <047.58435d34138b96a2bf714e154c899347@haskell.org> Message-ID: <062.c9f26f217b79299c6d596fcd6eabdb1b@haskell.org> #15342: Mark -XAutoDeriveTypeable as deprecated -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4933 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f59332f92b30306675da22150de092eeebbf55f3/ghc" f59332f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f59332f92b30306675da22150de092eeebbf55f3" Mark AutoDeriveTypeable as deprecated Test Plan: validate Reviewers: bgamari, alpmestan Reviewed By: alpmestan Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15342 Differential Revision: https://phabricator.haskell.org/D4933 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 18:09:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 18:09:32 -0000 Subject: [GHC] #9693: Reloading GHCi with Template Haskell names can panic GHC In-Reply-To: <043.739fde51b47ea4696baf564b0f9ae27e@haskell.org> References: <043.739fde51b47ea4696baf564b0f9ae27e@haskell.org> Message-ID: <058.8e7147442454e9bbc60c5738a304b311@haskell.org> #9693: Reloading GHCi with Template Haskell names can panic GHC -------------------------------------+------------------------------------- Reporter: maxs | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fbe162f58caa31df445d9edbf0b0919810687011/ghc" fbe162f5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fbe162f58caa31df445d9edbf0b0919810687011" Add a broken test for lingering state from TH unique names #9693 The stderr output is ``` Loading with T9693_initial.hs T9693_main.hs:4:1: Same exact name in multiple name-spaces: type constructor or class ‘X’, declared at: T9693_main.hs:4:1 data constructor ‘X’, declared at: T9693_main.hs:4:1 Probable cause: you bound a unique Template Haskell name (NameU), perhaps via newName, in different name-spaces. If that's it, then -ddump-splices might be useful Reloading with T9693_modified.hs T9693_main.hs:1:1: Data constructor ‘X’ used as a type constructor ``` The strange thing is that the modified version uses (mkName "X"), which should be fine for simultaneous use in both a data constructor and type constructor. Indeed, on a fresh load, the modified version works fine. So there is some sort of state left over from the prior load when (newName "X") was used. Test Plan: testsuite/tests/th/T9693.script Reviewers: bgamari, sighingnow, RyanGlScott Reviewed By: sighingnow, RyanGlScott Subscribers: RyanGlScott, sighingnow, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4926 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 18:10:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 18:10:02 -0000 Subject: [GHC] #15301: Regression in Natural desugaring In-Reply-To: <045.90c91b42b96252b83bfe60ec247894bd@haskell.org> References: <045.90c91b42b96252b83bfe60ec247894bd@haskell.org> Message-ID: <060.f899d758b1faa09486cc5452f519862c@haskell.org> #15301: Regression in Natural desugaring -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4885 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"987b5e7fbacd8afd2c8463c16eac28cd68f43155/ghc" 987b5e7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="987b5e7fbacd8afd2c8463c16eac28cd68f43155" Fix for built-in Natural literals desugaring The recent patch "Built-in Natural literals in Core" (https://phabricator.haskell.org/rGHCfe770c211631e7b4c9b0b1e88ef9b6046c6 585ef) introduced a regression when desugaring large numbers. This patch fixes it and adds a regression test. Reviewers: hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15301 Differential Revision: https://phabricator.haskell.org/D4885 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 18:10:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 18:10:20 -0000 Subject: [GHC] #15053: Compiler panic on invalid syntax (unterminated pragma) In-Reply-To: <047.d617a7e8bd5e9dac7c56bae30af4b445@haskell.org> References: <047.d617a7e8bd5e9dac7c56bae30af4b445@haskell.org> Message-ID: <062.f67e2f2b34bc4d223d2623fdafb5c74b@haskell.org> #15053: Compiler panic on invalid syntax (unterminated pragma) -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4883 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f03f0d61bebe287e0df0254c175eb2f183d697aa/ghc" f03f0d61/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f03f0d61bebe287e0df0254c175eb2f183d697aa" testsuite: Add test for #15053 Reviewers: Phyx Reviewed By: Phyx Subscribers: Phyx, rwbarton, thomie, carter GHC Trac Issues: #15053 Differential Revision: https://phabricator.haskell.org/D4883 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 18:10:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 18:10:38 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.a352d4562783b7476625f5b845130583@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8736715857d08cc1f88d766c257b39c05df20639/ghc" 87367158/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8736715857d08cc1f88d766c257b39c05df20639" rts: Enable two-step allocator on FreeBSD Previously we would prevent any operating system not providing the MEM_NORESERVE flag from using the two-step allocator. Afterall, Linux will reserve swap-space for a mapping unless this flag is given, which is most certainly not what we want. However, it seems that FreeBSD provides the reservation-only mapping behavior that we expect despite not providing the MEM_NORESERVE macro. In fact, it provided the macro until 2014, when it was removed on account of not being implemented in the kernel. However, empirical evidence suggests that just plain mmap does what we want. Reviewers: erikd, simonmar Subscribers: rwbarton, thomie, erikd, carter GHC Trac Issues: #15348 Differential Revision: https://phabricator.haskell.org/D4939 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 18:11:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 18:11:44 -0000 Subject: [GHC] #15301: Regression in Natural desugaring In-Reply-To: <045.90c91b42b96252b83bfe60ec247894bd@haskell.org> References: <045.90c91b42b96252b83bfe60ec247894bd@haskell.org> Message-ID: <060.292af1fd32fff79c3eef5e9fa2347b2c@haskell.org> #15301: Regression in Natural desugaring -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4885 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 18:13:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 18:13:15 -0000 Subject: [GHC] #15342: Mark -XAutoDeriveTypeable as deprecated In-Reply-To: <047.58435d34138b96a2bf714e154c899347@haskell.org> References: <047.58435d34138b96a2bf714e154c899347@haskell.org> Message-ID: <062.fa5376d8c4e2fb9326cf73d1434e6a7f@haskell.org> #15342: Mark -XAutoDeriveTypeable as deprecated -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4933 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 18:13:37 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 18:13:37 -0000 Subject: [GHC] #14470: CircleCI: Detect number of processors In-Reply-To: <046.012116c89dd22a1fbfc06a0f6d331f82@haskell.org> References: <046.012116c89dd22a1fbfc06a0f6d331f82@haskell.org> Message-ID: <061.cc216fc127020c359632a58b2fc55b62@haskell.org> #14470: CircleCI: Detect number of processors -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Continuous | Version: 8.2.1 Integration | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4897 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 18:14:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 18:14:15 -0000 Subject: [GHC] #12073: Missing instance of MonadFix for Q In-Reply-To: <046.40bbc19dbb6e691647fd4beba8f8097c@haskell.org> References: <046.40bbc19dbb6e691647fd4beba8f8097c@haskell.org> Message-ID: <061.cbabd646418909637bc4f340f5568cfe@haskell.org> #12073: Missing instance of MonadFix for Q -------------------------------------+------------------------------------- Reporter: jophish | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | 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 dfeuer): One change: `unsafeInterleaveIO` is now safer than necessary, and this should instead use `unsafeDupableInterleaveIO`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 18:20:41 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 18:20:41 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.e97c6503999e1cc1a2a5fa104ce4e755@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Changes (by vdukhovni): * Attachment "patch-rts__posix__OSMem.c" added. OSMem.c patch with MAP_GUARD used alone rather than in combination with MAP_ANON|MAP_PRIVATE -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 18:21:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 18:21:47 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.06f15e11a3e7886b0441f356091c96d8@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Comment (by vdukhovni): I modified the proposed OSMem.c patch as attached ,rebuilt GHC-8.4.3 and am now running my DANE scanner (runs for ~8 hours, using around 300MB of VM space, and doing a total of around 4TB of allocations). So far so good. And it did allocate a 1TB hole in its address space, partly replaced with actually allocated pages. Because this is a reserved hole, and not a mapping, the reported virtual size is still modest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 19:15:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 19:15:10 -0000 Subject: [GHC] #9672: Error message too long (full case statement printed) In-Reply-To: <051.99a860bf6093bb48bfa9c98f3e2d6cd2@haskell.org> References: <051.99a860bf6093bb48bfa9c98f3e2d6cd2@haskell.org> Message-ID: <066.9625aa8acd7cc5b6fc32b9ab3490e949@haskell.org> #9672: Error message too long (full case statement printed) -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nadine): Replying to [comment:7 bgamari]: > Nadine, you may also be interested in this one. Thank you Ben! I'll go ahead and claim this one too then :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 19:15:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 19:15:50 -0000 Subject: [GHC] #9672: Error message too long (full case statement printed) In-Reply-To: <051.99a860bf6093bb48bfa9c98f3e2d6cd2@haskell.org> References: <051.99a860bf6093bb48bfa9c98f3e2d6cd2@haskell.org> Message-ID: <066.78383de1d262eb608f88a86509b11851@haskell.org> #9672: Error message too long (full case statement printed) -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: nadine Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nadine): * owner: (none) => nadine -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 21:29:42 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 21:29:42 -0000 Subject: [GHC] #15347: QuantifiedConstraints: Implication constraints with type families don't work In-Reply-To: <049.446b77184844bcadda01810c8c61d990@haskell.org> References: <049.446b77184844bcadda01810c8c61d990@haskell.org> Message-ID: <064.fb036ad2e11232ee08cef997deaa5175@haskell.org> #15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I don't see how this is different from #14860. It looks the same to me. But I think `(x ~ F b, forall a. a => x)` and `forall a. a => F b` really are different. It's all about shadowing. The first casts a much bigger shadow, one whose shape can be specified. The second's shadow is too oddly shaped to be predictable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 21:41:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 21:41:13 -0000 Subject: [GHC] #15347: QuantifiedConstraints: Implication constraints with type families don't work In-Reply-To: <049.446b77184844bcadda01810c8c61d990@haskell.org> References: <049.446b77184844bcadda01810c8c61d990@haskell.org> Message-ID: <064.fbd046a752fa0aad555af8f5e4a8ae44@haskell.org> #15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aaronvargo): Sorry, ignore comment:1, which was stupid. This situation is different from #14860 in that the quantified variable doesn't appear in the application of the type family. As a result, it should be possible to pull the application out, replacing it with a variable, as I've described in comment:2. That is, the application `F b` can just be treated as if it's a variable `c`, allowing it to be matched. Then everything seems to work, as demonstrated by both `qux` and the example which uses fundeps. Not doing this seems to undermine the usefulness of type families as an alternative to fundeps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 21:53:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 21:53:25 -0000 Subject: [GHC] #15347: QuantifiedConstraints: Implication constraints with type families don't work In-Reply-To: <049.446b77184844bcadda01810c8c61d990@haskell.org> References: <049.446b77184844bcadda01810c8c61d990@haskell.org> Message-ID: <064.5b8a40669d6644cc9cd2ca0dc9664944@haskell.org> #15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aaronvargo): To clarify, this also compiles: {{{#!hs class Functor (f :: * -> *) where type Dom f type Cod f liftOb :: ( Functor f, cod ~ Cod f , forall a. Ob (Dom f) a => Ob cod (f a) , Ob (Dom f) a ) => Dict (Ob cod (f a)) liftOb = Dict }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 22:01:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 22:01:36 -0000 Subject: [GHC] #15347: QuantifiedConstraints: Implication constraints with type families don't work In-Reply-To: <049.446b77184844bcadda01810c8c61d990@haskell.org> References: <049.446b77184844bcadda01810c8c61d990@haskell.org> Message-ID: <064.98777604ba1a55de62d593fbb7965ed1@haskell.org> #15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): OK. I see how this is different than #14860. But I still claim that GHC should not do this rewriting, because having a variable in a quantified constraint head casts a longer shadow than having a type family. And it's all about that shadow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 22:05:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 22:05:52 -0000 Subject: [GHC] #15347: QuantifiedConstraints: Implication constraints with type families don't work In-Reply-To: <049.446b77184844bcadda01810c8c61d990@haskell.org> References: <049.446b77184844bcadda01810c8c61d990@haskell.org> Message-ID: <064.4f4547338d9929c79b26269d154828cc@haskell.org> #15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aaronvargo): Not if the variable is a skolem (is that the right terminology?), which is what I intended. I should have been clearer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 22:15:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 22:15:50 -0000 Subject: [GHC] #15347: QuantifiedConstraints: Implication constraints with type families don't work In-Reply-To: <049.446b77184844bcadda01810c8c61d990@haskell.org> References: <049.446b77184844bcadda01810c8c61d990@haskell.org> Message-ID: <064.de444b18c8a7136e651a3848007cdf79@haskell.org> #15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aaronvargo): This demonstrates there's no shadowing (it compiles): {{{#!hs liftOb :: forall f cod other a. ( Functor f, cod ~ Cod f, Ob (Dom f) a , forall a. Ob (Dom f) a => Ob cod (f a) , forall a. Ob (Dom f) a => Ob other (f a) ) => Dict (Ob cod (f a), Ob other (f a)) liftOb = Dict }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 22:20:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 22:20:47 -0000 Subject: [GHC] #15347: QuantifiedConstraints: Implication constraints with type families don't work In-Reply-To: <049.446b77184844bcadda01810c8c61d990@haskell.org> References: <049.446b77184844bcadda01810c8c61d990@haskell.org> Message-ID: <064.802ef743bcf189f788aee21ac8620e96@haskell.org> #15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aaronvargo): Or to give the simpler example, this does too: {{{#!hs wibble :: forall a b fb c. (a, fb ~ F b, a => fb, a => c) => Dict (F b, c) wibble = Dict }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 22:45:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 22:45:35 -0000 Subject: [GHC] #15347: QuantifiedConstraints: Implication constraints with type families don't work In-Reply-To: <049.446b77184844bcadda01810c8c61d990@haskell.org> References: <049.446b77184844bcadda01810c8c61d990@haskell.org> Message-ID: <064.759df89026ea87d1cead59e91b545e3d@haskell.org> #15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Consider this: {{{ type family F a type instance F Int = Bool instance Eq a => Eq (F a) where ... }}} Should we allow this? Obviously not. It's like allowing {{{ map f (xs ++ ys) = map f xs ++ map f ys map f [] = [] }}} where we have a function call in the pattern match. All manner of overlaps a chaos would result. So generally GHC does not allow type family calls in the head of an instance declaration. And I've made that same rule apply to quantified constraints, which are really just local instance declarations. But, you say, how are these two different? {{{ foo :: forall a b. (a => F b, a) => Dict (F b) qux :: forall a b c. (a => c, c ~ F b, a) => Dict (F b) }}} Very different, I say! Suppose that quantified constraint had looked like this {{ foo :: forall a b. (forall t. a => F t b, ...) => Dict (F b) }} Notice that the locally-quantified `t` is one of the arguments to `F`. Now, all the bad things could happen. What is different about your example is that '''the function call is independent of any of the forall'd variables of the quantified constraint'''. You expressed that by floating it out of the quantified constraint with you `c ~ F b`. And because it is independent of the forall'd variables, it is really constant so far as the instance is concerned, and doesn't lead to problems. Here's another variant: {{{ foo :: forall b. (forall t. C b t => C (F b) [t], ...) => Dict (F b) }}} Now the head of the quantified constraint does mention the forall'd `t`, but the call to `F` does not, so we can float thus: {{{ foo :: forall b c. (c ~ F b, forall t. C b t => C c [t], ...) => Dict (F b) }}} This directly expresses the fact that the first parameter to `C` in the head of the quantified constraint is independent of `t`. Now, you want this floating business to happen automatically, but I think it is much too complicated to do behind the scenes. If that's what you want, you can say it. I would be reluctant to introduce a significant (and unprecedented) implicit translation, based on a free-variable analysis, without plenty of evidence that it was going to have major benefit for a significant constituency. I don't think we are close to that point yet. But it ''is'' a nice observation that, by expressing the independence with an equality constraint, you can say just what you mean, and get just what you want. (I doubt that fundeps would be any help here.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 22:45:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 22:45:58 -0000 Subject: [GHC] #9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.dd790a69d3f2e7f26db936cccc8041f5@haskell.org> #9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Roles, Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T9123{,a} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I was thinking it would all happen in the "generate constraints" step. But now that I try to write the algorithm down, it does seem rather complex. Maybe I was wrong here. Close as wontfix? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 23:01:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 23:01:39 -0000 Subject: [GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin In-Reply-To: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> References: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> Message-ID: <062.1d03841c3501432297a475692a1d6792@haskell.org> #15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | typeable,knownnat Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10348 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * cc: dotwani@… (added) Comment: I really like the idea of domain-specific apartness. It's the perfect complement to the way that plugins can expand the equality relation, as my student Divesh (now in cc) and I have been exploring... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 23:15:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 23:15:23 -0000 Subject: [GHC] #15350: gcdExtInteger violates assertion Message-ID: <047.463f72a51535cf21b879b51cdb0841bf@haskell.org> #15350: gcdExtInteger violates assertion -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.4.3 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!haskell {-# LANGUAGE UnboxedTuples #-} import GHC.Integer.GMP.Internals main = let (# _, s #) = gcdExtInteger 2 (2^65 + 1) in print s }}} fails with {{{#!haskell Assertion failed: (sn <= mp_size_abs(xn)), function integer_gmp_gcdext, file libraries/integer-gmp/cbits/wrappers.c, line 316. Abort trap: 6 }}} It happens because `s = -2^64` and does not fit one-limbed `BigNat`. The implementation of `gcdExtInteger x y` (https://github.com/ghc/ghc/blob/master/libraries/integer- gmp/src/GHC/Integer/Type.hs#L1392) allocates for `s` a buffer, equal to size of `x` (one limb in our case), but according to GMP manual (https://gmplib.org/manual/Number-Theoretic-Functions.html#index- mpz_005fgcdext) it should be equal to size of `y` (two limbs in our case). Hopefully, the diff is simple enough for a PR on GitHub. Otherwise I'll be happy to prepare a patch for Phabricator. {{{#!diff - s@(MBN# s#) <- newBigNat# (absI# xn#) + s@(MBN# s#) <- newBigNat# (absI# yn#) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 6 23:20:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 06 Jul 2018 23:20:54 -0000 Subject: [GHC] #15350: gcdExtInteger violates assertion In-Reply-To: <047.463f72a51535cf21b879b51cdb0841bf@haskell.org> References: <047.463f72a51535cf21b879b51cdb0841bf@haskell.org> Message-ID: <062.1a34bdea4b2806b9c8d51e32d7f76675@haskell.org> #15350: gcdExtInteger violates assertion -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Bodigrim: Old description: > {{{#!haskell > {-# LANGUAGE UnboxedTuples #-} > import GHC.Integer.GMP.Internals > > main = let (# _, s #) = gcdExtInteger 2 (2^65 + 1) in print s > }}} > > fails with > > {{{#!haskell > Assertion failed: (sn <= mp_size_abs(xn)), function integer_gmp_gcdext, > file libraries/integer-gmp/cbits/wrappers.c, line 316. > Abort trap: 6 > }}} > > It happens because `s = -2^64` and does not fit one-limbed `BigNat`. The > implementation of `gcdExtInteger x y` > (https://github.com/ghc/ghc/blob/master/libraries/integer- > gmp/src/GHC/Integer/Type.hs#L1392) allocates for `s` a buffer, equal to > size of `x` (one limb in our case), but according to GMP manual > (https://gmplib.org/manual/Number-Theoretic-Functions.html#index- > mpz_005fgcdext) it should be equal to size of `y` (two limbs in our > case). > > Hopefully, the diff is simple enough for a PR on GitHub. Otherwise I'll > be happy to prepare a patch for Phabricator. > > {{{#!diff > - s@(MBN# s#) <- newBigNat# (absI# xn#) > + s@(MBN# s#) <- newBigNat# (absI# yn#) > }}} New description: {{{#!haskell {-# LANGUAGE UnboxedTuples #-} import GHC.Integer.GMP.Internals main = let (# _, s #) = gcdExtInteger 2 (2^65 + 1) in print s }}} fails with {{{#!haskell Assertion failed: (sn <= mp_size_abs(xn)), function integer_gmp_gcdext, file libraries/integer-gmp/cbits/wrappers.c, line 316. Abort trap: 6 }}} It happens because `s = -2^64` and does not fit one-limbed `BigNat`. The implementation of `gcdExtInteger x y` (https://github.com/ghc/ghc/blob/master/libraries/integer- gmp/src/GHC/Integer/Type.hs#L1392) allocates for `s` a buffer, equal to size of `x` (one limb in our case), but according to GMP manual (https://gmplib.org/manual/Number-Theoretic-Functions.html#index- mpz_005fgcdext) it should be equal to size of `y` (two limbs in our case). Hopefully, the diff is simple enough for a PR on GitHub (https://github.com/ghc/ghc/pull/163). Otherwise I'll be happy to prepare a patch for Phabricator. {{{#!diff - s@(MBN# s#) <- newBigNat# (absI# xn#) + s@(MBN# s#) <- newBigNat# (absI# yn#) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 7 01:29:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jul 2018 01:29:48 -0000 Subject: [GHC] #15347: QuantifiedConstraints: Implication constraints with type families don't work In-Reply-To: <049.446b77184844bcadda01810c8c61d990@haskell.org> References: <049.446b77184844bcadda01810c8c61d990@haskell.org> Message-ID: <064.41fd110087f0043a756f1a2c6d5caa14@haskell.org> #15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aaronvargo): Yes, that's what I wanted, but after thinking a bit, I think the current behavior may actually be broken anyway! Consider: {{{#!hs type family F a :: Constraint yikes :: forall a b fb. ( a => fb , fb ~ F b ) => Dict (Eq Int) yikes = Dict }}} The above compiles, but with the current behavior, it actually violates the open world assumption! Consider what happens if we now add: {{{#!hs type instance F a = Eq Int }}} {{{ • Could not deduce: a arising from a use of ‘Dict’ from the context: (a => fb, fb ~ F b) bound by the type signature for: yikes :: forall (a :: Constraint) b (fb :: Constraint). (a => fb, fb ~ F b) => Dict (Eq Int) • In the expression: Dict In an equation for ‘yikes’: yikes = Dict }}} The problem is that since `fb ~ F b`, the `a => fb` constraint can overlap if `F b` can be reduced further. A possible solution is to always first reduce the heads of given quantified constraints using given equalities. Then `a => fb` will become `a => F b`, and won't be usable since `F b` isn't a valid instance head. `qux` would then no longer compile, while `yikes` would continue to compile even after the type instance is added. My trick of floating out type families shouldn't even work! I'm not sure that that even completely solves the problem though...Consider: {{{#!hs type family F a :: Constraint type instance F String = () whatAboutThis :: forall a b. ( F String => (b ~ Int) , a => Eq b ) => Dict (Eq Int) whatAboutThis = Dict }}} Currently this compiles. Should it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 7 03:34:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jul 2018 03:34:32 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.5767194ad154bd2ffe8c0c7049a5a052@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Comment (by vdukhovni): Small change for HPUX, instead of {{{ #undef MAP_ANON #define MAP_ANON ... }}} safer to {{{ #ifndef MAP_ANON #define MAP_ANON ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 7 03:35:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jul 2018 03:35:55 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.de1db550cb73ef565419eb85a4ba5414@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Changes (by vdukhovni): * Attachment "patch-rts__posix__OSMem.2.c" added. [Updated] OSMem.c patch with MAP_GUARD used alone rather than in combination with MAP_ANON|MAP_PRIVATE -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 7 05:48:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jul 2018 05:48:37 -0000 Subject: [GHC] #15351: QuantifiedConstraints ignore FunctionalDependencies Message-ID: <049.c965c400807873236afd2b5848198ad6@haskell.org> #15351: QuantifiedConstraints ignore FunctionalDependencies -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code fails to compile: {{{#!hs {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE FunctionalDependencies #-} class C a b | a -> b where foo :: a -> b bar :: (forall a. C (f a) Int) => f a -> String bar = show . foo }}} {{{ • Could not deduce (Show a0) arising from a use of ‘show’ ... The type variable ‘a0’ is ambiguous }}} Yet it ought to work, since this is perfectly fine with top-level instances: {{{#!hs instance C [a] Int where ... baz :: [a] -> String baz = show . foo }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 7 05:52:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jul 2018 05:52:21 -0000 Subject: [GHC] #15351: QuantifiedConstraints ignore FunctionalDependencies In-Reply-To: <049.c965c400807873236afd2b5848198ad6@haskell.org> References: <049.c965c400807873236afd2b5848198ad6@haskell.org> Message-ID: <064.bd196ebb947b82d723a3e54574264eea@haskell.org> #15351: QuantifiedConstraints ignore FunctionalDependencies -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by aaronvargo: Old description: > The following code fails to compile: > > {{{#!hs > {-# LANGUAGE QuantifiedConstraints #-} > {-# LANGUAGE FunctionalDependencies #-} > > class C a b | a -> b where > foo :: a -> b > > bar :: (forall a. C (f a) Int) => f a -> String > bar = show . foo > }}} > > {{{ > • Could not deduce (Show a0) arising from a use of ‘show’ > ... > The type variable ‘a0’ is ambiguous > }}} > > Yet it ought to work, since this is perfectly fine with top-level > instances: > > {{{#!hs > instance C [a] Int where ... > > baz :: [a] -> String > baz = show . foo > }}} New description: The following code fails to compile: {{{#!hs {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE FunctionalDependencies #-} class C a b | a -> b where foo :: a -> b bar :: (forall a. C (f a) Int) => f a -> String bar = show . foo }}} {{{ • Could not deduce (Show a0) arising from a use of ‘show’ ... The type variable ‘a0’ is ambiguous • Could not deduce (C (f a) a0) arising from a use of ‘foo’ ... The type variable ‘a0’ is ambiguous }}} Yet it ought to work, since this is perfectly fine with top-level instances: {{{#!hs instance C [a] Int where ... baz :: [a] -> String baz = show . foo }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 7 06:21:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jul 2018 06:21:02 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.626a72172426ae94d53d4cb9d08ab87f@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Comment (by vdukhovni): So far, this works just fine. The scanner ran for ~7 hours, with reasonable graphs of rss/vsz over time (attached). For the next run, I'll throw in RTS memory stats. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 7 06:22:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jul 2018 06:22:03 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.931b3f020ab53146682917d71270fd33@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Changes (by vdukhovni): * Attachment "mem.pdf" added. Memory footprint of allocation-intensive application over 7 hours of run- time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 7 06:52:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jul 2018 06:52:53 -0000 Subject: [GHC] #15347: QuantifiedConstraints: Implication constraints with type families don't work In-Reply-To: <049.446b77184844bcadda01810c8c61d990@haskell.org> References: <049.446b77184844bcadda01810c8c61d990@haskell.org> Message-ID: <064.d25098ae715395574c15b2492b874c78@haskell.org> #15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aaronvargo): But wait...this compiles: {{{#!hs type family F a :: Constraint uhh :: (a => Eq b, F b) => Dict (Eq Int) uhh = Dict }}} Now add: {{{#!hs type instance F b = b ~ Int }}} {{{ • Could not deduce: a arising from a use of ‘Dict’ }}} Maybe this sort of problem is unavoidable without backtracking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 7 11:13:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jul 2018 11:13:31 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.a88ff24659fd937b218c0778d46754cb@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): I just brought the size down by another 50 lines of code. It's still at 550 lines total. I'll keep coming back to this occasionally to see what else I can eliminate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 7 11:22:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jul 2018 11:22:24 -0000 Subject: [GHC] #10675: GHC does not check the functional dependency consistency condition correctly In-Reply-To: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> References: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> Message-ID: <061.0824262d382d2e09d8ddb94ede1ef968@haskell.org> #10675: GHC does not check the functional dependency consistency condition correctly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: FunDeps Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): There's two reasons (at least) by which the OP program should be rejected (going by the FDs through CHRs paper): 1. GHC's Fundep consistency check is bogus, as comment:15 explains. 2. The FD is non-full. Paper section 6.1/Definition 13/Theorem 2 (Liberal- FD confluence). For non-full FDs, section 6.2 says to 'project' the FD on to a superclass constraint, and 'project' the class's instances: {{{ class (C_FD a b) => C x a b where -- no FD here, it's in the constraint op :: x -> a -> b class C_FD a b | a -> b instance C_FD [x] [x] instance C Char x y => C_FD [x] [Maybe y] -- luckily we can take the context from C's instance }}} Now we can see those instances for `C_FD` overlap (another no-no for the paper). Furthermore there's no substitution ordering. The paper (Fig. 2) says to derive CHRs from all instances and solve to a consistent and confluent set of rules. So (after we've held our noses and looked the other way as we breach the rules) type improvement ends up unifying the `C_FD` instances. In particular, Fig. 2 applies from the class decl and instance decls alone. It doesn't wait to see whether/where instances apply. What I can't explain is why the same doesn't apply for the TTypeEq example comment:9. (The Fig. 2 process incorporates any constraints from instances.) For this ticket it must be that it's breaking 2 rules. I agree with the comment:15 sentiment that "This has been wrong for a long time."/by implication 'fixing' it to reject such programs will break stuff. Then I suggest two warnings: * `-Wfundep-consistency-bogus` where after applying the unifying substitution between instances, the types are **not equal** but merely unifiable. (Reported against an instance, as per the current consistency check -- if **contradictory**, reject the instances, as currently.) * `-Wfundep-nonfull-noncovered` where a FunDep is non-full and there is no class constraint covering just the tyvars for the FunDep. (Reported against the class decl. Hmm hmm needs checking whether the constraining class has a FunDep of the right cover.) Note BTW the paper (section 6.3) has some fancy footwork for 'multi-range FDs': {{{ class D1 x a b | a -> b x where ... -- counts as full, and equivalent to class D2 x a b | a -> b, a -> x where ... -- this class D3 x a b | a -> b, b -> x where ... -- and/or this }}} "There are in fact also cases where we can transform single-range FDs into equivalent multi-range FDs. This has the advantage that non-full single- range FDs become full multi-range FDs and then we can apply the results from Section 6.1." Definition 5 (Basic Conditions) apply at all times: * "The instance declarations must not overlap." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 7 15:19:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jul 2018 15:19:36 -0000 Subject: [GHC] #15213: 32 bit Haddock runs out of memory compiling 32 bit GHC In-Reply-To: <044.953b3633442fb5d6beadb7e79e6f44ca@haskell.org> References: <044.953b3633442fb5d6beadb7e79e6f44ca@haskell.org> Message-ID: <059.c825016468d7be54152683926bc3bc31@haskell.org> #15213: 32 bit Haddock runs out of memory compiling 32 bit GHC ----------------------------------------+------------------------------ Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by Phyx-): Probably, I was wondering if it was an upstream or downstream issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 7 15:29:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jul 2018 15:29:06 -0000 Subject: [GHC] #14530: hWaitForInput causes the program to abort on Windows In-Reply-To: <047.b2bc1211baaf66413ffab8f8c11dbb08@haskell.org> References: <047.b2bc1211baaf66413ffab8f8c11dbb08@haskell.org> Message-ID: <062.7abdaf62b1154cb12dfb41c57dd91f98@haskell.org> #14530: hWaitForInput causes the program to abort on Windows -----------------------------------+-------------------------------------- Reporter: dnadales | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by Phyx-): Oops, sorry, didn't notice the reply. I'll make sure to test this scenario with the new IO manager and network lib. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 7 15:31:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jul 2018 15:31: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.c7b38496dc3dbe36c2c319c20be136c9@haskell.org> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows -------------------------------------+------------------------------------- Reporter: FalconNL | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: #11394, #13440 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): OK, this now works with the new Windows I/O manager. Hopefully included in 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 7 15:32:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jul 2018 15:32:17 -0000 Subject: [GHC] #11394: Base should use native Win32 IO on Windows In-Reply-To: <046.3c711b381d30e89343445554e3990623@haskell.org> References: <046.3c711b381d30e89343445554e3990623@haskell.org> Message-ID: <061.37ecfcd1a7aad328db150b278fcd1e9d@haskell.org> #11394: Base should use native Win32 IO on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 7.10.3 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: | -------------------------------------+------------------------------------- Comment (by Phyx-): All these are now handled correctly under the new I/O manager. Open tasks are tracking down a deadlock and implementing the non-threaded implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 7 21:06:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jul 2018 21:06:19 -0000 Subject: [GHC] #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression In-Reply-To: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> References: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> Message-ID: <065.74f022876aa4dd81dffcdd69b08681c5@haskell.org> #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've had quite an adventure debugging this one. I haven't quite fixed everything, but I have discovered one surprising fact: GHC incorrectly implements the `S_TPush` rule from //System FC with Explicit Kind Equality//. In particular, we have: {{{ Γ ⊢_co γ : ∀ a: κ_1. σ_1 ~ ∀ a: κ_2. σ_2 γ' = sym (nth^1 γ) τ' = τ ⊳ γ' ----------------------------------------- S_TPush (ν ⊳ γ) τ --> (ν τ') ⊳ γ@(<τ> ⊳ γ') }}} But in `CoreOpt`, GHC implements this rule as: {{{#!hs pushCoTyArg :: CoercionR -> Type -> Maybe (Type, MCoercionR) pushCoTyArg co ty ... | isForAllTy tyL = ASSERT2( isForAllTy tyR, ppr co $$ ppr ty ) Just (ty `mkCastTy` mkSymCo co1, MCo co2) ... where Pair tyL tyR = coercionKind co -- co :: tyL ~ tyR -- tyL = forall (a1 :: k1). ty1 -- tyR = forall (a2 :: k2). ty2 co1 = mkNthCo Nominal 0 co -- co1 :: k1 ~N k2 co2 = mkInstCo co (mkCoherenceLeftCo (mkNomReflCo ty) co1) -- co2 :: ty1[ (ty|>co1)/a1 ] ~ ty2[ ty/a2 ] }}} Here, `co2` is supposed to correspond to `γ@(<τ> ⊳ γ')`, or equivalently, `γ@(<τ> ⊳ sym (nth^1 γ))`. But note that this definition isn't correct: `co2` actually calculates `γ@(<τ> ⊳ nth^1 γ)`, not `γ@(<τ> ⊳ sym (nth^1 γ))`! To fix this, all one needs to do is apply this patch: {{{#!diff diff --git a/compiler/coreSyn/CoreOpt.hs b/compiler/coreSyn/CoreOpt.hs index 0353ab6..5e37fee 100644 --- a/compiler/coreSyn/CoreOpt.hs +++ b/compiler/coreSyn/CoreOpt.hs @@ -979,7 +979,7 @@ pushCoTyArg co ty | isForAllTy tyL = ASSERT2( isForAllTy tyR, ppr co $$ ppr ty ) - Just (ty `mkCastTy` mkSymCo co1, MCo co2) + Just (ty `mkCastTy` co1, MCo co2) | otherwise = Nothing @@ -989,8 +989,8 @@ pushCoTyArg co ty -- tyL = forall (a1 :: k1). ty1 -- tyR = forall (a2 :: k2). ty2 - co1 = mkNthCo Nominal 0 co - -- co1 :: k1 ~N k2 + co1 = mkSymCo (mkNthCo Nominal 0 co) + -- co1 :: k2 ~N k1 -- Note that NthCo can extract a Nominal equality between the -- kinds of the types related by a coercion between forall-types. -- See the NthCo case in CoreLint. }}} That fixes one of the Core Lint errors in comment:3, which is nice. But one remains even after applying that patch: {{{ *** Core Lint errors : in result of Simplifier *** Bug.hs:32:1: warning: [in body of lambda with binder a_a1qX :: ()] Kind application error in coercion ‘(Proxy (Sym (D:R:Rep()[0])) _P)_R’ Function kind = forall k. k -> Type Arg kinds = [(Rep (), Type), (a_avO, ())] Fun: Rep () (a_avO, ()) }}} It appears that we shouldn't be constructed the coercion `(Proxy (Sym (D:R:Rep()[0])) _P)_R`, as it's ill kinded. Using `-ddump-rule- rewrites`, we can see that this coercion is generated here: {{{ Rule fired Rule: Class op test Module: (BUILTIN) Before: SGenerics.test TyArg SGenerics.Rep () ValArg SGenerics.$fSDecide() `cast` ((SGenerics.SDecide (Sym (SGenerics.D:R:Rep()[0])))_R :: SGenerics.SDecide () ~R# SGenerics.SDecide (SGenerics.Rep ())) After: $ctest_a1r5 `cast` (forall (a :: Sym (SGenerics.D:R:Rep()[0])). (Data.Proxy.Proxy (Sym (SGenerics.D:R:Rep()[0])) _P)_R :: (forall (a :: ()). Data.Proxy.Proxy a) ~R# (forall (a :: SGenerics.Rep ()). Data.Proxy.Proxy (a |> SGenerics.D:R:Rep()[0]))) Cont: ApplyToTy (SGenerics.PFrom a_a1qX) Select nodup wild_Xj Stop[RhsCtxt] Data.Proxy.Proxy a_a1qX }}} That's as far as I've come debugging thus far. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 7 23:27:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 07 Jul 2018 23:27:27 -0000 Subject: [GHC] #15351: QuantifiedConstraints ignore FunctionalDependencies In-Reply-To: <049.c965c400807873236afd2b5848198ad6@haskell.org> References: <049.c965c400807873236afd2b5848198ad6@haskell.org> Message-ID: <064.615596d8561bd116585fd8bd1b3fbeda@haskell.org> #15351: QuantifiedConstraints ignore FunctionalDependencies -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Your constraint for `bar` doesn't look well-formed to me. I'm surprised GHC accepted the `forall` without an implication `=>`. I guess what you've ended up with is some sort of impredication. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 00:17:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 00:17:12 -0000 Subject: [GHC] #15352: False kind errors with implicitly bound kinds in GHC 8.6 Message-ID: <049.666f6c18fdc69cbdb49750fc137a0f75@haskell.org> #15352: False kind errors with implicitly bound kinds in GHC 8.6 -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This could be related to #15343. The following code fails to compile with GHC 8.6.0.20180627, but does compile with 8.4: {{{#!hs {-# LANGUAGE TypeInType #-} -- or PolyKinds {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} import Data.Kind class C (x :: Type) (y :: k) where type F y }}} {{{ • Expected a type, but ‘k’ has kind ‘k’ • In the kind ‘k’ | 7 | class C (x :: Type) (y :: k) where | ^ }}} Yet all of the following slightly different examples still do compile: {{{#!hs -- remove `x` class C0 (y :: k) where type F0 y -- remove `F` class C1 (x :: Type) (y :: k) -- remove the kind annotation from `x` class C2 x (y :: k) where type F2 y -- switch the order of `x` and `y` class C3 (y :: k) (x :: Type) where type F3 y -- make `k` an explicit parameter, with or without a kind annotation class C4 k (x :: Type) (y :: k) where type F4 y class C5 (k :: Type) (x :: Type) (y :: k) where type F5 y -- add a new parameter *with no kind annotation* class C6 z (x :: Type) (y :: k) where type F6 y }}} Here's also my original example which failed to compile: {{{#!hs type Hom k = k -> k -> Type type family Ob (p :: Hom k) :: k -> Constraint class ( obP ~ Ob p , opP ~ Dom p , obQ ~ Ob q , opQ ~ Dom q , p ~ Dom f , q ~ Cod f ) => Functor' (obP :: i -> Constraint) (opP :: Hom i) (p :: Hom i) (obQ :: j -> Constraint) (opQ :: Hom j) (q :: Hom j) (f :: i -> j) where type Dom f :: Hom i type Cod f :: Hom j }}} {{{ • Expected a type, but ‘j’ has kind ‘k’ • In the first argument of ‘Hom’, namely ‘j’ In the kind ‘Hom j’ | 34 | type Cod f :: Hom j | ^ }}} The only way I can find to make this one compile is to make `i` and `j` explicit parameters with explicit kinds: {{{#!hs class ( obP ~ Ob p , opP ~ Dom p , obQ ~ Ob q , opQ ~ Dom q , p ~ Dom f , q ~ Cod f ) => Functor' (i :: Type) (j :: Type) (obP :: i -> Constraint) (opP :: Hom i) (p :: Hom i) (obQ :: j -> Constraint) (opQ :: Hom j) (q :: Hom j) (f :: i -> j) where type Dom f :: Hom i type Cod f :: Hom j }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 00:41:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 00:41:13 -0000 Subject: [GHC] #15352: False kind errors with implicitly bound kinds in GHC 8.6 In-Reply-To: <049.666f6c18fdc69cbdb49750fc137a0f75@haskell.org> References: <049.666f6c18fdc69cbdb49750fc137a0f75@haskell.org> Message-ID: <064.eac67ca6b06d597e2dcf720f3c53d322@haskell.org> #15352: False kind errors with implicitly bound kinds in GHC 8.6 -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think this is exactly #15142. I have a fix en route -- will hopefully land tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 00:41:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 00:41:32 -0000 Subject: [GHC] #15352: False kind errors with implicitly bound kinds in GHC 8.6 In-Reply-To: <049.666f6c18fdc69cbdb49750fc137a0f75@haskell.org> References: <049.666f6c18fdc69cbdb49750fc137a0f75@haskell.org> Message-ID: <064.24f35b57b7660612b12d530b6ba9c04d@haskell.org> #15352: False kind errors with implicitly bound kinds in GHC 8.6 -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 00:44:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 00:44:04 -0000 Subject: [GHC] #15351: QuantifiedConstraints ignore FunctionalDependencies In-Reply-To: <049.c965c400807873236afd2b5848198ad6@haskell.org> References: <049.c965c400807873236afd2b5848198ad6@haskell.org> Message-ID: <064.7b2f96293d05d6d865e3ea97c34947de@haskell.org> #15351: QuantifiedConstraints ignore FunctionalDependencies -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Quantified constraints do not need a constraint -- just a `forall` is fine. Though I can't swear to it, I do think the original program should be accepted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 00:47:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 00:47:25 -0000 Subject: [GHC] #15352: False kind errors with implicitly bound kinds in GHC 8.6 In-Reply-To: <049.666f6c18fdc69cbdb49750fc137a0f75@haskell.org> References: <049.666f6c18fdc69cbdb49750fc137a0f75@haskell.org> Message-ID: <064.835e6be87d398957f3c5dc7e345ef6ef@haskell.org> #15352: False kind errors with implicitly bound kinds in GHC 8.6 -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aaronvargo): Ah, indeed it is! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 00:50:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 00:50:00 -0000 Subject: [GHC] #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression In-Reply-To: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> References: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> Message-ID: <065.0022f5117ae324b312644a0961c97181@haskell.org> #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Wow. Good sleuthing. Yes, you're right about TPush. I'm boggled that we've gotten this far with that mistake in there. I may have time tomorrow to continue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 01:04:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 01:04:15 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.dd9afb86aa5fda07b260e32a5be25e37@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): OK. I propose that we merge the work Ningning has done so far, given that it is generally an improvement. Ningning, are you happy with the current patch on Phab:D4747? If so, I can merge it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 06:29:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 06:29:11 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.0106d3d28f0b49ba2fffc1e2f0685c12@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ningning): Replying to [comment:14 goldfire]: > OK. I propose that we merge the work Ningning has done so far, given that it is generally an improvement. Ningning, are you happy with the current patch on Phab:D4747? If so, I can merge it. I am generally happy with it. Should I rebase it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 07:32:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 07:32:18 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.fc201d3afeabce4919fe2c021e36e135@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Changes (by vdukhovni): * Attachment "patch-rts__posix__OSMem.3.c" added. [Further code cleanup] OSMem.c patch with MAP_GUARD used alone rather than in combination with MAP_ANON|MAP_PRIVATE -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 07:36:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 07:36:38 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.51aa69ebfe31da2149c44b4efa1971a6@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Comment (by vdukhovni): I found the OSMem.c code a bit of an `#ifdef` maze. The latest patch attached should improve clarity, by better separating the logic from CPP conditionals. One side-effect is that `madvise(MADV_WILLNEED)` will now be called on `COMMIT` not only for Linux, but also for FreeBSD and other non-Darwin `mmap()` API platforms. Will test this shortly... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 08:04:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 08:04:34 -0000 Subject: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request In-Reply-To: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> References: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> Message-ID: <066.0e0da52012d0a941d86c692a17afffe3@haskell.org> #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: patch Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15219 | Differential Rev(s): Phab:D4777 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D4777 * related: => #15219 Comment: The [https://github.com/ghc-proposals/ghc- proposals/blob/master/proposals/0013-unlifted-newtypes.rst proposal] was accepted and this feature is currently being implemented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 08:04:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 08:04:42 -0000 Subject: [GHC] #15219: Implement UnliftedNewtypes proposal In-Reply-To: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> References: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> Message-ID: <064.9cfa757feaee4a0ce688de432348e46f@haskell.org> #15219: Implement UnliftedNewtypes proposal -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | UnliftedNewtypes, GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1311 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: => #1311 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 08:09:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 08:09:04 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.e7fa8aa8cdb2366bba7c3df5bfef4ba5@haskell.org> #9374: Investigate Static Argument Transformation -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: | StaticArgumentTransformation 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 osa1): I don't know what changed since comment:20, but I get literally no difference in allocations with `-fstatic-argument-transformation` when I run nofib with GHC 8.4.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 11:12:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 11:12:34 -0000 Subject: [GHC] #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression In-Reply-To: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> References: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> Message-ID: <065.3c707f4a5e573329e41be4c50d67dd0a@haskell.org> #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): As far as the other Core Lint error goes, I think I've narrowed it down to [http://git.haskell.org/ghc.git/blob/671537364ae09dc65d4bb1c646aa80e9c8f808df:/compiler/coreSyn/CoreOpt.hs#l1056 pushCoDataCon] (which implements the `S_KPush` rule from //System FC with Explicit Kind Equality//), as that's the function that annotates `$ctest` with the coercion `forall (a :: Sym (D:R:Rep()[0])). (Proxy (Sym (D:R:Rep()[0])) _P)_R`. I tried tracing through the steps of `S_KPush` to see if this coercion is what should have been produced, but I'm uncertain in my results simply because the way that GHC represents type abstraction congruence coercions is slightly different than the way they're represented in the paper. In the paper, a type abstraction congruence coercion is of the form: {{{ ∀_η (a_1, a_2, c). γ }}} Where `η` is a kind coercion, `a_1` and `a_2` are two fresh type variables inhabiting the from- and to-kinds of `η`, respectively, and `c` is a fresh coercion variable witnessing `a_1 ~ a_2`. See the `CT_AllT` rule in Figure 4 for a complete presentation of how it's typed. Since the type of `$ctest` is `∀(a : k). Proxy k a`, applying `Ψ` to this type (where `Ψ` is defined in Section 5 of the paper) should produce: {{{ ∀_(Sym (D:R:Rep()[0])) (a_1, a_2, c). (Sym (D:R:Rep()[0])) c }}} This does look a bit different than the coercion that GHC is actually producing, since the last argument to `` is `c` instead of ``. However, it's quite hard for me to determine if this difference is intentional, especially after reading GHC's [http://git.haskell.org/ghc.git/blob/671537364ae09dc65d4bb1c646aa80e9c8f808df:/compiler/types/TyCoRep.hs#l1038 Note [Forall coercions]], which presents the typing rule as: {{{ kind_co : k1 ~ k2 tv1:k1 |- co : t1 ~ t2 ------------------------------------------------------------------- ForAllCo tv1 kind_co co : all tv1:k1. t1 ~ all tv1:k2. (t2[tv1 |-> tv1 |> sym kind_co]) }}} This presentation is quite different from the `CT_AllT` typing rule in the paper, as it does not introduce two fresh type variables of different kinds equated by a coercion variable. Instead, it uses the same type variable in both sides of the `ForAllCo`, and tries to fix up the kind of the type variable in the to-type with this strange `tv1 |> sym kind_co` coercion. GHC's unusual treatment of this typing rule at least explains why the kind of the coercion we see in this program is `(forall (a :: ()). Proxy () a) ~R# (forall (a :: Rep ()). Proxy (Rep ()) (a |> D:R:Rep()[0]))`. Still, I find it difficult to convince myself that this alternate treatment is correct. After all, the type `forall (a :: Rep ()). Proxy (Rep ()) (a |> D:R:Rep()[0])` looks blatantly ill kinded to me, since `(a |> D:R:Rep()[0])` is of kind `()`, not `Rep ()` as it claims. Richard, do you have any insights here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 11:14:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 11:14:09 -0000 Subject: [GHC] #9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.9a6dbe2fdc7f1c9053d0817d0e078e49@haskell.org> #9123: Emit quantified Coercible constraints in GeneralizedNewtypeDeriving -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Roles, Resolution: fixed | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T9123{,a} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: If we can't come up with a uniform way to generate these constraints, then my optimism is probably unwarranted. Let's close this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 11:29:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 11:29:47 -0000 Subject: [GHC] #15311: MCoercion lacks an Outputable instance In-Reply-To: <049.b5ea1182b9f8a04e41d20be9a8908734@haskell.org> References: <049.b5ea1182b9f8a04e41d20be9a8908734@haskell.org> Message-ID: <064.112ce37caefd4436f8605c3a39809e88@haskell.org> #15311: MCoercion lacks an Outputable instance -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4944 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4944 Comment: I know this is marked as a newcomer ticket, but I found myself needing to add this instance anyway in order to debug #15346, so I'll just go ahead and submit a patch for this anyways. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 12:04:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 12:04:11 -0000 Subject: [GHC] #15351: QuantifiedConstraints ignore FunctionalDependencies In-Reply-To: <049.c965c400807873236afd2b5848198ad6@haskell.org> References: <049.c965c400807873236afd2b5848198ad6@haskell.org> Message-ID: <064.86080f4d76680cf1036090ee397f58ad@haskell.org> #15351: QuantifiedConstraints ignore FunctionalDependencies -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:3 goldfire]: > Quantified constraints do not need a constraint -- just a `forall` is fine. Then the github proposal's [https://github.com/Gertjan423/ghc- proposals/blob/quantified-constraints/proposals/0000-quantified- constraints.rst#id8 syntax changes] are wrongly described. (And the same text has gone into the Users guide.) The `=>` is the defining syntax for the extension; the `forall` is optional (although often needed in practice). @aaron, perhaps you could take out the `QuantifiedConstraints` flag (but put in `ExplicitForAll`) and try re-compiling. Does GHC complain you need to switch on the extension? (Sorry I can't try that from here.) > I do think the original program should be accepted. Then what does it mean? At a guess: for some `f0` being the type constructor in an argument to `bar`, there's an `instance C (f0 a') Int`? Note that `a'` is quantified within the constraint, so is distinct from the `a1` argument to the constructor `f0`. There is no such instance declared, whereas for the `baz` example there is an `instance C [a] Int`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 12:27:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 12:27:57 -0000 Subject: [GHC] #15353: Another Cabal submodule bump Message-ID: <057.8f07747ab1b423349609ed5b64e04274@haskell.org> #15353: Another Cabal submodule bump -------------------------------------+------------------------------------- Reporter: | Owner: (none) quasicomputational | Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- https://github.com/snowleopard/hadrian/issues/634 uncovered a bug in Cabal that bit Hadrian quite severely. The Hadrian people are working around it, but it'd be nice if they could rip out the hacks in CI and stop having to remember to point the Cabal submodule to a fixed commit. The bug has been fixed in Cabal HEAD now, so the only thing needed is a submodule bump in GHC master, please. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 16:24:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 16:24:01 -0000 Subject: [GHC] #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression In-Reply-To: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> References: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> Message-ID: <065.eb7cfc8abd0e431e9f5ebd037a1b13ce@haskell.org> #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"6595bee749ddb49d9058ed47ab7c1b6e7558ae17/ghc" 6595bee/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6595bee749ddb49d9058ed47ab7c1b6e7558ae17" Define an Outputable MCoercion instance Summary: I needed this when debugging #15346. Test Plan: Does it compile? It does? Cool. Reviewers: bgamari, mpickering Reviewed By: mpickering Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15311 Differential Revision: https://phabricator.haskell.org/D4944 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 16:24:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 16:24:01 -0000 Subject: [GHC] #15311: MCoercion lacks an Outputable instance In-Reply-To: <049.b5ea1182b9f8a04e41d20be9a8908734@haskell.org> References: <049.b5ea1182b9f8a04e41d20be9a8908734@haskell.org> Message-ID: <064.b455908c67d46d0c4ff3c1fa3a1adf0a@haskell.org> #15311: MCoercion lacks an Outputable instance -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4944 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"6595bee749ddb49d9058ed47ab7c1b6e7558ae17/ghc" 6595bee/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6595bee749ddb49d9058ed47ab7c1b6e7558ae17" Define an Outputable MCoercion instance Summary: I needed this when debugging #15346. Test Plan: Does it compile? It does? Cool. Reviewers: bgamari, mpickering Reviewed By: mpickering Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15311 Differential Revision: https://phabricator.haskell.org/D4944 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 16:24:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 16:24:55 -0000 Subject: [GHC] #15311: MCoercion lacks an Outputable instance In-Reply-To: <049.b5ea1182b9f8a04e41d20be9a8908734@haskell.org> References: <049.b5ea1182b9f8a04e41d20be9a8908734@haskell.org> Message-ID: <064.63d899e61a1e63502079dec007dfbcd8@haskell.org> #15311: MCoercion lacks an Outputable instance -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4944 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 21:00:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 21:00:23 -0000 Subject: [GHC] #15354: QuantifiedConstraints not fully described in manual Message-ID: <047.918d0c77c6c735a247e6543296b4835e@haskell.org> #15354: QuantifiedConstraints not fully described in manual -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As pointed out in comment:4:ticket:15351, the section in the manual on `-XQuantifiedConstraints` says that an `=>` is essential in a quantified constraint. However, the following is accepted: {{{#!hs class C a foo :: (forall x. C x) => () foo = () }}} Note that there is no `=>` in the quantified constraint. We need to update the manual accordingly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 22:48:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 22:48:45 -0000 Subject: [GHC] #15355: Functional dependencies can get GHC to print "UnkSkol" Message-ID: <047.fc55ac981662395b31d65ce17a7f873f@haskell.org> #15355: Functional dependencies can get GHC to print "UnkSkol" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple FunctionalDependencies | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I say {{{#!hs class C a b | a -> b where foo :: a -> b instance C Int Bool where foo = (>0) blah :: C Int Double => Int -> _a blah = foo }}} I get {{{ • Couldn't match type ‘Double’ with ‘Bool’ arising from a functional dependency between constraints: ‘C Int Bool’ arising from a use of ‘foo’ at Scratch.hs:51:8-10 ‘C Int Double’ arising from UnkSkol at Scratch.hs:51:1-10 • In the expression: foo In an equation for ‘blah’: blah = foo }}} There are actually two problems: 1. If we replace `_a` with `Double`, GHC accepts the program. I'm not sure it should. But that's a larger problem than... 2. ... when it prints the error, it says `UnkSkol`. It probably shouldn't. This ticket is about the second problem, because the first one require more fundep love than is usually on offer around here. Erroring here is reasonable enoug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 22:54:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 22:54:24 -0000 Subject: [GHC] #15351: QuantifiedConstraints ignore FunctionalDependencies In-Reply-To: <049.c965c400807873236afd2b5848198ad6@haskell.org> References: <049.c965c400807873236afd2b5848198ad6@haskell.org> Message-ID: <064.a74576fc5e7187d69e159acead3b7630@haskell.org> #15351: QuantifiedConstraints ignore FunctionalDependencies -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I've created #15354 about the documentation oversight -- you're absolutely right. I agree with your analysis in comment:4. By the constraint `forall a. C (f a) Int` (and the fundep), we know that any instance that begins with `C (f a)` ends with `Int`. Let's name different variables differently: {{{#!hs bar :: (forall b. C (f b) Int) => f a -> String bar = show . foo }}} So, since the usage of `foo` induces a `C (f a) alpha` constraint (for some unknown `alpha`) we can conclude that `alpha` must be `Int` by the fundep. Here is a related example, with the same `C`: {{{#!hs blah :: C Int Double => Int -> String blah = show . foo }}} This is accepted (even with no instances for `C`), because GHC can figure out that the result of `foo` must be `Double`. I don't see how quantified constraints should change that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 22:57:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 22:57:28 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.f6dc65d4f91bb923bab4c8c34d4f8f35@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, please. Then re-post to Phab and let me know you're ready to commit; I can to the merge to the master branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 8 23:19:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 08 Jul 2018 23:19:10 -0000 Subject: [GHC] #15356: Template Haskell should turn off RebindableSyntax in quotes Message-ID: <047.a53c06dcd85dace5b494f3df105e5ebc@haskell.org> #15356: Template Haskell should turn off RebindableSyntax in quotes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template | Version: 8.4.3 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I say {{{#!hs {-# LANGUAGE RebindableSyntax, TemplateHaskellQuotes #-} module Bug ( quote ) where quote = [| if 5>3 then 'x' else 'y' |] }}} GHC complains that `ifThenElse` and `fromInteger` are not in scope. If I then bring these into scope somehow, then the resulting quote does not use them. I think it's correct that the resulting quote doesn't use the rebindable syntax -- a quote should just stand for a convenient way or writing the TH AST. But then we shouldn't complain about missing rebindable syntax bits inside of a quote. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 00:18:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 00:18:57 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.0af2a4177c75b9f94690471c75613755@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Comment (by vdukhovni): The latest patch runs fine... I'm done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 07:22:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 07:22:12 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.aa9a7aa1a1570a8e43a5462c6974fd11@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | roles/should_compile/Roles2 Blocked By: | Blocking: Related Tickets: #9164 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): dominic, what is comment:30 trying to say? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 07:34:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 07:34:12 -0000 Subject: [GHC] #15349: fixST is a bit wrong In-Reply-To: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> References: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> Message-ID: <060.0635862c44a11c7e02ba84277b0b6313@haskell.org> #15349: fixST is a bit wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Wow, good catch. I suppose we should do what `fixIO` does, since this is clearly wrong. But maybe there's a way to do it with `IORef` that would be cheaper than `MVar`? (we'd need benchmarks to check, though) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 07:37:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 07:37:05 -0000 Subject: [GHC] #15351: QuantifiedConstraints ignore FunctionalDependencies In-Reply-To: <049.c965c400807873236afd2b5848198ad6@haskell.org> References: <049.c965c400807873236afd2b5848198ad6@haskell.org> Message-ID: <064.f82bf117a2d2930d2088a3a35e5cfab7@haskell.org> #15351: QuantifiedConstraints ignore FunctionalDependencies -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, you are right. Generally, when solving a constraint, GHC checks it against all in-scope instances in case there's fundep match. The same should happen for in-scope quantified constraints. Would anyone like to fix this? It's intriguing -- I never expected people to explore the outer limits of quantified constraints so rapidly. I hope that means that they are proving useful (when not so close to the limits). Is that so? Experience reports or blog posts (like Ryan Scott's) would be fascinating. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 07:46:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 07:46:32 -0000 Subject: [GHC] #15351: QuantifiedConstraints ignore FunctionalDependencies In-Reply-To: <049.c965c400807873236afd2b5848198ad6@haskell.org> References: <049.c965c400807873236afd2b5848198ad6@haskell.org> Message-ID: <064.355b004cae9edef12e5d9acd23abbdce@haskell.org> #15351: QuantifiedConstraints ignore FunctionalDependencies -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:5 goldfire]: > > {{{#!hs > bar :: (forall b. C (f b) Int) => f a -> String > bar = show . foo > }}} > > So, since the usage of `foo` induces a `C (f a) alpha` constraint (for some unknown `alpha`) we can conclude that `alpha` must be `Int` by the fundep. > Hmm (and accepting for the moment this is a legitimate `QuantifiedConstraint`). The OP doesn't include any `C` instance for the `f` in `bar` -- i.e. evidence for `C (f b) alpha`. Is that what the message `Could not deduce (C (f a) a0) arising from a use of ‘foo’` is saying? Is there another message the OP hasn't included `no instance for (C (f a) a0) ...`? The fact of the message saying ''deduce'' suggests it's trying to do apply some sort of implication?? Deduce what from what? (Simon's comment:6 that arrived as I was writing this doesn't explain what specifically GHC "checks it against" in this case.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 08:18:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 08:18:22 -0000 Subject: [GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 In-Reply-To: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> References: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> Message-ID: <066.9de9c8f9446beb373fb1d1f28a7fd355@haskell.org> #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Steps to reproduce: 1. Check out from git: {{{#!bash git clone https://github.com/waivio/cl3.git; cd cl3 }}} 2. Install the `random` package (e.g. `cabal install random`) 3. {{{#!bash cd cl3 }}} 4. {{{#!bash ghc -c Algebra/Geometric/Cl3.hs -fforce-recomp -O2}}} Without `-O2`, things compile in under .1 seconds on my machine; adding `-O2` makes it take minutes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 08:50:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 08:50:59 -0000 Subject: [GHC] #15351: QuantifiedConstraints ignore FunctionalDependencies In-Reply-To: <049.c965c400807873236afd2b5848198ad6@haskell.org> References: <049.c965c400807873236afd2b5848198ad6@haskell.org> Message-ID: <064.d81b521f60d9610bdb1137ae72bd3772@haskell.org> #15351: QuantifiedConstraints ignore FunctionalDependencies -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > this doesn't explain what specifically GHC "checks it against" in this case It's worth reading the original paper -- though alas I cannot find PDF online. Given {{{ class C a b | a -> b instance C Int Bool }}} if GHC finds a wanted constraint `[W] C Int t`, it compares it against all the top-level instances to see if the fist argument of `C` matches the one in the instance. It succeeds in this case, and emits a new Derived constraint `[D] t ~ Bool`. Quantified constraints behave very like top-level instances, so they too should be examined in this search. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 08:53:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 08:53:05 -0000 Subject: [GHC] #15351: QuantifiedConstraints ignore FunctionalDependencies In-Reply-To: <049.c965c400807873236afd2b5848198ad6@haskell.org> References: <049.c965c400807873236afd2b5848198ad6@haskell.org> Message-ID: <064.a35dcbe15b7167065789706c4ed4eba8@haskell.org> #15351: QuantifiedConstraints ignore FunctionalDependencies -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aaronvargo): Replying to [comment:6 simonpj]: > Would anyone like to fix this? How difficult would it be? I might like to try, but I've never contributed to GHC before. I could see it being pretty simple since most of the logic should already exist for top-level instances, but I wouldn't know. And I might need some hand-holding... > It's intriguing -- I never expected people to explore the outer limits of quantified constraints so rapidly. I would guess this is partly because we could already (somewhat painfully) manually represent such constraints with `Dict`s, so we already had some idea of what they might be useful for, and want them to be able to do everything we can do with `Dict`s (though that turns out to be unreasonable). I came across this particular issue while trying to work around #15347, but I'll write more about that on that ticket (at some point. Maybe after I can get my stupid example to work). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 08:56:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 08:56:27 -0000 Subject: [GHC] #14231: Core lint error "in result of Static argument" In-Reply-To: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> References: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> Message-ID: <064.37ad42c0c878bc0a09e9e9653ff00c23@haskell.org> #14231: Core lint error "in result of Static argument" -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4945 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D4945 Comment: In comment:8 I mentioned two problems: 1. Weird shadowing code to avoid renaming. 2. Weird binder cloning. It turns out only fixing (1) is enough to close this ticket. It's easy to fix (2) too (we just need to clone all binders of a definition with `CoreSubst.cloneIdBndrs`) but my patch doesn't include that for now. I validated GHC HEAD with `-fstatic-argument-transformation` and got a bunch of failures. I'll validate again with Phab:D4945 (and with `-fSAT`), and then validate again with my fix for (2) to see if that fixes any existing failures. (I don't have a reproducer for (2) yet) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 08:58:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 08:58:22 -0000 Subject: [GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 In-Reply-To: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> References: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> Message-ID: <066.86531367b2f3379d7470eb8afb2f31f4@haskell.org> #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): It seems that the `Eq` instance is at the core of the problem: replacing it with the following allows GHC to compile the module in a timely fashion, and compilation succeeds even with a heap limit of only 128M: {{{#!haskell instance Eq Cl3 where (==) = undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 10:24:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 10:24:48 -0000 Subject: [GHC] #15351: QuantifiedConstraints ignore FunctionalDependencies In-Reply-To: <049.c965c400807873236afd2b5848198ad6@haskell.org> References: <049.c965c400807873236afd2b5848198ad6@haskell.org> Message-ID: <064.d2ba92884761fae06a23c9ba970c0ab7@haskell.org> #15351: QuantifiedConstraints ignore FunctionalDependencies -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:6 simonpj]: > Yes, you are right. Sorry to be dumb, but who is 'you' and which bit are they 'right' about? > It's worth reading the original paper Yes I've pored over both your 2000 paper with Ralf, and the hs 2017 more detailed logic. (Both linked from the github proposal.) I didn't see any examples without a `=>` implication; I didn't see any examples without any instances declared at all. And the github proposal didn't mention such possibilities either. > It's intriguing -- I never expected people to explore the outer limits of quantified constraints so rapidly. I hope that means that they are proving useful (when not so close to the limits). Is that so? I think this extension is going to be huge -- and that was assuming the implications are needed. Experiments I will try when I get my hands on it: * subsuming quasi-injective logic {{{ class ( (b1 ~ True, b2 ~ True) => res ~ True, res ~ True => b1 ~ True, res ~ True => b2 ~ True, (res ~ False, b1 ~ True) => b2 ~ False, (res ~ False, b2 ~ True) => b1 ~ False ) => And (b1 :: Bool) (b2 :: Bool) ( res :: Bool) }}} * subsuming FunDeps {{{ class (forall b'. C a b' => b' ~ b) -- replicates GHC's "bogus" FD consistency check ref Trac #10675 => C a b where ... -- don't need | a -> b }}} (Is there any way to get a 'strict' after substitution `b'` equal type `b` consistency check?) * maybe subsuming overlap logic/apartness guards (of course more interesting uses than this example) {{{ class ( e ~ e' => d ~ Z, e /~ e' => d ~ (S d'), FindElem e l' d') => FindElemPosn e '( e' ': l' ) (d :: Nat) where ... }}} * field presence/absence for record extension/projection {{{ class ( (forall l a. HasField r1 l a => HasField r3 l a), (forall l a. HasField r2 l a => HasField r3 l a) ) => Merge r1 r2 r3 class ( (forall l a. HasField r3 l a => HasField r1 l a), (forall l a a'. (HasField r1 l a, HasField r2 l a') => HasField r3 l a), (forall l. Lacks r2 l => Lacks r3 l) ) => Project r1 r2 r3 }}} (Apologies for poaching on @aaron's ticket: you're welcome to try the above ideas.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 12:10:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 12:10:42 -0000 Subject: [GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 In-Reply-To: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> References: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> Message-ID: <066.940eba74773208ece9a3cc5c2a0777cc@haskell.org> #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Further investigation reveals that it's not necessarily the `Eq` instance itself that causes trouble; commenting out various parts of the module allows me to make it blow up or not blow up even with the full original `Eq` in place. It seems that multiple factors contribute to the blowup, and removing enough of them "fixes" the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 12:47:10 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 12:47:10 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.966927b2c8d5140f2599fcaaf1b48962@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | roles/should_compile/Roles2 Blocked By: | Blocking: Related Tickets: #9164 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dominic): Replying to [comment:31 simonpj]: > dominic, what is comment:30 trying to say? I think there is bug. This should be a type error. Here's a PR: https://phabricator.haskell.org/D4941. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 13:00:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 13:00:58 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.9f3edc6217bc9aa39c3576d87363ea65@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | roles/should_compile/Roles2 Blocked By: | Blocking: Related Tickets: #9164 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dominic): BTW you can't coerce a CInt to an Int so why should you be able to coerce a Vector of CInts to a Vector of Int? {{{ Prelude Data.Coerce Foreign.C.Types Data.Int> coerce (0 :: CInt) :: Int :5:1: error: • Couldn't match representation of type 'Int32' with that of 'Int' arising from a use of 'coerce' • In the expression: coerce (0 :: CInt) :: Int In an equation for 'it': it = coerce (0 :: CInt) :: Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 13:26:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 13:26:17 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.1e25de672c2f78749a9da9dba12672f4@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | roles/should_compile/Roles2 Blocked By: | Blocking: Related Tickets: #9164 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I think there's a bit of a tension here between two different camps who want `Ptr`'s role signature to be phantom or representational for different purposes: 1. Some have argued that it should be phantom because that allows one to implement `castPtr` (a quite fundamental operation) efficiently via `coerce`. 2. Others have argued that it should be representational to avoid coercing between `Ptr`s whose underlying types have different representations. Personally, I find myself more aligned towards the (1) camp, for the simple reason that `Ptr`s are not intended to be a safe abstraction. There are many ways you can cause a Haskell program to segfault through reckless use of `Ptr`s (even without `castPtr`), so changing its role signature isn't going to change things in this regard. In light of this, I'm inclined to believe that the proper fix to dominic's problem is to give `Vector` a role signature of representational, as `Vector` is what is intended to be a safe abstraction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 13:29:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 13:29:15 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.9fb6b5779fd94fafeaa2ad4e415d125a@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | roles/should_compile/Roles2 Blocked By: | Blocking: Related Tickets: #9164 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Is this really a discussion for the libraries list? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 13:31:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 13:31:39 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.1084a1e6ff974da6c675b9e8470bbab3@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | roles/should_compile/Roles2 Blocked By: | Blocking: Related Tickets: #9164 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): If dominic feels strongly about this, then yes, I'd encourage that they take this issue to the libraries list. I posted comment:34 not necessarily to start the debate afresh, but to give an overview of how things came to be, and to give my (editorialized) view on a simple way to resolve this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 13:59:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 13:59:21 -0000 Subject: [GHC] #14231: Core lint error "in result of Static argument" In-Reply-To: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> References: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> Message-ID: <064.2e142ca812dfbaa98562a79c5905c51b@haskell.org> #14231: Core lint error "in result of Static argument" -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4945 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I "fixed" (2), but that made some tests that were previously (just (1)) passing fail. Maybe I misunderstood what it's supposed to do. With my fix for (1) currently these tests are failing when running the test suite with `EXTRA_HC_OPTS="-fstatic-argument-transformation -dcore- lint"`: {{{ ManyAlternatives ManyConstructors MultiLayerModules T10370 T10547 T10858 T10989 T12150 T12227 T12234 T12425 T12545 T12707 T13035 T13056 T13143 T13379 T13701 T13719 T13825-ghci T14052 T14683 T14697 T15164 T1969 T2182ghci T3064 T3294 T3591 T4029 T4801 T4945 T5030 T5321FD T5321Fun T5631 T5642 T5837 T6048 T6106 T783 T8353 T8425 T9020 T9233 T9293 T9630 T9675 T9872a T9872b T9872c T9872d T9961 break008 break009 break026 determ017 ghci.prog009 ghci.prog010 ghci024 ghci025 ghci038 ghci057 ghci058 inline-check joao-circular parsing001 print007 prog001 prog002 prog003 prog012 prog013 rule2 spec001 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 14:16:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 14:16:37 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.07c491ed59998183c61ddadd52581b88@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | roles/should_compile/Roles2 Blocked By: | Blocking: Related Tickets: #9164 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dominic): I do feel strongly. From https://hackage.haskell.org/package/base-4.8.2.0/docs/Data-Coerce.html: "The function coerce allows you to safely convert between values of types". If the user has to know that the package they are using uses Ptr and thus avoid coerce then that seems to break the principle of abstraction. At least change the claim that coerce is type safe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 14:25:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 14:25:12 -0000 Subject: [GHC] #14231: Core lint error "in result of Static argument" In-Reply-To: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> References: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> Message-ID: <064.ec8f04c71f5e1285d0460e2f4bfc89ac@haskell.org> #14231: Core lint error "in result of Static argument" -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4945 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): These are all stat failures: (not good enough) - T10858 - T1969 - T3294 - T4801 - T3064 - T5030 - T5631 - parsing001 - T783 - T5321Fun - T5321FD - T5642 - T5837 - T6048 - T9020 - T9675 - T9872a - T9872b - T9872c - T9872d - T9961 - T9233 - T10370 - T10547 - T12227 - T12425 - T12234 - T12545 - T13035 - T13056 - T12707 - T12150 - T13379 - MultiLayerModules - ManyConstructors - ManyAlternatives - T13701 - T13719 - T14697 - T14683 - T9630 - T15164 - T14052 Lint errors: - determ017 - joao-circular - spec001 - T4945 - T13143 - T3591 - T8425 Debug output differs because with this pass we do more inlinings etc. - inline-check - rule2 These are all -fghci-leak-check warnings: - prog001 - prog002 - prog003 - ghci.prog009 - ghci.prog010 - prog012 - prog013 - ghci024 - ghci025 - ghci038 - ghci057 - T2182ghci - T6106 - ghci058 - T8353 - T9293 - T10989 - T13825-ghci - print007 - break008 - break009 - break026 - T4029 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 14:27:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 14:27:36 -0000 Subject: [GHC] #15337: Warning not showing up when deprecated variable is explicitly imported In-Reply-To: <046.eac70ab0086dceacc7da0405feddb32c@haskell.org> References: <046.eac70ab0086dceacc7da0405feddb32c@haskell.org> Message-ID: <061.b9f6e605ccb81574242de743729cdc98@haskell.org> #15337: Warning not showing up when deprecated variable is explicitly imported -------------------------------------+------------------------------------- Reporter: alanasp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: deprecation | 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: | -------------------------------------+------------------------------------- Comment (by tdammers): Phab:D4931 reveals an unintended consequence of this mechanism. In the case at hand, the `bytestring` package defines and deprecates `findSubstrings` in `Data.ByteString`, and then transparently re-exports it from `Data.ByteString.Char8`. Conceptually, the transparent re-export is not an error; the intention is to just forward the symbol, deprecation and all, through the `.Char8` module. But in order to re-export the symbol, `.Char8` needs to import it, and that does trigger the "importing deprecated symbol" warning. However, the situation is only like this because both modules are from the same package; if `bytestring` were to explicitly re-export a symbol from some other package, and *that* symbol got deprecated, then I'd expect the deprecation warning to fire, because in such a case, the intention would be to re-export the non-deprecated symbol, and the deprecation flag on it would be unexpected from the module author's point of view. The again, "package" isn't really a meaningful language-level concept, so saying "OK, if this import comes from the same package, then don't warn about it" doesn't seem right either. Maybe a solution would be to somehow allow marking explicit imports as deprecated, which would 1) deprecate the symbol in the current module's namespace including re-exports, and 2) silence the deprecation warning while compiling the current module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 15:48:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 15:48:55 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.8df6056c9ec6a7a8627ea5041f4dc456@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nfrisby Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 | Differential Rev(s): Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): I'm currently thinking about Pros and Cons involved with (re-)implementing this as an optimization on STG rather than Core. Pros: - Much less involved analysis that doesn't need to stay in sync with CorePrep - LLF only enables intra-module opportunities in the simplifier anyway - Runtime arguments are immediately visible - Lifting to top-level only is orthogonal enough to full laziness that it might be worthwhile to split anyway - Integrating more low-level information might be more feasible (like calling convention, e.g. number of argument registers, or `stg_ap_*` patterns) Cons: - The Simplifier might not be able to inline as much (which probably had limited effect anyway) - It's not enough to look at Core alone to gauge allocation (quite a bummer) - No Core Lint (but STG Lint, still) - Potentially we need to re-invent some utility functions we already have for Core - Perform the lifting by hand, rather than let `FloatOut` do the work I'm really interested to hear opinions/objections about this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 15:49:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 15:49:26 -0000 Subject: [GHC] #15315: Renamer plugins could run after each group has been renamed In-Reply-To: <049.364dc4b31c5f3adc156474aa350df00b@haskell.org> References: <049.364dc4b31c5f3adc156474aa350df00b@haskell.org> Message-ID: <064.1128756c35e6a662d4e764dbaf694a4d@haskell.org> #15315: Renamer plugins could run after each group has been renamed -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4947 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * differential: => Phab:D4947 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 16:29:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 16:29:43 -0000 Subject: [GHC] #15357: Make nofib suitable for runtime measurements. Message-ID: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> #15357: Make nofib suitable for runtime measurements. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: NoFib | Version: 8.4.3 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): | Wiki Page: -------------------------------------+------------------------------------- Currently many benchmarks in a default nofib run have runtimes so low that they become meaningless. This comes with a bunch of issues: * It takes up build/runtime while not actually improving the accuracy of runtime measurements. * It skews results as the jump from 1ms to 2ms registers as a 200% change. * It can hide regression which fall outside of the measured granularity. * Higher number of runs per benchmark spend far too much time on the few slower benchmarks. At the extreme end there are 9 benchmarks with runtimes shorter than the granularity of 1ms. For some benchmarks changing this might be as easy as increasing the number of runs/iterations. For others changing problem sizes is not as easy since they process more complex input data. Below are the runtimes of a recent default nofib run. ||= benchmark =|| Time (ms) || || ansi || 0 || || awards || 0 || || banner || 0 || || calendar || 0 || || expert || 0 || || gen_regexps || 0 || || grep || 0 || || pretty || 0 || || scc || 0 || || cse || 1 || || eliza || 1 || || lift || 1 || || mkhprog || 1 || || prolog || 1 || || sorting || 1 || || veritas || 1 || || knights || 2 || || minimax || 2 || || x2n1 || 2 || || mandel2 || 3 || || parstof || 3 || || fluid || 4 || || pic || 4 || || boyer2 || 5 || || bspt || 5 || || cryptarithm2 || 5 || || fish || 6 || || gg || 6 || || reptile || 6 || || symalg || 6 || || tak || 6 || || VSD || 7 || || rfib || 7 || || queens || 9 || || rewrite || 9 || || sched || 11 || || fem || 12 || || fibheaps || 13 || || parser || 14 || || rsa || 14 || || genfft || 15 || || clausify || ansi || 0 || || awards || 0 || || banner || 0 || || calendar || 0 || || expert || 0 || || gen_regexps || 0 || || grep || 0 || || pretty || 0 || || scc || 0 || || cse || 1 || || eliza || 1 || || lift || 1 || || mkhprog || 1 || || prolog || 1 || || sorting || 1 || || veritas || 1 || || knights || 2 || || minimax || 2 || || x2n1 || 2 || || mandel2 || 3 || || parstof || 3 || || fluid || 4 || || pic || 4 || || boyer2 || 5 || || bspt || 5 || || cryptarithm2 || 5 || || fish || 6 || || gg || 6 || || reptile || 6 || || symalg || 6 || || tak || 6 || || VSD || 7 || || rfib || 7 || || queens || 9 || || rewrite || 9 || || sched || 11 || || fem || 12 || || fibheaps || 13 || || parser || 14 || || rsa || 14 || || genfft || 15 || || clausify || 17 || || gamteb || 17 || || fft || 18 || || boyer || 20 || || gcd || 20 || || sphere || 21 || || fft2 || 23 || || infer || 25 || || maillist || 25 || || mandel || 27 || || nucleic2 || 30 || || primes || 34 || || cichelli || 35 || || ida || 39 || || listcompr || 41 || || listcopy || 43 || || multiplier || 43 || || wang || 43 || || hpg || 45 || || anna || 46 || || reverse-complem || 46 || || integrate || 48 || || primetest || 50 || || paraffins || 54 || || solid || 54 || || puzzle || 55 || || treejoin || 61 || || compress2 || 64 || || compress || 65 || || event || 65 || || bernouilli || 74 || || comp_lab_zift || 78 || || simple || 86 || || wheel-sieve2 || 91 || || life || 100 || || exp3_8 || 102 || || wave4main || 103 || || typecheck || 106 || || atom || 110 || || fulsom || 112 || || CS || 116 || || para || 120 || || kahan || 138 || || transform || 145 || || power || 150 || || cacheprof || 151 || || hidden || 160 || || scs || 168 || || lcss || 175 || || wheel-sieve1 || 199 || || VS || 204 || || pidigits || 216 || || FS || 222 || || last-piece || 230 || || fasta || 263 || || cryptarithm1 || 264 || || CSD || 272 || || digits-of-e1 || 273 || || binary-trees || 342 || || digits-of-e2 || 381 || || circsim || 418 || || S || 451 || || VSM || 497 || || lambda || 617 || || integer || 905 || || n-body || 1043 || || linear || 1070 || || spectral-norm || 1132 || || constraints || 1171 || || exact-reals || 1289 || || mate || 1955 || || fannkuch-redux || 2185 || || k-nucleotide || 2989 || || 17 || || gamteb || 17 || || fft || 18 || || boyer || 20 || || gcd || 20 || || sphere || 21 || || fft2 || 23 || || infer || 25 || || maillist || 25 || || mandel || 27 || || nucleic2 || 30 || || primes || 34 || || cichelli || 35 || || ida || 39 || || listcompr || 41 || || listcopy || 43 || || multiplier || 43 || || wang || 43 || || hpg || 45 || || anna || 46 || || reverse-complem || 46 || || integrate || 48 || || primetest || 50 || || paraffins || 54 || || solid || 54 || || puzzle || 55 || || treejoin || 61 || || compress2 || 64 || || compress || 65 || || event || 65 || || bernouilli || 74 || || comp_lab_zift || 78 || || simple || 86 || || wheel-sieve2 || 91 || || life || 100 || || exp3_8 || 102 || || wave4main || 103 || || typecheck || 106 || || atom || 110 || || fulsom || 112 || || CS || 116 || || para || 120 || || kahan || 138 || || transform || 145 || || power || 150 || || cacheprof || 151 || || hidden || 160 || || scs || 168 || || lcss || 175 || || wheel-sieve1 || 199 || || VS || 204 || || pidigits || 216 || || FS || 222 || || last-piece || 230 || || fasta || 263 || || cryptarithm1 || 264 || || CSD || 272 || || digits-of-e1 || 273 || || binary-trees || 342 || || digits-of-e2 || 381 || || circsim || 418 || || S || 451 || || VSM || 497 || || lambda || 617 || || integer || 905 || || n-body || 1043 || || linear || 1070 || || spectral-norm || 1132 || || constraints || 1171 || || exact-reals || 1289 || || mate || 1955 || || fannkuch-redux || 2185 || || k-nucleotide || 2989 || -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 16:31:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 16:31:58 -0000 Subject: [GHC] #15357: Make nofib suitable for runtime measurements. In-Reply-To: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> References: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> Message-ID: <062.dfc4db7dda6b1962318cce12ee16ddc9@haskell.org> #15357: Make nofib suitable for runtime measurements. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: NoFib benchmark | Version: 8.4.3 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): Wiki Page: | -------------------------------------+------------------------------------- Old description: > Currently many benchmarks in a default nofib run have runtimes so low > that they become meaningless. > > This comes with a bunch of issues: > * It takes up build/runtime while not actually improving the accuracy of > runtime measurements. > * It skews results as the jump from 1ms to 2ms registers as a 200% > change. > * It can hide regression which fall outside of the measured granularity. > * Higher number of runs per benchmark spend far too much time on the few > slower benchmarks. > > At the extreme end there are 9 benchmarks with runtimes shorter than the > granularity of 1ms. > > For some benchmarks changing this might be as easy as increasing the > number of runs/iterations. > For others changing problem sizes is not as easy since they process more > complex input data. > > Below are the runtimes of a recent default nofib run. > > ||= benchmark =|| Time (ms) || > || ansi || 0 || > || awards || 0 || > || banner || 0 || > || calendar || 0 || > || expert || 0 || > || gen_regexps || 0 || > || grep || 0 || > || pretty || 0 || > || scc || 0 || > || cse || 1 || > || eliza || 1 || > || lift || 1 || > || mkhprog || 1 || > || prolog || 1 || > || sorting || 1 || > || veritas || 1 || > || knights || 2 || > || minimax || 2 || > || x2n1 || 2 || > || mandel2 || 3 || > || parstof || 3 || > || fluid || 4 || > || pic || 4 || > || boyer2 || 5 || > || bspt || 5 || > || cryptarithm2 || 5 || > || fish || 6 || > || gg || 6 || > || reptile || 6 || > || symalg || 6 || > || tak || 6 || > || VSD || 7 || > || rfib || 7 || > || queens || 9 || > || rewrite || 9 || > || sched || 11 || > || fem || 12 || > || fibheaps || 13 || > || parser || 14 || > || rsa || 14 || > || genfft || 15 || > || clausify || ansi || 0 || > || awards || 0 || > || banner || 0 || > || calendar || 0 || > || expert || 0 || > || gen_regexps || 0 || > || grep || 0 || > || pretty || 0 || > || scc || 0 || > || cse || 1 || > || eliza || 1 || > || lift || 1 || > || mkhprog || 1 || > || prolog || 1 || > || sorting || 1 || > || veritas || 1 || > || knights || 2 || > || minimax || 2 || > || x2n1 || 2 || > || mandel2 || 3 || > || parstof || 3 || > || fluid || 4 || > || pic || 4 || > || boyer2 || 5 || > || bspt || 5 || > || cryptarithm2 || 5 || > || fish || 6 || > || gg || 6 || > || reptile || 6 || > || symalg || 6 || > || tak || 6 || > || VSD || 7 || > || rfib || 7 || > || queens || 9 || > || rewrite || 9 || > || sched || 11 || > || fem || 12 || > || fibheaps || 13 || > || parser || 14 || > || rsa || 14 || > || genfft || 15 || > || clausify || 17 || > || gamteb || 17 || > || fft || 18 || > || boyer || 20 || > || gcd || 20 || > || sphere || 21 || > || fft2 || 23 || > || infer || 25 || > || maillist || 25 || > || mandel || 27 || > || nucleic2 || 30 || > || primes || 34 || > || cichelli || 35 || > || ida || 39 || > || listcompr || 41 || > || listcopy || 43 || > || multiplier || 43 || > || wang || 43 || > || hpg || 45 || > || anna || 46 || > || reverse-complem || 46 || > || integrate || 48 || > || primetest || 50 || > || paraffins || 54 || > || solid || 54 || > || puzzle || 55 || > || treejoin || 61 || > || compress2 || 64 || > || compress || 65 || > || event || 65 || > || bernouilli || 74 || > || comp_lab_zift || 78 || > || simple || 86 || > || wheel-sieve2 || 91 || > || life || 100 || > || exp3_8 || 102 || > || wave4main || 103 || > || typecheck || 106 || > || atom || 110 || > || fulsom || 112 || > || CS || 116 || > || para || 120 || > || kahan || 138 || > || transform || 145 || > || power || 150 || > || cacheprof || 151 || > || hidden || 160 || > || scs || 168 || > || lcss || 175 || > || wheel-sieve1 || 199 || > || VS || 204 || > || pidigits || 216 || > || FS || 222 || > || last-piece || 230 || > || fasta || 263 || > || cryptarithm1 || 264 || > || CSD || 272 || > || digits-of-e1 || 273 || > || binary-trees || 342 || > || digits-of-e2 || 381 || > || circsim || 418 || > || S || 451 || > || VSM || 497 || > || lambda || 617 || > || integer || 905 || > || n-body || 1043 || > || linear || 1070 || > || spectral-norm || 1132 || > || constraints || 1171 || > || exact-reals || 1289 || > || mate || 1955 || > || fannkuch-redux || 2185 || > || k-nucleotide || 2989 || > || 17 || > || gamteb || 17 || > || fft || 18 || > || boyer || 20 || > || gcd || 20 || > || sphere || 21 || > || fft2 || 23 || > || infer || 25 || > || maillist || 25 || > || mandel || 27 || > || nucleic2 || 30 || > || primes || 34 || > || cichelli || 35 || > || ida || 39 || > || listcompr || 41 || > || listcopy || 43 || > || multiplier || 43 || > || wang || 43 || > || hpg || 45 || > || anna || 46 || > || reverse-complem || 46 || > || integrate || 48 || > || primetest || 50 || > || paraffins || 54 || > || solid || 54 || > || puzzle || 55 || > || treejoin || 61 || > || compress2 || 64 || > || compress || 65 || > || event || 65 || > || bernouilli || 74 || > || comp_lab_zift || 78 || > || simple || 86 || > || wheel-sieve2 || 91 || > || life || 100 || > || exp3_8 || 102 || > || wave4main || 103 || > || typecheck || 106 || > || atom || 110 || > || fulsom || 112 || > || CS || 116 || > || para || 120 || > || kahan || 138 || > || transform || 145 || > || power || 150 || > || cacheprof || 151 || > || hidden || 160 || > || scs || 168 || > || lcss || 175 || > || wheel-sieve1 || 199 || > || VS || 204 || > || pidigits || 216 || > || FS || 222 || > || last-piece || 230 || > || fasta || 263 || > || cryptarithm1 || 264 || > || CSD || 272 || > || digits-of-e1 || 273 || > || binary-trees || 342 || > || digits-of-e2 || 381 || > || circsim || 418 || > || S || 451 || > || VSM || 497 || > || lambda || 617 || > || integer || 905 || > || n-body || 1043 || > || linear || 1070 || > || spectral-norm || 1132 || > || constraints || 1171 || > || exact-reals || 1289 || > || mate || 1955 || > || fannkuch-redux || 2185 || > || k-nucleotide || 2989 || New description: Currently many benchmarks in a default nofib run have runtimes so low that they become meaningless. This comes with a bunch of issues: * It takes up build/runtime while not actually improving the accuracy of runtime measurements. * It skews results as the jump from 1ms to 2ms registers as a 200% change. * It can hide regression which fall outside of the measured granularity. * Higher number of runs per benchmark spend far too much time on the few slower benchmarks. At the extreme end there are 9 benchmarks with runtimes shorter than the granularity of 1ms. For some benchmarks changing this might be as easy as increasing the number of runs/iterations. For others changing problem sizes is not as easy since they process more complex input data. Below are the runtimes of a recent default nofib run. ||= benchmark =|| Time (ms) || || ansi || 0 || || awards || 0 || || banner || 0 || || calendar || 0 || || expert || 0 || || gen_regexps || 0 || || grep || 0 || || pretty || 0 || || scc || 0 || || cse || 1 || || eliza || 1 || || lift || 1 || || mkhprog || 1 || || prolog || 1 || || sorting || 1 || || veritas || 1 || || knights || 2 || || minimax || 2 || || x2n1 || 2 || || mandel2 || 3 || || parstof || 3 || || fluid || 4 || || pic || 4 || || boyer2 || 5 || || bspt || 5 || || cryptarithm2 || 5 || || fish || 6 || || gg || 6 || || reptile || 6 || || symalg || 6 || || tak || 6 || || VSD || 7 || || rfib || 7 || || queens || 9 || || rewrite || 9 || || sched || 11 || || fem || 12 || || fibheaps || 13 || || parser || 14 || || rsa || 14 || || genfft || 15 || || clausify || 17 || || gamteb || 17 || || fft || 18 || || boyer || 20 || || gcd || 20 || || sphere || 21 || || fft2 || 23 || || infer || 25 || || maillist || 25 || || mandel || 27 || || nucleic2 || 30 || || primes || 34 || || cichelli || 35 || || ida || 39 || || listcompr || 41 || || listcopy || 43 || || multiplier || 43 || || wang || 43 || || hpg || 45 || || anna || 46 || || reverse-complem || 46 || || integrate || 48 || || primetest || 50 || || paraffins || 54 || || solid || 54 || || puzzle || 55 || || treejoin || 61 || || compress2 || 64 || || compress || 65 || || event || 65 || || bernouilli || 74 || || comp_lab_zift || 78 || || simple || 86 || || wheel-sieve2 || 91 || || life || 100 || || exp3_8 || 102 || || wave4main || 103 || || typecheck || 106 || || atom || 110 || || fulsom || 112 || || CS || 116 || || para || 120 || || kahan || 138 || || transform || 145 || || power || 150 || || cacheprof || 151 || || hidden || 160 || || scs || 168 || || lcss || 175 || || wheel-sieve1 || 199 || || VS || 204 || || pidigits || 216 || || FS || 222 || || last-piece || 230 || || fasta || 263 || || cryptarithm1 || 264 || || CSD || 272 || || digits-of-e1 || 273 || || binary-trees || 342 || || digits-of-e2 || 381 || || circsim || 418 || || S || 451 || || VSM || 497 || || lambda || 617 || || integer || 905 || || n-body || 1043 || || linear || 1070 || || spectral-norm || 1132 || || constraints || 1171 || || exact-reals || 1289 || || mate || 1955 || || fannkuch-redux || 2185 || || k-nucleotide || 2989 || -- Comment (by AndreasK): Formatting fix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 16:34:28 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 16:34:28 -0000 Subject: [GHC] #15349: fixST is a bit wrong In-Reply-To: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> References: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> Message-ID: <060.303878d4927874c4e5c2374e1c0572bf@haskell.org> #15349: fixST is a bit wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: (none) => dfeuer Comment: I raised this issue on the libraries list. Levent Erkök was [https://mail.haskell.org/pipermail/libraries/2018-July/028888.html first to respond]. He recognized that this bug leads to a violation of the `MonadFix` laws, and surprising behavior, but that it was harmless enough to get away with just documenting it. Then Arseniy Alekseyev came up with [https://mail.haskell.org/pipermail/libraries/2018-July/028889.html a more frightening example], in which this feature of `fixST` turns safe code using unsafe operations into unsafe code. That was enough to [https://mail.haskell.org/pipermail/libraries/2018-July/028892.html tilt Edward Kmett] toward fixing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 16:39:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 16:39:24 -0000 Subject: [GHC] #15349: fixST is a bit wrong In-Reply-To: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> References: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> Message-ID: <060.3a84ab54ad89590c2a6a9ee1c6a279a9@haskell.org> #15349: fixST is a bit wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:1 simonmar]: > Wow, good catch. I suppose we should do what `fixIO` does, since this is clearly wrong. But maybe there's a way to do it with `IORef` that would be cheaper than `MVar`? (we'd need benchmarks to check, though) I don't think there is. I believe that runs into the same problem as `unsafeFixIO`: trouble with multiple threads. In `fixST f`, `f` may spark computations (`runEval`, `runPar`, etc.) that demand the final result; those should block until the result is available. Just like `fixIO`, what we really want here is an `IVar`, and we don't (yet?) have those natively. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 16:45:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 16:45:45 -0000 Subject: [GHC] #15343: Implicitly quantifying a kind variable causes GHC 8.6 to panic (coercionKind) In-Reply-To: <050.0e8877c07406b2b81b1a5431ef627da1@haskell.org> References: <050.0e8877c07406b2b81b1a5431ef627da1@haskell.org> Message-ID: <065.deedfd5648d8699bfe623bf7da9bec78@haskell.org> #15343: Implicitly quantifying a kind variable causes GHC 8.6 to panic (coercionKind) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm on this. It turns out to be a very dark corner. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 16:57:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 16:57:26 -0000 Subject: [GHC] #15349: fixST is a bit wrong In-Reply-To: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> References: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> Message-ID: <060.93d3af6bb8a875655a6189a235992d21@haskell.org> #15349: fixST is a bit wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): The only alternative I see for now is to use `noDuplicate#` to fix up the implementation, like maybe {{{#!hs fixST :: (a -> ST s a) -> ST s a fixST k = ST $ \ s -> let ans = liftST (noDuplicate >> k r) s STret _ r = ans in case ans of STret s' x -> (# s', x #) }}} That implementation is also available for `fixIO`, of course. I don't have a terribly good sense of how it would compare. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 17:50:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 17:50:51 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.53470109506e54091f5ec4fb4cf5e96d@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | roles/should_compile/Roles2 Blocked By: | Blocking: Related Tickets: #9164 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): goldfire, this gets back to what we discussed in Philly. What we *really* want is for `Ptr` to be defined with a phantom argument, but exported with a representational one. We can work around the trouble today using a newtype: {{{#!hs data Addr = Addr Addr# newtype Ptr a = Ptr_ Addr type role Ptr representational pattern Ptr :: Addr# -> Ptr a pattern Ptr addr# = Ptr_ (Addr addr#) castPtr :: Ptr a -> Ptr b castPtr = coerce ptrCoercion :: Coercion (Ptr a) (Ptr b) ptrCoercion = Coercion }}} The only trouble I see is that the `Generic` representation will change. I kind of doubt anyone's relying on the details of that representation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 17:51:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 17:51:12 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.e2711c7027943a9898eca890659fd35d@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | roles/should_compile/Roles2 Blocked By: | Blocking: Related Tickets: #9164 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 18:52:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 18:52:04 -0000 Subject: [GHC] #15260: Xmobar crashes with segmentation fault In-Reply-To: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> References: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> Message-ID: <061.d590d1887d417254ef7ee578d53b2e64@haskell.org> #15260: Xmobar crashes with segmentation fault ----------------------------------+-------------------------------------- Reporter: Voronwe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by duncancmt): This bug has a ticket open on the Arch tracker https://bugs.archlinux.org/task/58795 . I have had no luck coming up with a reliable way to reproduce this behavior. I'm sure you've already seen these, but #14346 and #13707 seem possibly related to this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 20:15:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 20:15:34 -0000 Subject: [GHC] #15349: fixST is a bit wrong In-Reply-To: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> References: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> Message-ID: <060.212653b50236c959c9330304fe5fb8b4@haskell.org> #15349: fixST is a bit wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lerkok): Update: I cannot replicate Arseniy's example with GHC 8.4.2. He says that he's observing it on GHC 8.2.2; but I don't have that version lying around to replicate. With 8.4.2, Arseniy's example produces 0 with no-eager-blackholing, and <> with eager-blackholing; so it's about the same as with David's original example in terms of brokenness. So, something got fixed between 8.4.2 and 8.2.2 that the seg-fault disappeared. This doesn't mean Arseniy's example can't be replicated on 8.4.2. I think the next step should be to replicate that on latest GHC and decide from there. (Or, if we can't replicate, figure out what got it fixed.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 20:16:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 20:16:13 -0000 Subject: [GHC] #15349: fixST is a bit wrong In-Reply-To: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> References: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> Message-ID: <060.9b4e9850d5dd608dd9b2d38e3b8ec159@haskell.org> #15349: fixST is a bit wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lerkok): * cc: lerkok (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 20:46:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 20:46:01 -0000 Subject: [GHC] #15349: fixST is a bit wrong In-Reply-To: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> References: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> Message-ID: <060.2961541d544a671765d1ff25fae2eaa0@haskell.org> #15349: fixST is a bit wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rotsor): I don't have GHC 8.4.2. I tried with 8.4.3 and it does segfault. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 21:30:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 21:30:09 -0000 Subject: [GHC] #14929: Program compiled with -O2 exhibits much worse performance In-Reply-To: <049.ba205f50f7e92bd0b7f0e4b08e0f1c92@haskell.org> References: <049.ba205f50f7e92bd0b7f0e4b08e0f1c92@haskell.org> Message-ID: <064.d7964f765c3314d4610f437a5ec8d267@haskell.org> #14929: Program compiled with -O2 exhibits much worse performance -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.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 George): According to https://www.reddit.com/r/haskell/comments/84qovv/an_example_of_code_where_ghcs_o2_makes_things/ it's now down to 60 lines but I don't see any way to get those 60 lines: https://www.reddit.com/r/haskell/comments/84qovv/an_example_of_code_where_ghcs_o2_makes_things/dvshdb8 Also according to that page, compiling with -fno-full-laziness is a workaround -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 21:39:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 21:39:56 -0000 Subject: [GHC] #14091: When PolyKinds is on, suggested type signatures seem to require TypeInType In-Reply-To: <048.fd1cdc8104a91800836507c43b8b5124@haskell.org> References: <048.fd1cdc8104a91800836507c43b8b5124@haskell.org> Message-ID: <063.9123531bd700546fa94e75ab7617434b@haskell.org> #14091: When PolyKinds is on, suggested type signatures seem to require TypeInType -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: wontfix | Keywords: TypeInType, | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => wontfix Comment: We no longer distinguish between TypeInType and PolyKinds, so I'm closing this ticket. See ​https://github.com/ghc-proposals/ghc- proposals/blob/master/proposals/0020-no-type-in-type.rst and #15195 for more details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 21:42:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 21:42:46 -0000 Subject: [GHC] #12928: Too easy to trigger CUSK condition using TH In-Reply-To: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> References: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> Message-ID: <063.54fa94eb1fe673ea8e7afd7b03b9c033@haskell.org> #12928: Too easy to trigger CUSK condition using TH -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | CUSKs Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: GHCProposal (added) Comment: See https://github.com/ghc-proposals/ghc-proposals/pull/54 for the GHC proposal alluded to in comment:9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 21:43:30 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 21:43:30 -0000 Subject: [GHC] #12928: Too easy to trigger CUSK condition using TH In-Reply-To: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> References: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> Message-ID: <063.13d54858bcc5479718217adf94d77ad0@haskell.org> #12928: Too easy to trigger CUSK condition using TH -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | CUSKs, GHCProposal Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: TypeInType, CUSKs => TypeInType, CUSKs, GHCProposal * cc: GHCProposal (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 21:50:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 21:50:58 -0000 Subject: [GHC] #13109: CUSK improvements In-Reply-To: <046.19ae04c2da59427623532feabc0338e7@haskell.org> References: <046.19ae04c2da59427623532feabc0338e7@haskell.org> Message-ID: <061.a78c71a120257311a15047ba4f76421d@haskell.org> #13109: CUSK improvements -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Did commit 12794287174146f982257cdeffd491e3e23838dc fix this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 22:01:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 22:01:03 -0000 Subject: [GHC] #11282: Error warns about non-injectivity of injective type family In-Reply-To: <047.508834a153eecaeec4a5e4aca0387e2b@haskell.org> References: <047.508834a153eecaeec4a5e4aca0387e2b@haskell.org> Message-ID: <062.fa2171b7268766bbdff161a9215be042@haskell.org> #11282: Error warns about non-injectivity of injective type family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: duplicate | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #14369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #14369 Comment: Closing as a duplicate of #14369. After commit 8846a7fdcf2060dd37e66b4d1f89bd8fdfad4620 (which fixed #14369), the error message no longer claims that `F` may not be injective: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs -XTypeFamilyDependencies [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:10:9: error: • Could not deduce: F a ~ F a0 from the context: G a0 bound by the type signature for: meth :: G a0 => F a0 at Bug.hs:10:9-26 The type variable ‘a0’ is ambiguous • In the ambiguity check for ‘meth’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature: meth :: (G a => F a) -> () | 10 | meth :: (G a => F a) -> () | ^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 9 22:04:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 09 Jul 2018 22:04:52 -0000 Subject: [GHC] #11070: Type-level arithmetic of sized-types has weaker inference power than in 7.8 In-Reply-To: <045.53eceb5327c44565612d8182117e7c77@haskell.org> References: <045.53eceb5327c44565612d8182117e7c77@haskell.org> Message-ID: <060.2b285bc0f6a215dda46e2c3a5588b9a6@haskell.org> #11070: Type-level arithmetic of sized-types has weaker inference power than in 7.8 -------------------------------------+------------------------------------- Reporter: cactus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Amusingly enough, this now typechecks again on GHC 8.0 and later. Is this a good thing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 01:15:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 01:15:18 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.9a5802281ed36f3b784e8b19cf96eb53@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | roles/should_compile/Roles2 Blocked By: | Blocking: Related Tickets: #9164 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): comment:38 may indeed work. But `Ptr` is baked into the compiler in places, so you'll have to tread carefully if you update it. Specifically, look at `normaliseFfiType'`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 01:16:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 01:16:29 -0000 Subject: [GHC] #13109: CUSK improvements In-Reply-To: <046.19ae04c2da59427623532feabc0338e7@haskell.org> References: <046.19ae04c2da59427623532feabc0338e7@haskell.org> Message-ID: <061.3bbb4e1b0d7e54b1975186f9ef8ed3cd@haskell.org> #13109: CUSK improvements -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: TypeInType, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: Yes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 01:20:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 01:20:52 -0000 Subject: [GHC] #11070: Type-level arithmetic of sized-types has weaker inference power than in 7.8 In-Reply-To: <045.53eceb5327c44565612d8182117e7c77@haskell.org> References: <045.53eceb5327c44565612d8182117e7c77@haskell.org> Message-ID: <060.340dcc829412e117ee834ff8329977b4@haskell.org> #11070: Type-level arithmetic of sized-types has weaker inference power than in 7.8 -------------------------------------+------------------------------------- Reporter: cactus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): We're in the borderlands here, according to comment:4. I think accepting is an improvement, yes. I don't terribly want to add this as a test case, though, because I'm worried that keeping that test case working will limit our flexibility when working on the solver. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 01:38:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 01:38:53 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.891c0baadade0be9cee8940fdd19fb67@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"55a3f8552c9dc9b84e204ec6623c698912795347/ghc" 55a3f85/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="55a3f8552c9dc9b84e204ec6623c698912795347" Refactor coercion rule Summary: The patch is an attempt on #15192. It defines a new coercion rule ``` | GRefl Role Type MCoercion ``` which correspondes to the typing rule ``` t1 : k1 ------------------------------------ GRefl r t1 MRefl: t1 ~r t1 t1 : k1 co :: k1 ~ k2 ------------------------------------ GRefl r t1 (MCo co) : t1 ~r t1 |> co ``` MCoercion wraps a coercion, which might be reflexive (MRefl) or not (MCo co). To know more about MCoercion see #14975. We keep Refl ty as a special case for nominal reflexive coercions, naemly, Refl ty :: ty ~n ty. This commit is meant to be a general performance improvement, but there are a few regressions. See #15192, comment:13 for more information. Test Plan: ./validate Reviewers: bgamari, goldfire, simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15192 Differential Revision: https://phabricator.haskell.org/D4747 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 01:38:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 01:38:53 -0000 Subject: [GHC] #14975: Refactor (Maybe Coercion) In-Reply-To: <047.51816057ba89e62ff311692e8071c67c@haskell.org> References: <047.51816057ba89e62ff311692e8071c67c@haskell.org> Message-ID: <062.21076c7d255089196b48c03367e787b1@haskell.org> #14975: Refactor (Maybe Coercion) -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11735 | Differential Rev(s): Phab:D4699 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"55a3f8552c9dc9b84e204ec6623c698912795347/ghc" 55a3f85/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="55a3f8552c9dc9b84e204ec6623c698912795347" Refactor coercion rule Summary: The patch is an attempt on #15192. It defines a new coercion rule ``` | GRefl Role Type MCoercion ``` which correspondes to the typing rule ``` t1 : k1 ------------------------------------ GRefl r t1 MRefl: t1 ~r t1 t1 : k1 co :: k1 ~ k2 ------------------------------------ GRefl r t1 (MCo co) : t1 ~r t1 |> co ``` MCoercion wraps a coercion, which might be reflexive (MRefl) or not (MCo co). To know more about MCoercion see #14975. We keep Refl ty as a special case for nominal reflexive coercions, naemly, Refl ty :: ty ~n ty. This commit is meant to be a general performance improvement, but there are a few regressions. See #15192, comment:13 for more information. Test Plan: ./validate Reviewers: bgamari, goldfire, simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15192 Differential Revision: https://phabricator.haskell.org/D4747 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 05:17:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 05:17:34 -0000 Subject: [GHC] #15206: Strictness annotations bind more tightly than doc strings on non-record data declarations In-Reply-To: <050.d27d0e7d2edeaad12b554d4fccd90f3f@haskell.org> References: <050.d27d0e7d2edeaad12b554d4fccd90f3f@haskell.org> Message-ID: <065.853f363e1acef6f8169fd135fad25022@haskell.org> #15206: Strictness annotations bind more tightly than doc strings on non-record data declarations -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4727 Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => closed * resolution: => fixed Comment: Replying to [comment:1 bgamari]: > These won't be addressed for GHC 8.6. But this has already been fixed in 8.6! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 05:18:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 05:18:08 -0000 Subject: [GHC] #15206: Strictness annotations bind more tightly than doc strings on non-record data declarations In-Reply-To: <050.d27d0e7d2edeaad12b554d4fccd90f3f@haskell.org> References: <050.d27d0e7d2edeaad12b554d4fccd90f3f@haskell.org> Message-ID: <065.2315ad8b8dc31fda591c5362a37ede4f@haskell.org> #15206: Strictness annotations bind more tightly than doc strings on non-record data declarations -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4727 Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * milestone: 8.8.1 => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 05:25:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 05:25:56 -0000 Subject: [GHC] #8822: Allow -- ^ Haddock syntax on record constructors In-Reply-To: <047.9e31292a58062fe675a519afe89cb025@haskell.org> References: <047.9e31292a58062fe675a519afe89cb025@haskell.org> Message-ID: <062.72703338fcca3ab3346c7d7f17f4cbb8@haskell.org> #8822: Allow -- ^ Haddock syntax on record constructors -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9770, #12050 | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D4094 -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => closed * resolution: => fixed Comment: Fixed in GHC 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 05:26:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 05:26:42 -0000 Subject: [GHC] #12050: Allow haddock comments on non-record types In-Reply-To: <046.f6b7a2b632eb5ba65b0da9770c2d4b66@haskell.org> References: <046.f6b7a2b632eb5ba65b0da9770c2d4b66@haskell.org> Message-ID: <061.81b6917e7d263385db283d348130ed20@haskell.org> #12050: Allow haddock comments on non-record types -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8822 | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D4094 -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => closed * resolution: => fixed Comment: Fixed in GHC 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 09:13:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 09:13:23 -0000 Subject: [GHC] #14231: Core lint error "in result of Static argument" In-Reply-To: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> References: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> Message-ID: <064.3b8d3a30e350a90aeb69bc531462f07a@haskell.org> #14231: Core lint error "in result of Static argument" -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4945 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Crumbs -- code in `SAT.hs` is extremely impenetrable. But it is mainly doing the right thing; the "weird cloning" is nearly right. Here's an example {{{ f :: forall a b. (a,b) -> b -> Int f = /\a b. \(x:(a,b)) (y:b). where is an expression mentioning a, b, x, y and with recursive calls like (f b y) where presumably :: (,b) Here the second type argument `b`, and the second value argument `y::b`, are static. The first type arg `a` and value arg `x::(a,b)` are dynamic. The body of `f` may mention any or all of `a`, `b`, `x`, `y`. We want to generate this: {{{ f :: forall a b. (a,b) -> b -> Int f = /\a b. \(x:(a,b)) (y:b). letrec fwrk = /\a \(x:(a,b). REPLACE (f b y) WITH (fwrk ) IN in fwrk a x }}} Here `fwrk` is the local, recursive worker, which has free variables `b`' and `y::b`. Notice that the binders of `fwrk`, namely `a` and `x::(a,b)` must be identical (same unique) as the originals, because they are mentioned in ``. What is this "REPLACE" business? We want to replace a recusive call to `f` with a call to `fwrk`. The easy way to do this is with a non-recursive let, later inlined: {{{ f = /\a b \(x::(a,b) (y::b). fwrk a x }}} We must use the ''same'' unique for `f`: we are deliberately shadowing its outer binding. Contrary to the claims in `Note [Binder type capture]` I don't think it matters whether or not we clone the lambda binders; we are free to alpha-rename the lambda as we please, including re-using existing binders. So the bugs seem to be: * In `bindWith` (comment:8) we are abstracting over the type variable, ''but it is static''. This is the real source of the problem. In my example above, note that `b` was static but `a` was not. * Once we fix this we don't need to clone those binders at all; `Note [Binder type capture]` is moot. I also commented on a bug in the Phab. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 09:18:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 09:18:58 -0000 Subject: [GHC] #15349: fixST is a bit wrong In-Reply-To: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> References: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> Message-ID: <060.379cb2fc4a0255d847524f65fb3cb3a3@haskell.org> #15349: fixST is a bit wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4948 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D4948 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 09:21:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 09:21:59 -0000 Subject: [GHC] #14530: hWaitForInput causes the program to abort on Windows In-Reply-To: <047.b2bc1211baaf66413ffab8f8c11dbb08@haskell.org> References: <047.b2bc1211baaf66413ffab8f8c11dbb08@haskell.org> Message-ID: <062.87d3993bf013e4769e76cb86f560bd44@haskell.org> #14530: hWaitForInput causes the program to abort on Windows -----------------------------------+-------------------------------------- Reporter: dnadales | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by dnadales): That'd be great. Let me know if I can help somehow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 10:18:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 10:18:17 -0000 Subject: [GHC] #15357: Make nofib suitable for runtime measurements. In-Reply-To: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> References: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> Message-ID: <062.9331114ecf8e2ccec4a7c970cd18009e@haskell.org> #15357: Make nofib suitable for runtime measurements. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: NoFib benchmark | Version: 8.4.3 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 10:46:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 10:46:42 -0000 Subject: [GHC] #14231: Core lint error "in result of Static argument" In-Reply-To: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> References: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> Message-ID: <064.51cd0cae1da422c72c2c6c2e9a5f67bd@haskell.org> #14231: Core lint error "in result of Static argument" -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4945 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > In bindWith (comment:8) we are abstracting over the type variable, but it is static. This is the real source of the problem. In my example above, note that b was static but a was not. We introduce two new bindings: - `bindWith_r1` this is the wrapper (or "shadowing" binding). This has to have the exact same type with the original binder (`bindWith`) because it'll shadow the original definition. This has a type arg because the original `bindWith` has one. - `sat_worker_s198` this is the actual worker function without static argument and because all arguments to `bindWith` are static this has no args. So in the actual worker we don't abstract over the static type argument. It seems to me that there isn't a problem with abstracting over static arguments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 11:45:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 11:45:11 -0000 Subject: [GHC] #15343: Implicitly quantifying a kind variable causes GHC 8.6 to panic (coercionKind) In-Reply-To: <050.0e8877c07406b2b81b1a5431ef627da1@haskell.org> References: <050.0e8877c07406b2b81b1a5431ef627da1@haskell.org> Message-ID: <065.17929d93debc22b8b43300814ac7925b@haskell.org> #15343: Implicitly quantifying a kind variable causes GHC 8.6 to panic (coercionKind) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"aedbf7f1c402ecbcb5ff192d5fb4dd6dd4771bf8/ghc" aedbf7f1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aedbf7f1c402ecbcb5ff192d5fb4dd6dd4771bf8" Fix decompsePiCos and visible type application Trac #15343 was caused by two things First, in TcHsType.tcHsTypeApp, which deals with the type argment in visible type application, we were failing to call solveLocalEqualities. But the type argument is like a user type signature so it's at least inconsitent not to do so. I thought that would nail it. But it didn't. It turned out that we were ended up calling decomposePiCos on a type looking like this (f |> co) Int where co :: (forall a. ty) ~ (t1 -> t2) Now, 'co' is insoluble, and we'll report that later. But meanwhile we don't want to crash in decomposePiCos. My fix involves keeping track of the type on both sides of the coercion, and ensuring that the outer shape matches before decomposing. I wish there was a simpler way to do this. But I think this one is at least robust. I suppose it is possible that the decomposePiCos fix would have cured the original report, but I'm leaving the one-line tcHsTypeApp fix in too because it just seems more consistent. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 11:45:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 11:45:11 -0000 Subject: [GHC] #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) In-Reply-To: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> References: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> Message-ID: <065.b6d0edf0536305dbe9cdfbc57335f8c6@haskell.org> #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"fd0f0334189c0c5c9b186bd1b009f706d3d86086/ghc" fd0f0334/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fd0f0334189c0c5c9b186bd1b009f706d3d86086" More refactoring in TcValidity This patch responds to Trac #15334 by making it an error to write an instance declaration for a tuple constraint like (Eq [a], Show [a]). I then discovered that instance validity checking was scattered betweeen TcInstDcls and TcValidity, so I took the time to bring it all together, into TcValidity.checkValidInstHead In doing so I discovered that there are lot of special cases. I have not changed them, but at least they are all laid out clearly now. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 11:45:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 11:45:11 -0000 Subject: [GHC] #14174: GHC panic with TypeInType and type family In-Reply-To: <045.87c0508a41a6d0d9834ba40ef8506297@haskell.org> References: <045.87c0508a41a6d0d9834ba40ef8506297@haskell.org> Message-ID: <060.4124454bb83c2956c24e10818b6218f3@haskell.org> #14174: GHC panic with TypeInType and type family -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.3 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | polykinds/T14174.hs, T14174a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"5067b205a8abb5a9f98335d3a929f647c88c0aa2/ghc" 5067b20/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5067b205a8abb5a9f98335d3a929f647c88c0aa2" Add nakedSubstTy and use it in TcHsType.tcInferApps This was a tricky one. During type checking we maintain TcType: Note [The well-kinded type invariant] That is, types are well-kinded /without/ zonking. But in tcInferApps we were destroying that invariant by calling substTy, which in turn uses smart constructors, which eliminate apparently-redundant Refl casts. This is horribly hard to debug beause they really are Refls and so it "ought" to be OK to discard them. But it isn't, as the above Note describes in some detail. Maybe we should review the invariant? But for now I just followed it, tricky thought it is. This popped up because (for some reason) when I fixed Trac #15343, that exposed this bug by making test polykinds/T14174a fail (in Trac #14174 which indeed has the same origin). So this patch fixes a long standing and very subtle bug. One interesting point: I defined nakedSubstTy in a few lines by using the generic mapType stuff. I note that the "normal" TyCoRep.substTy does /not/ use mapType. But perhaps it should: substTy has lots of $! strict applications in it, and they could all be eliminated just by useing the StrictIdentity monad. And that'd make it much easier to experiment with switching between strict and lazy versions. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 11:45:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 11:45:11 -0000 Subject: [GHC] #15343: Implicitly quantifying a kind variable causes GHC 8.6 to panic (coercionKind) In-Reply-To: <050.0e8877c07406b2b81b1a5431ef627da1@haskell.org> References: <050.0e8877c07406b2b81b1a5431ef627da1@haskell.org> Message-ID: <065.134f40633cef6e5058d4a9f9795e8c9d@haskell.org> #15343: Implicitly quantifying a kind variable causes GHC 8.6 to panic (coercionKind) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"5067b205a8abb5a9f98335d3a929f647c88c0aa2/ghc" 5067b20/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5067b205a8abb5a9f98335d3a929f647c88c0aa2" Add nakedSubstTy and use it in TcHsType.tcInferApps This was a tricky one. During type checking we maintain TcType: Note [The well-kinded type invariant] That is, types are well-kinded /without/ zonking. But in tcInferApps we were destroying that invariant by calling substTy, which in turn uses smart constructors, which eliminate apparently-redundant Refl casts. This is horribly hard to debug beause they really are Refls and so it "ought" to be OK to discard them. But it isn't, as the above Note describes in some detail. Maybe we should review the invariant? But for now I just followed it, tricky thought it is. This popped up because (for some reason) when I fixed Trac #15343, that exposed this bug by making test polykinds/T14174a fail (in Trac #14174 which indeed has the same origin). So this patch fixes a long standing and very subtle bug. One interesting point: I defined nakedSubstTy in a few lines by using the generic mapType stuff. I note that the "normal" TyCoRep.substTy does /not/ use mapType. But perhaps it should: substTy has lots of $! strict applications in it, and they could all be eliminated just by useing the StrictIdentity monad. And that'd make it much easier to experiment with switching between strict and lazy versions. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 11:51:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 11:51:17 -0000 Subject: [GHC] #14929: Program compiled with -O2 exhibits much worse performance In-Reply-To: <049.ba205f50f7e92bd0b7f0e4b08e0f1c92@haskell.org> References: <049.ba205f50f7e92bd0b7f0e4b08e0f1c92@haskell.org> Message-ID: <064.c63429232977d8eace018858dc1fa842@haskell.org> #14929: Program compiled with -O2 exhibits much worse performance -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.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 sgraf): Retainer profiling shows mentions this CAF: {{{ -- RHS size: {terms: 2, types: 3, coercions: 0, joins: 0/0} lvl24_r7ue :: conduit-1.2.13:Data.Conduit.Internal.Pipe.Pipe B.ByteString B.ByteString Data.Void.Void () (ResourceT IO) () [GblId] lvl24_r7ue = scc scc scc scc scc<>>=> scc<>>=.\> scc<>>=.\.\> scc<>>=> scc<>>=.\> scc<>>=.\.\> scc scc scc<>>=> scc<>>=.\> scc<>>=.\.\> tick<>>=> scc<>>=> scctick<>>=.\> countC_r7tY @ Data.Void.Void @ B.ByteString @ () lvl23_r7ud }}} `-fno-full-laziness` is a work-around, but maybe we should have a more granular way to influence float out. We probably still want to float lambdas, for example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 11:56:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 11:56:38 -0000 Subject: [GHC] #15354: QuantifiedConstraints not fully described in manual In-Reply-To: <047.918d0c77c6c735a247e6543296b4835e@haskell.org> References: <047.918d0c77c6c735a247e6543296b4835e@haskell.org> Message-ID: <062.c8eacbb7a597c800715cd000f7f55c1a@haskell.org> #15354: QuantifiedConstraints not fully described in manual -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"8ec2946048123f9278cf68eaf520104319a1f569/ghc" 8ec29460/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8ec2946048123f9278cf68eaf520104319a1f569" Optional context for a quantified constraint This is a documentation-only fix, addressing Trac #15354. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 11:58:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 11:58:13 -0000 Subject: [GHC] #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) In-Reply-To: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> References: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> Message-ID: <065.3dc876e763e6bb94560e881f5b4aaea5@haskell.org> #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: quantified- valid program | constraints/T15334 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => quantified-constraints/T15334 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 11:59:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 11:59:26 -0000 Subject: [GHC] #15343: Implicitly quantifying a kind variable causes GHC 8.6 to panic (coercionKind) In-Reply-To: <050.0e8877c07406b2b81b1a5431ef627da1@haskell.org> References: <050.0e8877c07406b2b81b1a5431ef627da1@haskell.org> Message-ID: <065.6bac11c55cc32bbf655b7c01842a62b8@haskell.org> #15343: Implicitly quantifying a kind variable causes GHC 8.6 to panic (coercionKind) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | dependent/should_fail/T15343 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => dependent/should_fail/T15343 Comment: I'd like Richard to check these patches, if he has time, but they are outright bugs and should probably move to the branch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 12:05:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 12:05:47 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.db1b2b7880adc8059fa1813f2831c1ab@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Could you maybe provide a quick summary of the exact performance trouble? I'm running some tests as we speak, but it would be easier for me if you could hint at some tests that produce particularly bad behavior, or maybe an example program on which GHC peforms badly after this patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 14:15:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 14:15:59 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.3c832f0510862947b991738538cd5de4@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): To be honest, I don't recall the details any more. But the problems show up in the performance tests, so running a validation should show them up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 14:25:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 14:25:30 -0000 Subject: [GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 In-Reply-To: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> References: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> Message-ID: <066.5629001540fb4f7ff0c8d5f38de679e3@haskell.org> #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Here's `-dshow-passes` with HEAD {{{ simonpj at cam-05-unx:~/tmp/cl3$ ~/5builds/HEAD-5/inplace/bin/ghc-stage2 -c -dshow-passes src/Algebra/Geometric/Cl3.hs -O2 Glasgow Haskell Compiler, Version 8.7.20180710, stage 2 booted by GHC version 8.2.2 Using binary package database: /home/simonpj/5builds/HEAD-5/inplace/lib/package.conf.d/package.cache Using binary package database: /home/simonpj/.ghc/x86_64-linux-8.7.20180710/package.conf.d/package.cache package flags [] loading package database /home/simonpj/5builds/HEAD-5/inplace/lib/package.conf.d loading package database /home/simonpj/.ghc/x86_64-linux-8.7.20180710/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.3 wired-in package integer-gmp mapped to integer-gmp-1.0.2.0 wired-in package base mapped to base-4.12.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.14.0.0 wired-in package ghc mapped to ghc-8.7 *** Checking old interface for Algebra.Geometric.Cl3 (use -ddump-hi-diffs for more details): *** Parser [Algebra.Geometric.Cl3]: !!! Parser [Algebra.Geometric.Cl3]: finished in 281.59 milliseconds, allocated 124.657 megabytes *** Renamer/typechecker [Algebra.Geometric.Cl3]: !!! Renamer/typechecker [Algebra.Geometric.Cl3]: finished in 1729.18 milliseconds, allocated 582.499 megabytes *** Desugar [Algebra.Geometric.Cl3]: Result size of Desugar (before optimization) = {terms: 46,524, types: 55,087, coercions: 2,210, joins: 0/9,539} Result size of Desugar (after optimization) = {terms: 26,825, types: 34,697, coercions: 4,390, joins: 1/660} !!! Desugar [Algebra.Geometric.Cl3]: finished in 463.17 milliseconds, allocated 198.217 megabytes *** Simplifier [Algebra.Geometric.Cl3]: Result size of Simplifier iteration=1 = {terms: 29,453, types: 35,248, coercions: 7,271, joins: 1/982} Result size of Simplifier iteration=2 = {terms: 26,430, types: 32,412, coercions: 5,036, joins: 1/207} Result size of Simplifier iteration=3 = {terms: 26,370, types: 32,315, coercions: 4,924, joins: 1/198} Result size of Simplifier = {terms: 26,370, types: 32,315, coercions: 4,924, joins: 1/198} !!! Simplifier [Algebra.Geometric.Cl3]: finished in 1478.89 milliseconds, allocated 532.541 megabytes *** Specialise [Algebra.Geometric.Cl3]: Result size of Specialise = {terms: 27,077, types: 33,084, coercions: 4,924, joins: 1/226} !!! Specialise [Algebra.Geometric.Cl3]: finished in 34.41 milliseconds, allocated 20.874 megabytes *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Algebra.Geometric.Cl3]: Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 29,888, types: 35,057, coercions: 4,924, joins: 1/217} !!! Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Algebra.Geometric.Cl3]: finished in 303.86 milliseconds, allocated 133.719 megabytes *** Simplifier [Algebra.Geometric.Cl3]: Result size of Simplifier iteration=1 = {terms: 109,632, types: 50,922, coercions: 4,826, joins: 183/7,875} Result size of Simplifier iteration=2 = {terms: 93,026, types: 52,819, coercions: 4,899, joins: 185/1,646} Result size of Simplifier iteration=3 = {terms: 135,959, types: 55,173, coercions: 4,892, joins: 99/2,772} Result size of Simplifier iteration=4 = {terms: 131,354, types: 52,485, coercions: 4,892, joins: 53/529} Result size of Simplifier = {terms: 131,354, types: 52,485, coercions: 4,892, joins: 53/529} !!! Simplifier [Algebra.Geometric.Cl3]: finished in 4415.46 milliseconds, allocated 1573.215 megabytes *** Simplifier [Algebra.Geometric.Cl3]: Result size of Simplifier iteration=1 = {terms: 130,205, types: 52,159, coercions: 4,892, joins: 37/519} Result size of Simplifier iteration=2 = {terms: 128,591, types: 51,440, coercions: 4,892, joins: 37/513} Result size of Simplifier = {terms: 128,591, types: 51,440, coercions: 4,892, joins: 37/513} !!! Simplifier [Algebra.Geometric.Cl3]: finished in 3285.00 milliseconds, allocated 1248.401 megabytes *** Simplifier [Algebra.Geometric.Cl3]: Result size of Simplifier iteration=1 = {terms: 129,119, types: 51,615, coercions: 4,892, joins: 37/538} Result size of Simplifier iteration=2 = {terms: 129,068, types: 51,555, coercions: 4,892, joins: 37/533} Result size of Simplifier = {terms: 129,068, types: 51,555, coercions: 4,892, joins: 37/533} !!! Simplifier [Algebra.Geometric.Cl3]: finished in 3415.70 milliseconds, allocated 1218.423 megabytes *** Float inwards [Algebra.Geometric.Cl3]: Result size of Float inwards = {terms: 129,068, types: 51,555, coercions: 4,892, joins: 37/533} !!! Float inwards [Algebra.Geometric.Cl3]: finished in 218.06 milliseconds, allocated 143.267 megabytes *** Called arity analysis [Algebra.Geometric.Cl3]: Result size of Called arity analysis = {terms: 129,068, types: 51,555, coercions: 4,892, joins: 37/533} !!! Called arity analysis [Algebra.Geometric.Cl3]: finished in 160.66 milliseconds, allocated 86.793 megabytes *** Simplifier [Algebra.Geometric.Cl3]: Result size of Simplifier = {terms: 129,068, types: 51,555, coercions: 4,892, joins: 37/533} !!! Simplifier [Algebra.Geometric.Cl3]: finished in 943.43 milliseconds, allocated 405.961 megabytes *** Demand analysis [Algebra.Geometric.Cl3]: Result size of Demand analysis = {terms: 129,068, types: 51,555, coercions: 4,892, joins: 37/533} !!! Demand analysis [Algebra.Geometric.Cl3]: finished in 1513.03 milliseconds, allocated 552.224 megabytes *** Worker Wrapper binds [Algebra.Geometric.Cl3]: Result size of Worker Wrapper binds = {terms: 130,487, types: 54,247, coercions: 4,892, joins: 38/701} !!! Worker Wrapper binds [Algebra.Geometric.Cl3]: finished in 36.37 milliseconds, allocated 10.774 megabytes *** Simplifier [Algebra.Geometric.Cl3]: Result size of Simplifier iteration=1 = {terms: 143,685, types: 58,766, coercions: 4,815, joins: 96/1,750} Result size of Simplifier iteration=2 = {terms: 175,579, types: 63,298, coercions: 4,815, joins: 173/1,293} C-c C-c*** Deleting temp files: *** Deleting temp dirs: }}} I had to stop it with ctrl-C -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 14:58:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 14:58:28 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.edc9c47091a6af3da58416360446de09@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => highest * owner: (none) => osa1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 17:48:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 17:48:13 -0000 Subject: [GHC] #15339: Add function equality instance for finite functions to base In-Reply-To: <045.f5bbef36b20a797130d19467b6f78cbc@haskell.org> References: <045.f5bbef36b20a797130d19467b6f78cbc@haskell.org> Message-ID: <060.dadddafde9c62bc5fc976f392360082b@haskell.org> #15339: Add function equality instance for finite functions to base -------------------------------------+------------------------------------- Reporter: madgen | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: libraries/base | Version: 8.4.3 Resolution: invalid | Keywords: base, | equality, function Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: This should really go to the `libraries at haskell.org` mailing list. Thanks for contributing here, but I will close this ticket as out of scope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 19:30:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 19:30:31 -0000 Subject: [GHC] #15358: no way to talk about unpacking sum types / unpacking tuples Message-ID: <046.10280472f5df7e66337f813b5dfe7fe0@haskell.org> #15358: no way to talk about unpacking sum types / unpacking tuples -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: unboxedsums, | Operating System: Unknown/Multiple unboxedtuples | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Suppose I have the following Haskell module: {{{#!hs {-# LANGUAGE BangPatterns #-} -- strict 'Maybe' data StrictMaybe a = SNothing | SJust !a -- lazy 'Maybe' data Maybe a = Nothing | Just a data BoxedInner = BoxedInner !Int !(Maybe Int) data StillBoxedInner = StillBoxedInner !Int !(StrictMaybe Int) mBoxed :: BoxedInner mBoxed = BoxedInner 0 (Just 0) mWantThisToUnbox :: StillBoxedInner mWantThisToUnbox = StillBoxedInner 1 (Just 1) }}} the 'StrictMaybe' can unbox the first 'Int' into 1#, but the 1 inside of the just cannot unbox. When compiled to core with -O2 what I'd want to see is something like: {{{#!hs mWantThisToUnbox = StillBoxedInner 0# (# | 1# #) }}} (where (# (# #) | a #) is an unboxed sum type with two constructors, one nullary and one unary) but instead the Int inside 'SJust' remains boxed. Even with something like the following: {{{#!hs {-# LANGUAGE UnboxedSums #-} data UMaybe a = (# (# #) | a #) }}} something like 'UMaybe Int' would still result in 'Int' being boxed. This same thing occurs with unpacked tuples, consider something like: {{{#!hs data StrictTuple = StrictTuple !Int !(Int, Int) }}} Anything inside the (Int, Int) tuple will not unbox, despite having a bang pattern there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 19:57:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 19:57:22 -0000 Subject: [GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 In-Reply-To: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> References: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> Message-ID: <066.93cf988a963b5db5e2e1ca16a5f6d3b3@haskell.org> #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * Attachment "Cl3.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 19:57:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 19:57:35 -0000 Subject: [GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 In-Reply-To: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> References: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> Message-ID: <066.8ccf6460a2cf487c1b7f0ddb395d89a5@haskell.org> #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): Based on comment:6, I attached a bit smaller version without dependency on random. On my machine: * `ghc-8.0.2 -O -c Cl3.hs -fforce-recomp` takes 2 secs * `ghc-8.2.1 -O -c Cl3.hs -fforce-recomp` takes 57 secs * `ghc-8.4.3 -O -c Cl3.hs -fforce-recomp` takes 95 secs If I don't add `-O`, every version takes 2 secs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 19:59:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 19:59:56 -0000 Subject: [GHC] #15358: no way to talk about unpacking sum types / unpacking tuples In-Reply-To: <046.10280472f5df7e66337f813b5dfe7fe0@haskell.org> References: <046.10280472f5df7e66337f813b5dfe7fe0@haskell.org> Message-ID: <061.15f93cd8ee02181ee7abb8bebbd8e221@haskell.org> #15358: no way to talk about unpacking sum types / unpacking tuples -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: unboxedsums, | unboxedtuples Operating System: 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): If I understand correctly you want two things: 1. Unpacking polymorphic fields 2. Deeply unpacking strict fields (1) gets requested from time to time and it's not something that can be implemented easily, it deserves a detailed design and a proposal. (2) already works today. E.g. {{{ {-# LANGUAGE BangPatterns #-} module Lib where data StrictIntPair = StrictIntPair {-# UNPACK #-} !Int {-# UNPACK #-} !Int data StrictTuple = StrictTuple {-# UNPACK #-} !Int {-# UNPACK #-} !StrictIntPair }}} If you look at worker functions for `StrictIntPair` and `StrictTuple` constructors: {{{ Lib.$WStrictIntPair [InlPrag=INLINE[2]] :: GHC.Types.Int -> GHC.Types.Int -> Lib.StrictIntPair [GblId[DataConWrapper], Arity=2, Caf=NoCafRefs, Str=m, Unf=OtherCon []] = [] \r [dt_s1aj dt_s1ak] case dt_s1aj of { GHC.Types.I# dt_s1am [Occ=Once] -> case dt_s1ak of { GHC.Types.I# dt_s1ao [Occ=Once] -> Lib.StrictIntPair [dt_s1am dt_s1ao]; }; }; Lib.$WStrictTuple [InlPrag=INLINE[2]] :: GHC.Types.Int -> Lib.StrictIntPair -> Lib.StrictTuple [GblId[DataConWrapper], Arity=2, Caf=NoCafRefs, Str=m, Unf=OtherCon []] = [] \r [dt_s1ac dt_s1ad] case dt_s1ac of { GHC.Types.I# dt_s1af [Occ=Once] -> case dt_s1ad of { Lib.StrictIntPair dt_s1ah [Occ=Once] dt_s1ai [Occ=Once] -> Lib.StrictTuple [dt_s1af dt_s1ah dt_s1ai]; }; }; }}} Notice that `StrictIntPair` unpacks `Int`s, and `StrictTuple` uses those unpacked `Int`s. In your example you have two problems: - In the first example the data type is polymorphic on the field so you can't unpack the `SJust` field even if it's strict. - In `StrictTuple` you can't unpack `Int`s because the tuple is not strict in its fields. If you define a strict tuple as I did in my example you'll see that you get three unboxed `Int`s as fields in `StrictTuple`. Finally, when trying these out make sure you're using explicit `{-# UNPACK #-}` pragmas (otherwise it's hard to know if your field will be unpacked) and use `-O` (or `-O2`) as otherwise `UNPACK` pragmas don't work and you don't get automatic unpacking of small fields (e.g. `Int`s). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 21:06:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 21:06:45 -0000 Subject: [GHC] #15349: fixST is a bit wrong In-Reply-To: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> References: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> Message-ID: <060.51db7732223a9208012d9b50fd53060f@haskell.org> #15349: fixST is a bit wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4948 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I've put up a differential to fix ''strict'' `ST`. Unfortunately, all my attempts thus far to fix ''lazy'' `ST` have been extremely fragile. I don't really understand what's going on well enough to see exactly what the trouble is, let alone how to fix it. My lazy `ST` test case: {{{#!hs foo :: ST s Int foo = do ref <- strictToLazyST (newSTRef True) fixST $ \res -> strictToLazyST $ do x <- readSTRef ref if x then do writeSTRef ref False return $! (res + 5) else return 10 main = print $ runST foo }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 21:49:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 21:49:56 -0000 Subject: [GHC] #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 In-Reply-To: <047.0e132514379b72c39d1662f2412d5748@haskell.org> References: <047.0e132514379b72c39d1662f2412d5748@haskell.org> Message-ID: <062.4683fd793c9cdc4f95d81999e92cbd77@haskell.org> #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 -------------------------------------+------------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): Here is the minimal reproducer: {{{#!hs -- a.hs import System.IO main = do hSetBuffering stdout (BlockBuffering Nothing) hPutStrLn stdout "hello" }}} {{{ $ ghc --make a.hs -O1 -dynamic $ ./a }}} Confirmed locally that: - broken: '''sh4''' and '''m68k''' - seem to work: '''x86_64''', '''mipsn32''', '''powerpc''', '''powerpc64''', '''sparc''' I have not got to the bottom of the bug yet but on the way there. Somehow flushStdHandles fails to flush stdout when (and only when) in full buffered mode. A few observations: - the trigger needs both '''-O1' and '''-dynamic''' - both '''sh4''' and '''m68k''' are arches with 2-byte instruction width I'll keep debugging. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 22:03:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 22:03:50 -0000 Subject: [GHC] #15357: Make nofib suitable for runtime measurements. In-Reply-To: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> References: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> Message-ID: <062.b214213fbd410392300e9643e6831535@haskell.org> #15357: Make nofib suitable for runtime measurements. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: NoFib benchmark | Version: 8.4.3 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think that would be extremely helpful. Are you offering to help?! It would be great if so. NB: there's already FAST/NORM/SLOW setting that is supposed to choose per- benchmarks configurations that take 1s/5s/20s or something vaguely like that. Worth figuring out what this does. The configs are doubtless way out of date. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 22:11:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 22:11:08 -0000 Subject: [GHC] #14929: Program compiled with -O2 exhibits much worse performance In-Reply-To: <049.ba205f50f7e92bd0b7f0e4b08e0f1c92@haskell.org> References: <049.ba205f50f7e92bd0b7f0e4b08e0f1c92@haskell.org> Message-ID: <064.3b871c9cf2a68a1086c7c6981664ff1c@haskell.org> #14929: Program compiled with -O2 exhibits much worse performance -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.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 not looked at the code, but full laziness is definitely capable of increasing space usage. Consider even {{{ f xs = sum [x+n | n <- [1..], x <- xs] }}} Full laziness will turn this into {{{ ns = [1..] f xs = sum [x+n | n<-ns, x<-xs] }}} which will retain a top-level CAF whose length is the longest list ever passed to `f`. In this case it is probably better to re-generate the list `[1..]` on every call, but it's not so clear if it is `map expensive [1..]`. The OP doesn't say if the same effect happens with -O. Is there something -O2 specific going on, I wonder? Regardless * Extracting the test case and uploading it here with repro instructions would be good * More specific insight into exactly what is happening would be good -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 22:48:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 22:48:58 -0000 Subject: [GHC] #14231: Core lint error "in result of Static argument" In-Reply-To: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> References: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> Message-ID: <064.fa15c86e9e25f9385f41c4cfc3e71781@haskell.org> #14231: Core lint error "in result of Static argument" -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4945 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Aargh. I'm an idiot. My claim that cloning is unnecessary is utterly wrong. Here's a fixed version of the latter part of comment:13. We want to generate this: {{{ f :: forall a b. (a,b) -> b -> Int f = /\a b. \(x:(a,b)) (y:b). letrec fwrk = /\a \(x:(a,b). REPLACE (f b y) WITH (fwrk ) IN in fwrk a x }}} Here `fwrk` is the local, recursive worker, which has free variables `b`' and `y::b`. Notice that the binders of `fwrk`, namely `a` and `x::(a,b)` must be identical (same unique) as the originals, because they are mentioned in ``. What is this "REPLACE" business? We want to replace a recusive call to `f` with a call to `fwrk`. The easy way to do this is with a non-recursive let, later inlined: {{{ f = /\a b. \(x:(a,b)) (y:b). letrec fwrk :: forall a. (a,b) -> Int fwrk = /\a \(x:(a,b). let f :: forall a b1. (a,b) -> b -> Int f = /\a _ \(x::(a,b) (_::b). fwrk a x in in fwrk a x }}} We must use the ''same'' unique for that inner `f`: we are deliberately shadowing its outer binding. Notice too that I used underscores (i.e. freshly-cloned variables that are never referred to) for the static variables. Reason: `fwrk t` expects an argument of type `(t,b)`, where `b` scopes globally over the entire definition of `fwrk`. We ''cannot'' write {{{ let f :: forall a b. (a,b) -> b -> Int f = /\a b \(x::(a,b) (y::b). fwrk a x }}} becuase then the call to `fwrk` is ill-typed. This is what `Note [Binder type capture]` is about. We should clone the static binders; and it does no harm to clone everything I suppose. ------------------ So what is wrong in commnet:8. Here's the actual error message {{{ In the expression: bindWith @ a_a17R k_atm f_atn Mismatch in type between binder and occurrence Var: bindWith_rqJ Binder type: forall a. (a_a17R -> a_a17R) -> a_a17R -> a_a17R Occurrence type: forall a. (a -> a) -> a -> a Before subst: forall a. (a -> a) -> a -> a }}} Ah! Indeed in our running example, the REPLACE binding for `f` has type {{{ let f :: forall a b1. (a,b) -> b -> Int f = /\a _ \(x::(a,b) (_::b). fwrk a x }}} and indeed that is not the type of the top-level `f`. But each ''occurrence'' of `f` has the top of the top-level `f` and Lint is objecting that there seems to be an inconsistency. If we just let it inline, everything would be fine. How tiresome. Using a let-binding to do the REPLACE stuff is not as convenient as it seems :-(. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 23:26:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 23:26:23 -0000 Subject: [GHC] #15354: QuantifiedConstraints not fully described in manual In-Reply-To: <047.918d0c77c6c735a247e6543296b4835e@haskell.org> References: <047.918d0c77c6c735a247e6543296b4835e@haskell.org> Message-ID: <062.fa4522e9a4ee3611abf7958a02db59e4@haskell.org> #15354: QuantifiedConstraints not fully described in manual -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:1 Simon Peyton Jones ]: > {{{ > This is a documentation-only fix, addressing Trac #15354. > }}} Thanks Simon, is there a typo? {{{ class ::= ... | [forall tyavrs .] [context =>] qtycls inst1 ... instn | [forall tyavrs .] [context =>] tyvar inst1 ... instn }}} should be `| [forall tyvars .] ...`? (I think this has come through from the github proposal.) So to know if some code is using `QuantifiedConstraints`: either there's a `context =>` or a `forall` (or both). If neither appear (despite having `{-# LANGUAGE QuantifiedConstraints #-}`), then it's a regular class appearing in a context, whatever "regular" means ;-). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 23:34:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 23:34:36 -0000 Subject: [GHC] #15354: QuantifiedConstraints not fully described in manual In-Reply-To: <047.918d0c77c6c735a247e6543296b4835e@haskell.org> References: <047.918d0c77c6c735a247e6543296b4835e@haskell.org> Message-ID: <062.6785df68811a77963fce894d130df36f@haskell.org> #15354: QuantifiedConstraints not fully described in manual -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes there's some overlap (with the existing productions) in the grammar. I considered having rules for all combinations of with and without foralls and context (for each of the two forms of head) leading to six productions instead of two, but I decided against. The grammar isn't trying to tell you which extension you are using, just what forms are legal. I don't feel strongly; it does not seem v important. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 23:55:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 23:55:26 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails In-Reply-To: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> References: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> Message-ID: <065.a140677cccbecad4ed74d6c50e9c7235@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, CUSKs Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"030211d21207dabb7a4bf21cc9af6fa5eb066db1/ghc" 030211d2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="030211d21207dabb7a4bf21cc9af6fa5eb066db1" Kind-check CUSK associated types separately Previously, we kind-checked associated types while while still figuring out the kind of a CUSK class. This caused trouble, as documented in Note [Don't process associated types in kcLHsQTyVars] in TcTyClsDecls. This commit moves this process after the initial kind of the class is determined. Fixes #15142. Test case: indexed-types/should_compile/T15142.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 23:55:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 23:55:26 -0000 Subject: [GHC] #14873: GHC HEAD regression (piResultTy) In-Reply-To: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> References: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> Message-ID: <065.ab41264c34de4051e3ebe49901a05f44@haskell.org> #14873: GHC HEAD regression (piResultTy) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"cf67e59a90bcaba657a9f5db3d5defb6289c274f/ghc" cf67e59a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cf67e59a90bcaba657a9f5db3d5defb6289c274f" Expand and implement Note [The tcType invariant] Read that note -- it's necessary to make sure that we can always call typeKind without panicking. As discussed on #14873, there were more checks and zonking to do, implemented here. There are no known bugs fixed by this patch, but there are likely unknown ones. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 23:55:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 23:55:26 -0000 Subject: [GHC] #14808: GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order In-Reply-To: <050.90702c1fad16a72a2e55cb4eeb0cc78a@haskell.org> References: <050.90702c1fad16a72a2e55cb4eeb0cc78a@haskell.org> Message-ID: <065.4a024bf731c3fe041ea9458ecc49873f@haskell.org> #14808: GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14529, #14796 | Differential Rev(s): Phab:D4413 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"7f4dd888f12ec9a24cc2d7f60f214706bd33a1ab/ghc" 7f4dd88/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7f4dd888f12ec9a24cc2d7f60f214706bd33a1ab" Note [Ordering of implicit variables] This addresses #14808 [ci skip] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 23:58:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 23:58:23 -0000 Subject: [GHC] #14808: GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order In-Reply-To: <050.90702c1fad16a72a2e55cb4eeb0cc78a@haskell.org> References: <050.90702c1fad16a72a2e55cb4eeb0cc78a@haskell.org> Message-ID: <065.e4342f12a2de691eac57219bee2e58bd@haskell.org> #14808: GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14529, #14796 | Differential Rev(s): Phab:D4413 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge Comment: The remaining piece was to improve documentation, which the last commit does. It's worth merging this last piece, as it clarifies the manual. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 10 23:59:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 10 Jul 2018 23:59:18 -0000 Subject: [GHC] #14873: GHC HEAD regression (piResultTy) In-Reply-To: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> References: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> Message-ID: <065.9d919baddf668ea3889f90c1a5a784fc@haskell.org> #14873: GHC HEAD regression (piResultTy) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge Comment: This ticket just had some documentation needs to sort out, but along the way, I found places where a few zonks were necessary. I see no reason not to merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 00:00:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 00:00:23 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails In-Reply-To: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> References: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> Message-ID: <065.b8f54f4cd67c3c30cf76325d1cd8f3f8@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: indexed- crash or panic | types/should_compile/T15142 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => indexed-types/should_compile/T15142 Comment: Fixed now. Please merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 06:39:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 06:39:51 -0000 Subject: [GHC] #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 In-Reply-To: <047.0e132514379b72c39d1662f2412d5748@haskell.org> References: <047.0e132514379b72c39d1662f2412d5748@haskell.org> Message-ID: <062.f33cd7a11e243cd85292a238c693f855@haskell.org> #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 -------------------------------------+------------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): Replying to [comment:3 slyfox]: > I'll keep debugging. I think I understand breakage mechanics now: The example above breaks because '''stdout''' haskell closure is evaluated twice: - once in the test binary - once in shared library and creates two objects. '''hFlush''' is called only for second (shared library) object because it is called from there. Duplication happens because '''base_GHCziIOziHandleziFD_stdout_closure''' (closure behind '''System.IO.stdout''' object) is copied by the linker '''COPY''' relocation: {{{ $ objdump -R -D bug/ghc-pkg 00415248 : ... 415248: R_SH_COPY base_GHCziIOziHandleziFD_stdout_closure }}} It should be just an external reference like '''R_SH_GLOB_DAT''' instead. Normally '''COPY''' relocations are used only for immutable ('''const''' in C land) data. But '''_closure'''s are mutable. I'll double-check generated C code and file a toolchain bug upstream. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 07:30:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 07:30:00 -0000 Subject: [GHC] #14808: GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order In-Reply-To: <050.90702c1fad16a72a2e55cb4eeb0cc78a@haskell.org> References: <050.90702c1fad16a72a2e55cb4eeb0cc78a@haskell.org> Message-ID: <065.7ee9915c0e1f94bd7be06335d69a4752@haskell.org> #14808: GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14529, #14796 | Differential Rev(s): Phab:D4413 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks Richard! That's an improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 08:17:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 08:17:23 -0000 Subject: [GHC] #14873: GHC HEAD regression (piResultTy) In-Reply-To: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> References: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> Message-ID: <065.f772517dd4c3da5a142702562622f305@haskell.org> #14873: GHC HEAD regression (piResultTy) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Richard, I'm beginning to wonder if the pain of `Note [The well-kinded type invariant]` is worth the gain. It's all very delicate. Here's a possible alternative 1. Define `tcTypeKind :: TcType -> TcM TcKind` which zonks, if necessary, on the fly. This would be dead easy to write. 2. Call `tcTypeKind` instead of `typeKind` in ... well, in various places. Anywhere in the type checker where un-zonked kinds might be floating about. For (2) there are two difficulties * Which calls, exactly, would need to be in the monad? * Are there any calls that don't have the `TcM` monad conveniently to hand? For example `eqType` calls `typeKind`, so we'd really need a `tcEqType` variant that calls `tcTypeKind`. Advantages: (a) redundant Refls disappear much earlier; this is Good (b) less delicate invariants. What do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 08:17:49 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 08:17:49 -0000 Subject: [GHC] #14873: The well-kinded type invariant (in TcType) (was: GHC HEAD regression (piResultTy)) In-Reply-To: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> References: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> Message-ID: <065.bba3b667c6cbcf842e3e39c0a90259b6@haskell.org> #14873: The well-kinded type invariant (in TcType) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 08:25:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 08:25:03 -0000 Subject: [GHC] #15136: High CPU when asynchronous exception and unblocking retry on TVar raced In-Reply-To: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> References: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> Message-ID: <062.c86e933d5216817bd649f542649c853b@haskell.org> #15136: High CPU when asynchronous exception and unblocking retry on TVar raced -------------------------------------+------------------------------------- Reporter: nshimaza | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I documented why we can't apply ownership semantics of MVars to TVars (as described in comment:5) in Phab:D4954. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 08:36:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 08:36:30 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails In-Reply-To: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> References: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> Message-ID: <065.1f312b14e837b636bb06bf5f47d8e752@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: indexed- crash or panic | types/should_compile/T15142 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > In 030211d2/ghc: Richard, I like this. The code is simpler, `kcLHsQTyVars` has a simpler signature. All good. But you did not respond to these points from comment:5: * First, `C` has a CUSK. But does `T`? Well `hsDeclHasCusk` reports True for the class decl, without even looking at `T`. This seems wrong. What is the CUSK status of `T`? Apparently `famDeclHasCusk` returns True if the enclosing class has a CUSK, but is that right? There's a comment "all un-associated open families have CUSKs" which I don't understand. Ah... I see from [http://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#complete-user-supplied-kind-signatures-and- polymorphic-recursion the manual] that we treat open families as CUSK-ish by defaulting. We should have a Note to explain the rules -- or I suppose a Note that summarises and points clearly to the manual as the reference. But why do we default here? It seems inconsistent with (say) `data T a b = ...`. Is it just an arbitrary choice of convenience? What about `type family F (a :: k1 k2) :: *`? * `C` has a CUSK, but in `class C (a :: Type) (b :: k)`, I'm not sure how we get to know that `k :: Type`. Yet, without that `C` would not have a CUSK. I guess that we are defaulting kind variables to `*`? Well not to `*`, because we might have `class C (a :: k1 k2) where ...` After typing this in I realise that all I'm seeking is a clearer exposition of the CUSK rules. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 08:57:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 08:57:59 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.199b0070b45d65682e050c0770bc873e@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nfrisby Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 | Differential Rev(s): Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by simonpj): Thoughts * There are a handful of spectacular reductions in allocation (queens, n-body). It'd be good to understand and explain them. Perhaps we can more closely target LLF on those cases. * I don't think we should float join points at all, recursive or non- recursive. Think of them like labels in a control-flow graph. * I think of LLF as a code-generation strategy, that we do once all other transformations are done. (Lambda-lifting ''can'' affect earlier optimisations. It can make a big function into a small one (by floating out its guts), and thereby let it be inlined. But that is subtle and difficult to get consistent gains for. Let's not complicate LLF by thinking about this.) * Given that it's a code-gen strategy, doing it on STG makes perfect sense to me. You've outlined the pros and cons well. Definitely worth a try. I'm not sure what you meant by "It's not enough to look at Core alone to gauge allocation" as a disadvantage. When you say "Much less involved analysis that doesn't need to stay in sync with CorePrep", I think it would be v helpful to lay out "the analysis". I have vague memories, but I don't know what this "stay in sync" stuff is about. If you do it in STG you don't need to explain "stay in sync", but explaining the analysis would be excellent. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 09:25:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 09:25:23 -0000 Subject: [GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin In-Reply-To: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> References: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> Message-ID: <062.fae0f3ce796d110bdd11b625c792a57a@haskell.org> #15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | typeable,knownnat Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10348 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by LeanderK): A bit of community-feedback: I have used type-nats a few times and every time I used them, I have been bitten by GHC not recognizing apartness between nats. I think the ability for a plugin to provide the functionality would make them way more useful! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 10:37:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 10:37:43 -0000 Subject: [GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin In-Reply-To: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> References: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> Message-ID: <062.f1c0f4022eb0f3d651a9c42ae266a2f9@haskell.org> #15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | typeable,knownnat Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10348 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I have used type-nats a few times and every time I used them, I have been bitten by GHC not recognizing apartness between nats Interesting. Another possibility would be to build into GHC more knowledge about `KnownNat`. But making it possible for plugins to specify apartness would also be good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 11:07:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 11:07:13 -0000 Subject: [GHC] #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints In-Reply-To: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> References: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> Message-ID: <059.fb1b39a6d8f221e3b384be493f1c9fbc@haskell.org> #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: quantified- invalid program | constraints/T15316 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Doesn't UndecidableInstances imply the typechecking might not terminate, as opposed to a finite typechecking process resulting in a program nonterminating due to poor case of context elaboration? Usually yes, but in the cases above it can mean the latter too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 11:09:39 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 11:09:39 -0000 Subject: [GHC] #15352: False kind errors with implicitly bound kinds in GHC 8.6 In-Reply-To: <049.666f6c18fdc69cbdb49750fc137a0f75@haskell.org> References: <049.666f6c18fdc69cbdb49750fc137a0f75@haskell.org> Message-ID: <064.c5c28615856adbd1ce57f2f2bc701249@haskell.org> #15352: False kind errors with implicitly bound kinds in GHC 8.6 -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"81d8b1792d01e0645468e35e23e758dd9c7a6349/ghc" 81d8b179/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="81d8b1792d01e0645468e35e23e758dd9c7a6349" Add test for Trac #15352 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 11:09:39 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 11:09:39 -0000 Subject: [GHC] #14873: The well-kinded type invariant (in TcType) In-Reply-To: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> References: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> Message-ID: <065.a938342b10f471dee0fb9dec9468da38@haskell.org> #14873: The well-kinded type invariant (in TcType) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"e24da5edb4709bdb050c8d0676f302d0b87b8446/ghc" e24da5e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e24da5edb4709bdb050c8d0676f302d0b87b8446" Better Note [The well-kinded type invariant] c.f. Trac #14873 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 11:10:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 11:10:23 -0000 Subject: [GHC] #15352: False kind errors with implicitly bound kinds in GHC 8.6 In-Reply-To: <049.666f6c18fdc69cbdb49750fc137a0f75@haskell.org> References: <049.666f6c18fdc69cbdb49750fc137a0f75@haskell.org> Message-ID: <064.6b815a5f2acedd53db93367084c652cd@haskell.org> #15352: False kind errors with implicitly bound kinds in GHC 8.6 -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, this is fixed. Hurrah. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 11:11:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 11:11:13 -0000 Subject: [GHC] #15352: False kind errors with implicitly bound kinds in GHC 8.6 In-Reply-To: <049.666f6c18fdc69cbdb49750fc137a0f75@haskell.org> References: <049.666f6c18fdc69cbdb49750fc137a0f75@haskell.org> Message-ID: <064.415369c5f7ec2a7cb4e9c2962c596960@haskell.org> #15352: False kind errors with implicitly bound kinds in GHC 8.6 -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T15352 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => indexed-types/should_compile/T15352 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 13:00:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 13:00:59 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.6032f8d6a875f34c9e35f861527fc562@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): OK, so I tried to validate, but I'm getting core lint errors while compiling stage2: {{{ "inplace/bin/ghc-stage1" -this-unit-id rts -shared -dynamic -dynload deploy -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath -optl-Wl,'$ORIGIN' -optl-Wl,-zorigin `cat rts/dist/libs.depend` rts/dist/build/Arena.l_dyn_o rts/dist/build/Stable.l_dyn_o rts/dist/build/Linker.l_dyn_o rts/dist/build/RtsFlags.l_dyn_o rts/dist/build/Sparks.l_dyn_o rts/dist/build/Profiling.l_dyn_o rts/dist/build/RtsStartup.l_dyn_o rts/dist/build/FileLock.l_dyn_o rts/dist/build/StgPrimFloat.l_dyn_o rts/dist/build/Pool.l_dyn_o rts/dist/build/StaticPtrTable.l_dyn_o rts/dist/build/Disassembler.l_dyn_o rts/dist/build/TopHandler.l_dyn_o rts/dist/build/WSDeque.l_dyn_o rts/dist/build/RetainerSet.l_dyn_o rts/dist/build/ProfilerReport.l_dyn_o rts/dist/build/Schedule.l_dyn_o rts/dist/build/RtsAPI.l_dyn_o rts/dist/build/Adjustor.l_dyn_o rts/dist/build/Globals.l_dyn_o rts/dist/build/Capability.l_dyn_o rts/dist/build/xxhash.l_dyn_o rts/dist/build/Messages.l_dyn_o rts/dist/build/Interpreter.l_dyn_o rts/dist/build/Hpc.l_dyn_o rts/dist/build/Libdw.l_dyn_o rts/dist/build/RetainerProfile.l_dyn_o rts/dist/build/ClosureFlags.l_dyn_o rts/dist/build/LdvProfile.l_dyn_o rts/dist/build/StgCRun.l_dyn_o rts/dist/build/Task.l_dyn_o rts/dist/build/ProfilerReportJson.l_dyn_o rts/dist/build/RtsUtils.l_dyn_o rts/dist/build/Weak.l_dyn_o rts/dist/build/Stats.l_dyn_o rts/dist/build/Trace.l_dyn_o rts/dist/build/Hash.l_dyn_o rts/dist/build/RaiseAsync.l_dyn_o rts/dist/build/ProfHeap.l_dyn_o rts/dist/build/RtsMessages.l_dyn_o rts/dist/build/RtsSymbolInfo.l_dyn_o rts/dist/build/RtsDllMain.l_dyn_o rts/dist/build/Timer.l_dyn_o rts/dist/build/HsFFI.l_dyn_o rts/dist/build/OldARMAtomic.l_dyn_o rts/dist/build/STM.l_dyn_o rts/dist/build/ThreadLabels.l_dyn_o rts/dist/build/Proftimer.l_dyn_o rts/dist/build/RtsSymbols.l_dyn_o rts/dist/build/PathUtils.l_dyn_o rts/dist/build/Threads.l_dyn_o rts/dist/build/RtsMain.l_dyn_o rts/dist/build/CheckUnload.l_dyn_o rts/dist/build/Inlines.l_dyn_o rts/dist/build/Ticky.l_dyn_o rts/dist/build/LibdwPool.l_dyn_o rts/dist/build/ThreadPaused.l_dyn_o rts/dist/build/Printer.l_dyn_o rts/dist/build/fs.l_dyn_o rts/dist/build/hooks/OutOfHeap.l_dyn_o rts/dist/build/hooks/MallocFail.l_dyn_o rts/dist/build/hooks/FlagDefaults.l_dyn_o rts/dist/build/hooks/OnExit.l_dyn_o rts/dist/build/hooks/LongGCSync.l_dyn_o rts/dist/build/hooks/StackOverflow.l_dyn_o rts/dist/build/sm/MBlock.l_dyn_o rts/dist/build/sm/Scav.l_dyn_o rts/dist/build/sm/GCUtils.l_dyn_o rts/dist/build/sm/CNF.l_dyn_o rts/dist/build/sm/Compact.l_dyn_o rts/dist/build/sm/Sweep.l_dyn_o rts/dist/build/sm/GCAux.l_dyn_o rts/dist/build/sm/MarkWeak.l_dyn_o rts/dist/build/sm/BlockAlloc.l_dyn_o rts/dist/build/sm/Evac_thr.l_dyn_o rts/dist/build/sm/GC.l_dyn_o rts/dist/build/sm/Sanity.l_dyn_o rts/dist/build/sm/Evac.l_dyn_o rts/dist/build/sm/Storage.l_dyn_o rts/dist/build/sm/Scav_thr.l_dyn_o rts/dist/build/eventlog/EventLogWriter.l_dyn_o rts/dist/build/eventlog/EventLog.l_dyn_o rts/dist/build/linker/elf_reloc_aarch64.l_dyn_o rts/dist/build/linker/MachO.l_dyn_o rts/dist/build/linker/elf_plt.l_dyn_o rts/dist/build/linker/elf_plt_aarch64.l_dyn_o rts/dist/build/linker/M32Alloc.l_dyn_o rts/dist/build/linker/elf_got.l_dyn_o rts/dist/build/linker/Elf.l_dyn_o rts/dist/build/linker/CacheFlush.l_dyn_o rts/dist/build/linker/SymbolExtras.l_dyn_o rts/dist/build/linker/elf_plt_arm.l_dyn_o rts/dist/build/linker/LoadArchive.l_dyn_o rts/dist/build/linker/PEi386.l_dyn_o rts/dist/build/linker/elf_reloc.l_dyn_o rts/dist/build/linker/elf_util.l_dyn_o rts/dist/build/posix/OSMem.l_dyn_o rts/dist/build/posix/GetTime.l_dyn_o rts/dist/build/posix/OSThreads.l_dyn_o rts/dist/build/posix/Itimer.l_dyn_o rts/dist/build/posix/TTY.l_dyn_o rts/dist/build/posix/Signals.l_dyn_o rts/dist/build/posix/Select.l_dyn_o rts/dist/build/posix/GetEnv.l_dyn_o rts/dist/build/StgStartup.l_dyn_o rts/dist/build/PrimOps.l_dyn_o rts/dist/build/HeapStackCheck.l_dyn_o rts/dist/build/Updates.l_dyn_o rts/dist/build/Exception.l_dyn_o rts/dist/build/StgMiscClosures.l_dyn_o rts/dist/build/Apply.l_dyn_o rts/dist/build/Compact.l_dyn_o rts/dist/build/StgStdThunks.l_dyn_o rts/dist/build/AutoApply.l_dyn_o -fPIC -dynamic -eventlog -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical- monad-instances -o rts/dist/build/libHSrts_l-ghc8.5.20180710.so "rm" -f rts/dist/build/libHSrts_thr_l-ghc8.5.20180710.so "inplace/bin/ghc-stage1" -this-unit-id rts -shared -dynamic -dynload deploy -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath -optl-Wl,'$ORIGIN' -optl-Wl,-zorigin `cat rts/dist/libs.depend` rts/dist/build/Arena.thr_l_dyn_o rts/dist/build/Stable.thr_l_dyn_o rts/dist/build/Linker.thr_l_dyn_o rts/dist/build/RtsFlags.thr_l_dyn_o rts/dist/build/Sparks.thr_l_dyn_o rts/dist/build/Profiling.thr_l_dyn_o rts/dist/build/RtsStartup.thr_l_dyn_o rts/dist/build/FileLock.thr_l_dyn_o rts/dist/build/StgPrimFloat.thr_l_dyn_o rts/dist/build/Pool.thr_l_dyn_o rts/dist/build/StaticPtrTable.thr_l_dyn_o rts/dist/build/Disassembler.thr_l_dyn_o rts/dist/build/TopHandler.thr_l_dyn_o rts/dist/build/WSDeque.thr_l_dyn_o rts/dist/build/RetainerSet.thr_l_dyn_o rts/dist/build/ProfilerReport.thr_l_dyn_o rts/dist/build/Schedule.thr_l_dyn_o rts/dist/build/RtsAPI.thr_l_dyn_o rts/dist/build/Adjustor.thr_l_dyn_o rts/dist/build/Globals.thr_l_dyn_o rts/dist/build/Capability.thr_l_dyn_o rts/dist/build/xxhash.thr_l_dyn_o rts/dist/build/Messages.thr_l_dyn_o rts/dist/build/Interpreter.thr_l_dyn_o rts/dist/build/Hpc.thr_l_dyn_o rts/dist/build/Libdw.thr_l_dyn_o rts/dist/build/RetainerProfile.thr_l_dyn_o rts/dist/build/ClosureFlags.thr_l_dyn_o rts/dist/build/LdvProfile.thr_l_dyn_o rts/dist/build/StgCRun.thr_l_dyn_o rts/dist/build/Task.thr_l_dyn_o rts/dist/build/ProfilerReportJson.thr_l_dyn_o rts/dist/build/RtsUtils.thr_l_dyn_o rts/dist/build/Weak.thr_l_dyn_o rts/dist/build/Stats.thr_l_dyn_o rts/dist/build/Trace.thr_l_dyn_o rts/dist/build/Hash.thr_l_dyn_o rts/dist/build/RaiseAsync.thr_l_dyn_o rts/dist/build/ProfHeap.thr_l_dyn_o rts/dist/build/RtsMessages.thr_l_dyn_o rts/dist/build/RtsSymbolInfo.thr_l_dyn_o rts/dist/build/RtsDllMain.thr_l_dyn_o rts/dist/build/Timer.thr_l_dyn_o rts/dist/build/HsFFI.thr_l_dyn_o rts/dist/build/OldARMAtomic.thr_l_dyn_o rts/dist/build/STM.thr_l_dyn_o rts/dist/build/ThreadLabels.thr_l_dyn_o rts/dist/build/Proftimer.thr_l_dyn_o rts/dist/build/RtsSymbols.thr_l_dyn_o rts/dist/build/PathUtils.thr_l_dyn_o rts/dist/build/Threads.thr_l_dyn_o rts/dist/build/RtsMain.thr_l_dyn_o rts/dist/build/CheckUnload.thr_l_dyn_o rts/dist/build/Inlines.thr_l_dyn_o rts/dist/build/Ticky.thr_l_dyn_o rts/dist/build/LibdwPool.thr_l_dyn_o rts/dist/build/ThreadPaused.thr_l_dyn_o rts/dist/build/Printer.thr_l_dyn_o rts/dist/build/fs.thr_l_dyn_o rts/dist/build/hooks/OutOfHeap.thr_l_dyn_o rts/dist/build/hooks/MallocFail.thr_l_dyn_o rts/dist/build/hooks/FlagDefaults.thr_l_dyn_o rts/dist/build/hooks/OnExit.thr_l_dyn_o rts/dist/build/hooks/LongGCSync.thr_l_dyn_o rts/dist/build/hooks/StackOverflow.thr_l_dyn_o rts/dist/build/sm/MBlock.thr_l_dyn_o rts/dist/build/sm/Scav.thr_l_dyn_o rts/dist/build/sm/GCUtils.thr_l_dyn_o rts/dist/build/sm/CNF.thr_l_dyn_o rts/dist/build/sm/Compact.thr_l_dyn_o rts/dist/build/sm/Sweep.thr_l_dyn_o rts/dist/build/sm/GCAux.thr_l_dyn_o rts/dist/build/sm/MarkWeak.thr_l_dyn_o rts/dist/build/sm/BlockAlloc.thr_l_dyn_o rts/dist/build/sm/Evac_thr.thr_l_dyn_o rts/dist/build/sm/GC.thr_l_dyn_o rts/dist/build/sm/Sanity.thr_l_dyn_o rts/dist/build/sm/Evac.thr_l_dyn_o rts/dist/build/sm/Storage.thr_l_dyn_o rts/dist/build/sm/Scav_thr.thr_l_dyn_o rts/dist/build/eventlog/EventLogWriter.thr_l_dyn_o rts/dist/build/eventlog/EventLog.thr_l_dyn_o rts/dist/build/linker/elf_reloc_aarch64.thr_l_dyn_o rts/dist/build/linker/MachO.thr_l_dyn_o rts/dist/build/linker/elf_plt.thr_l_dyn_o rts/dist/build/linker/elf_plt_aarch64.thr_l_dyn_o rts/dist/build/linker/M32Alloc.thr_l_dyn_o rts/dist/build/linker/elf_got.thr_l_dyn_o rts/dist/build/linker/Elf.thr_l_dyn_o rts/dist/build/linker/CacheFlush.thr_l_dyn_o rts/dist/build/linker/SymbolExtras.thr_l_dyn_o rts/dist/build/linker/elf_plt_arm.thr_l_dyn_o rts/dist/build/linker/LoadArchive.thr_l_dyn_o rts/dist/build/linker/PEi386.thr_l_dyn_o rts/dist/build/linker/elf_reloc.thr_l_dyn_o rts/dist/build/linker/elf_util.thr_l_dyn_o rts/dist/build/posix/OSMem.thr_l_dyn_o rts/dist/build/posix/GetTime.thr_l_dyn_o rts/dist/build/posix/OSThreads.thr_l_dyn_o rts/dist/build/posix/Itimer.thr_l_dyn_o rts/dist/build/posix/TTY.thr_l_dyn_o rts/dist/build/posix/Signals.thr_l_dyn_o rts/dist/build/posix/Select.thr_l_dyn_o rts/dist/build/posix/GetEnv.thr_l_dyn_o rts/dist/build/StgStartup.thr_l_dyn_o rts/dist/build/PrimOps.thr_l_dyn_o rts/dist/build/HeapStackCheck.thr_l_dyn_o rts/dist/build/Updates.thr_l_dyn_o rts/dist/build/Exception.thr_l_dyn_o rts/dist/build/StgMiscClosures.thr_l_dyn_o rts/dist/build/Apply.thr_l_dyn_o rts/dist/build/Compact.thr_l_dyn_o rts/dist/build/StgStdThunks.thr_l_dyn_o rts/dist/build/AutoApply.thr_l_dyn_o -fPIC -dynamic -optc-DTHREADED_RTS -eventlog -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical- monad-instances -o rts/dist/build/libHSrts_thr_l-ghc8.5.20180710.so "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -this-unit-id ghc- prim-0.5.2.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc- prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim /dist-install/build/./autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id ghc-prim -XHaskell2010 -O -dcore-lint -dno- debug-output -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno- deprecated-flags -Wnoncanonical-monad-instances -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/./GHC/CString.hs -o libraries/ghc-prim/dist- install/build/GHC/CString.o -dyno libraries/ghc-prim/dist- install/build/GHC/CString.dyn_o "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -this-unit-id ghc- prim-0.5.2.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc- prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim /dist-install/build/./autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id ghc-prim -XHaskell2010 -O -dcore-lint -dno- debug-output -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno- deprecated-flags -Wnoncanonical-monad-instances -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/./GHC/IntWord64.hs -o libraries/ghc-prim/dist- install/build/GHC/IntWord64.o -dyno libraries/ghc-prim/dist- install/build/GHC/IntWord64.dyn_o "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -this-unit-id base-4.12.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base /dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base /dist-install/build/./autogen -Ilibraries/base/dist- install/build/./autogen -Ilibraries/base/include -Ilibraries/base/dist- install/build/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package- id ghc-prim-0.5.2.0 -package-id integer-gmp-1.0.2.0 -package-id rts -this- unit-id base -XHaskell2010 -O -dcore-lint -dno-debug-output -no-user- package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist- install/build -dynamic-too -c libraries/base/./GHC/Base.hs-boot -o libraries/base/dist-install/build/GHC/Base.o-boot -dyno libraries/base /dist-install/build/GHC/Base.dyn_o-boot "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -this-unit-id base-4.12.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base /dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base /dist-install/build/./autogen -Ilibraries/base/dist- install/build/./autogen -Ilibraries/base/include -Ilibraries/base/dist- install/build/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package- id ghc-prim-0.5.2.0 -package-id integer-gmp-1.0.2.0 -package-id rts -this- unit-id base -XHaskell2010 -O -dcore-lint -dno-debug-output -no-user- package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist- install/build -dynamic-too -c libraries/base/./GHC/Real.hs-boot -o libraries/base/dist-install/build/GHC/Real.o-boot -dyno libraries/base /dist-install/build/GHC/Real.dyn_o-boot *** Core Lint errors : in result of Simplifier *** : warning: [RHS of $j_sCd :: [Char]] Join point has invalid type: $j_sCd :: [Char] *** Offending Program *** unpackCString# [InlPrag=NOINLINE CONLIKE] :: Addr# -> [Char] [LclIdX, Arity=1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 102 0}] unpackCString# = \ (addr_atX :: Addr#) -> letrec { unpack_sBT [Occ=LoopBreaker] :: Int# -> [Char] [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 62 40}] unpack_sBT = \ (nh_atZ :: Int#) -> case indexCharOffAddr# addr_atX nh_atZ of ch_axY { __DEFAULT -> : @ Char (C# ch_axY) (unpack_sBT (+# nh_atZ 1#)); '\NUL'# -> [] @ Char }; } in unpack_sBT 0# ----- snip ----- $trModule_sAS :: TrName [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] $trModule_sAS = TrNameS $trModule_sAR $trModule :: Module [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $trModule = Module $trModule_sAQ $trModule_sAS *** End of Offense *** : error: Compilation had errors libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist- install/build/GHC/CString.o' failed make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/CString.o] Error 1 make[1]: *** Waiting for unfinished jobs.... Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 }}} This is from running `validate` on `ec9638b222` - as far as I can tell, this is about where the patch originally branched off of `master`; in any case it applies cleanly, and `ec9638b222` itself validates without errors. Since this error occurs while compiling stage2, my assumption is that the patch changes GHC to produce incorrect output; the incorrect stage1 compiler then fails with a core lint error while compiling stage2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 13:21:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 13:21:13 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails In-Reply-To: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> References: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> Message-ID: <065.276efffaeab27bf116d070ef1844c912@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: indexed- crash or panic | types/should_compile/T15142 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The rules are in the [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #complete-user-supplied-kind-signatures-and-polymorphic-recursion manual]. There is also `Note [Complete user-supplied kind signatures]`, but I see now that it's a bit out of date. To avoid duplication, I'll just have the Note point to the manual. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 13:31:31 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 13:31:31 -0000 Subject: [GHC] #15359: Quantified constraints do not work with equality constraints Message-ID: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> #15359: Quantified constraints do not work with equality constraints -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Feeling abusive toward GHC this morning, I tried this: {{{#!hs class C a b data Dict c where Dict :: c => Dict c foo :: (forall a b. C a b => a ~ b) => Dict (C a b) -> a -> b foo Dict x = x }}} I thought it wouldn't work, and I was right: {{{ • Class ‘~’ does not support user-specified instances • In the quantified constraint ‘forall (a :: k) (b :: k). C a b => a ~ b’ In the type signature: foo :: (forall a b. C a b => a ~ b) => Dict (C a b) -> a -> b }}} Good. But then I tried something more devious: {{{#!hs class C a b class a ~ b => D a b data Dict c where Dict :: c => Dict c foo :: (forall a b. C a b => D a b) => Dict (C a b) -> a -> b foo Dict x = x }}} This also fails, with ` Couldn't match expected type ‘b’ with actual type ‘a’`. I'm fine with the second case failing (because I think anything else would be very challenging), but the error message is unfortunate. According to the semantics of class constraints and quantified constraints, this case should be accepted. So if we reject it, we should have a good reason -- like we offer in the first case. Essentially, we need to explain that any logical entailment of an equality constraint simply doesn't hold in the presence of a quantified constraint. I neither know a good pithy way of explaining that to users nor how to detect when to do so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 13:36:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 13:36:25 -0000 Subject: [GHC] #14873: The well-kinded type invariant (in TcType) In-Reply-To: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> References: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> Message-ID: <065.3c087f8f6540d5e5cbf5248aeb4be216@haskell.org> #14873: The well-kinded type invariant (in TcType) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I've wondered about this, too. If we had `TcType` separate from `Type`, then we this would be very easy to find. I suppose we could smoke it out: put an `ASSERT` in the `typeKind` case for `TyVarTy` that the tyvar isn't a `TcTyVar`. Do the same with `eqType`. Then we'd catch (almost) all the cases. I wonder what the performance implications would be. (+) We don't have to zonk unnecessarily just to maintain the invariant. (-) When we do zonk, we don't memorialize this in the type -- only in the kind. (-) Is monadic code slower than pure code? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 13:49:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 13:49:48 -0000 Subject: [GHC] #15359: Quantified constraints do not work with equality constraints In-Reply-To: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> References: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> Message-ID: <062.7d4151468732d3c59d3500129b529b38@haskell.org> #15359: Quantified constraints do not work with equality constraints -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It's very strange to me that we allow quantified `Coercible` constraints but not quantified `(~)` constraints. What is the rationale behind this decision choice? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 13:59:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 13:59:26 -0000 Subject: [GHC] #15359: Quantified constraints do not work with equality constraints In-Reply-To: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> References: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> Message-ID: <062.3a681a2abeadc2c086dee9730e591188@haskell.org> #15359: Quantified constraints do not work with equality constraints -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Oh dear. I see trouble a-brewing. I agree that `Coercible` and `~` should either both be allowed or both be rejected. But the implications in my OP are unimplementable, I think. So I'm lost as to how to specify this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 16:25:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 16:25:01 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.cbf9ab33a00bc8ef25d3101300f05780@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nfrisby Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 | Differential Rev(s): Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:16 simonpj]: > Thoughts > > * There are a handful of spectacular reductions in allocation (queens, n-body). It'd be good to understand and explain them. Perhaps we can more closely target LLF on those cases. It's hard to tell for `n-body`: The `-fno-llf` variant shows the same reduction in allocations, meaning that the reduction must happen somewhere in the base libraries rather than in `n-body` itself. `queens` has its `go1` function within `gen` lifted (arity 1 with 3 free vars). Non-lifted Core after CorePrep: {{{ let { n_s5S3 [Occ=OnceL*] :: [[GHC.Types.Int]] [LclId] n_s5S3 = go_s5RY ys_s5S2 } in case GHC.Prim.># 1# ww1_s5RX of { __DEFAULT -> letrec { go1_s5S5 [Occ=LoopBreaker] :: GHC.Prim.Int# -> [[GHC.Types.Int]] [LclId, Arity=1, Str=, Unf=OtherCon []] go1_s5S5 = \ (x1_s5S6 :: GHC.Prim.Int#) -> case Main.main_$ssafe y_s5S1 1# x1_s5S6 of { GHC.Types.False -> case GHC.Prim.==# x1_s5S6 ww1_s5RX of { __DEFAULT -> case GHC.Prim.+# x1_s5S6 1# of sat_s5S9 [Occ=Once] { __DEFAULT -> go1_s5S5 sat_s5S9 }; 1# -> n_s5S3 }; GHC.Types.True -> let { sat_s5Se [Occ=Once] :: [[GHC.Types.Int]] [LclId] sat_s5Se = case GHC.Prim.==# x1_s5S6 ww1_s5RX of { __DEFAULT -> case GHC.Prim.+# x1_s5S6 1# of sat_s5Sd [Occ=Once] { __DEFAULT -> go1_s5S5 sat_s5Sd }; 1# -> n_s5S3 } } in let { sat_s5Sa [Occ=Once] :: GHC.Types.Int [LclId] sat_s5Sa = GHC.Types.I# x1_s5S6 } in let { sat_s5Sb [Occ=Once] :: [GHC.Types.Int] [LclId] sat_s5Sb = GHC.Types.: @ GHC.Types.Int sat_s5Sa y_s5S1 } in GHC.Types.: @ [GHC.Types.Int] sat_s5Sb sat_s5Se }; } in go1_s5S5 1#; 1# -> n_s5S3 } }}} And when `go1` is lifted to top-level, the CorePrep'd call site changes to {{{ case GHC.Prim.># 1# ww1_s5Ts of { __DEFAULT -> let { sat_s5Tz [Occ=Once, Dmd=] :: [[GHC.Types.Int]] [LclId] sat_s5Tz = go_s5Tt ys_s5Tx } in llf_go_r5SK y_s5Tw ww1_s5Ts sat_s5Tz 1#; 1# -> go_s5Tt ys_s5Tx } }}} The important detail is that `n_s5S3` corresponds to `sat_s5Tz` in the lifted version. Both have a 'single' occurrence, but `n_s5S3`'s occurrence is under a non-oneshot lambda (which appearently and understandably is enough for OccAnal to give up, as opposed to analyzing parameters of recursive functions), so `n_s5S3` is updateable and causes an increase in heap allocation, while `sat_s5Tz` is single-entry. So, I'm afraid this gain can't entirely claimed by LLF. A late demand analysis run would probably detect the same. There's `cichelli`, which shows similar improvements (-10% allocs) due to something happening in `Prog.hs`, but there's too many lifts to bisect, so I'll postpone that to a follow-up post. > * I don't think we should float join points at all, recursive or non- recursive. Think of them like labels in a control-flow graph. This was also what I thought, but there can be synergetic effects with the inliner if we manage to "outline" (that's what the transformation would be called in an imperative language) huge non-recursive join points, where the call overhead is neglibigle. At least that's what the wiki page mentions. But that brings me to the next point... > * I think of LLF as a code-generation strategy, that we do once all other transformations are done. (Lambda-lifting ''can'' affect earlier optimisations. It can make a big function into a small one (by floating out its guts), and thereby let it be inlined. But that is subtle and difficult to get consistent gains for. Let's not complicate LLF by thinking about this.) Yes, I wasn't sure if having it play nice with the simplifier was intended here. I take comfort in your confirmation seeing it as a code-gen strategy. > * Given that it's a code-gen strategy, doing it on STG makes perfect sense to me. You've outlined the pros and cons well. Definitely worth a try. Will do. > I'm not sure what you meant by "It's not enough to look at Core alone to gauge allocation" as a disadvantage. Maybe it's just me only slowly understanding every layer of compilation in GHC, but I felt like I could have this mental model of roughly where and how much things allocate after CorePrep, but that's probably an illusion considering things like let-no-escapes (that story got better with join points, I suppose). Having another pass transforming heap allocation into stack allocation *after* CorePrep isn't exactly helping that intuition. Or were you thrown off by me using words I maybe mistranslated ("gauge" for "estimate", roughly)? > When you say "Much less involved analysis that doesn't need to stay in sync with CorePrep", I think it would be v helpful to lay out "the analysis". I have vague memories, but I don't know what this "stay in sync" stuff is about. There is [https://github.com/sgraf812/ghc/blob/f5c160c98830fdba83faa9a0634eeab38dbe04d4/compiler/simplCore/SetLevels.hs#L2169-L2214 this note] that explains why it's necessary to approximate CorePrep. What follows is [https://github.com/sgraf812/ghc/blob/f5c160c98830fdba83faa9a0634eeab38dbe04d4/compiler/simplCore/SetLevels.hs#L2478 this new analysis] that interleaves a free variable analysis with computing use information for id's which are free in the floating bindings. > If you do it in STG you don't need to explain "stay in sync", but explaining the analysis would be excellent. Yes! I'm not really sure I understand all of it yet. (Re-)implementing it on STG should help me figure things out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 16:31:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 16:31:35 -0000 Subject: [GHC] #15330: Error message prints invisible kind arguments in a visible matter In-Reply-To: <050.7a0d11dfbc8ef3463c27a79c9bdf89a1@haskell.org> References: <050.7a0d11dfbc8ef3463c27a79c9bdf89a1@haskell.org> Message-ID: <065.0f4f9df40f25febb6d4686553189687b@haskell.org> #15330: Error message prints invisible kind arguments in a visible matter -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4938 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"1c3536239cb5e83ff1427ac410d8fa2549e7d9c0/ghc" 1c353623/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1c3536239cb5e83ff1427ac410d8fa2549e7d9c0" Use IfaceAppArgs to store an IfaceAppTy's arguments Summary: Currently, an `IfaceAppTy` has no way to tell whether its argument is visible or not, so it simply treats all arguments as visible, leading to #15330. We already have a solution for this problem in the form of the `IfaceTcArgs` data structure, used by `IfaceTyConApp` to represent the arguments to a type constructor. Therefore, it makes sense to reuse this machinery for `IfaceAppTy`, so this patch does just that. This patch: 1. Renames `IfaceTcArgs` to `IfaceAppArgs` to reflect its more general purpose. 2. Changes the second field of `IfaceAppTy` from `IfaceType` to `IfaceAppArgs`, and propagates the necessary changes through. In particular, pretty-printing an `IfaceAppTy` now goes through the `IfaceAppArgs` pretty-printer, which correctly displays arguments as visible or not for free, fixing #15330. 3. Changes `toIfaceTypeX` and related functions so that when converting an `AppTy` to an `IfaceAppTy`, it flattens as many argument `AppTy`s as possible, and then converts those arguments into an `IfaceAppArgs` list, using the kind of the function `Type` as a guide. (Doing so minimizes the number of times we need to call `typeKind`, which is more expensive that finding the kind of a `TyCon`.) Test Plan: make test TEST=T15330 Reviewers: goldfire, simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15330 Differential Revision: https://phabricator.haskell.org/D4938 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 16:33:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 16:33:10 -0000 Subject: [GHC] #15330: Error message prints invisible kind arguments in a visible matter In-Reply-To: <050.7a0d11dfbc8ef3463c27a79c9bdf89a1@haskell.org> References: <050.7a0d11dfbc8ef3463c27a79c9bdf89a1@haskell.org> Message-ID: <065.5c7c9867439bf0f2066fb5f5dd03f108@haskell.org> #15330: Error message prints invisible kind arguments in a visible matter -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | typecheck/should_fail/T15330 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4938 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => typecheck/should_fail/T15330 * resolution: => fixed Comment: This change is just invasive enough that it's probably wise not to merge this into 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 16:43:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 16:43:32 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.5f6e80318f859e3c6c97652812734dab@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nfrisby Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 | Differential Rev(s): Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by simonpj): > A late demand analysis run would probably detect the same. -O2 does late demand analysis for this very reason. So presumably it doesn't catch it. > "It's not enough to look at Core alone to gauge allocation" I agree that STG has a stronger operational model than Core. (Core is not bad, but STG is better.) But that's an ''advantage'' of doing LLF in STG, not a ''disadvantage''. Do have a go! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 17:51:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 17:51:10 -0000 Subject: [GHC] #15136: High CPU when asynchronous exception and unblocking retry on TVar raced In-Reply-To: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> References: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> Message-ID: <062.93699565aacf7a8b86deff9f387c1eff@haskell.org> #15136: High CPU when asynchronous exception and unblocking retry on TVar raced -------------------------------------+------------------------------------- Reporter: nshimaza | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4956 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D4956 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 18:41:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 18:41:12 -0000 Subject: [GHC] #14576: Internal error when compiling TH code with profiling on Windows In-Reply-To: <044.c2e93e4cd6fa3bc5d229bcd4603864fa@haskell.org> References: <044.c2e93e4cd6fa3bc5d229bcd4603864fa@haskell.org> Message-ID: <059.2e6264d074d3898d0560b31dbfd19b48@haskell.org> #14576: Internal error when compiling TH code with profiling on Windows -------------------------------------+------------------------------------- Reporter: lazac | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.2.1 Resolution: | Keywords: RemoteGHCi Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by SoYman): I got a very similar error from the interpreter after doing these commands. {{{ Prelude Data.List> import qualified Data.Map.Strict as Map Prelude Data.List Map> data Dice = Dice Int Int Int Int Int Int deriving (Eq, Show) Prelude Data.List Map> Map.fromList [((0,0),(1, Dice 1 6 3 4 2 5))] ghc.exe: internal error: IMAGE_REL_AMD64_ADDR32[NB]: High bits are set in 13765d848 for .text (GHC version 8.4.3 for x86_64_unknown_mingw32) 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 Wed Jul 11 18:53:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 18:53:48 -0000 Subject: [GHC] #12045: Visible kind application In-Reply-To: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> References: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> Message-ID: <066.56d81d9df0a123c0107b68f97bbd768c@haskell.org> #12045: Visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mnguyen Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications TypeInType | GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ​Phab:D2216 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mnguyen): * owner: Iceland_jack => mnguyen Comment: Hi, I'm My Nguyen and I'm working with Richard on this :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 18:58:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 18:58:34 -0000 Subject: [GHC] #15360: Template Haskell splicing drops lots of type arguments Message-ID: <047.e6d2b23e630646579ceaa92c2d2bfbeb@haskell.org> #15360: Template Haskell splicing drops lots of type arguments -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template | Version: 8.4.3 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The conversion functions (in the `Convert` module) drop type arguments in various places. Here are two examples: {{{ data T a b c = Mk a b c bar :: $( return $ AppT (InfixT (ConT ''Int) ''T (ConT ''Bool)) (ConT ''Double) ) bar = Mk 5 True 3.14 }}} This correct code leads to an error {{{ Expecting one more argument to ‘T Int Bool’ }}} because the `Double` is forgotten. Similarly, {{{ baz :: $( return $ AppT (ParensT (ConT ''Maybe)) (ConT ''Int) ) baz = Just 5 }}} fails because `baz :: (Maybe)` isn't valid. On the other hand, {{{ frob :: forall (a :: $( [t| * Int |] )). a -> a frob x = x }}} is spuriously accepted, because GHC has forgotten about the `Int` argument. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 18:58:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 18:58:40 -0000 Subject: [GHC] #15361: Error message displays redundant equality constraint Message-ID: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> #15361: Error message displays redundant equality constraint -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: #14394 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiling this program: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind import Data.Type.Equality foo :: forall (a :: Type) (b :: Type) (c :: Type). a :~~: b -> a :~~: c foo HRefl = HRefl }}} GHC complains thus: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:12:13: error: • Could not deduce: a ~ c from the context: (* ~ *, b ~ a) bound by a pattern with constructor: HRefl :: forall k1 (a :: k1). a :~~: a, in an equation for ‘foo’ at Bug.hs:12:5-9 ‘a’ is a rigid type variable bound by the type signature for: foo :: forall a b c. (a :~~: b) -> a :~~: c at Bug.hs:(10,1)-(11,27) ‘c’ is a rigid type variable bound by the type signature for: foo :: forall a b c. (a :~~: b) -> a :~~: c at Bug.hs:(10,1)-(11,27) Expected type: a :~~: c Actual type: a :~~: a • In the expression: HRefl In an equation for ‘foo’: foo HRefl = HRefl • Relevant bindings include foo :: (a :~~: b) -> a :~~: c (bound at Bug.hs:12:1) | 12 | foo HRefl = HRefl | ^^^^^ }}} That `* ~ *` constraint is entirely redundant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 18:59:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 18:59:32 -0000 Subject: [GHC] #15360: Template Haskell splicing drops lots of type arguments In-Reply-To: <047.e6d2b23e630646579ceaa92c2d2bfbeb@haskell.org> References: <047.e6d2b23e630646579ceaa92c2d2bfbeb@haskell.org> Message-ID: <062.dd3fe66bc79064075f8502b427a95b8b@haskell.org> #15360: Template Haskell splicing drops lots of type arguments -------------------------------------+------------------------------------- Reporter: goldfire | Owner: mnguyen Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mnguyen): * owner: (none) => mnguyen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 19:00:58 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 19:00:58 -0000 Subject: [GHC] #15362: Template Haskell ignores bad type family definitions Message-ID: <047.0b0cf3afdce7ff5f14f7f40ab4e469a1@haskell.org> #15362: Template Haskell ignores bad type family definitions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template | Version: 8.4.3 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This garbage is accepted: {{{#!hs data Nat = Zero | Succ Nat $( [d| type family a + b where Maybe Zero b = b Succ a + b = Succ (a + b) |] ) }}} Note the `Maybe` photo-bombing in the first equation. The problem is that TH uses the symbol declared in the family head for all the equations, ignoring what's actually there. This is sad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 19:01:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 19:01:37 -0000 Subject: [GHC] #15362: Template Haskell ignores bad type family definitions In-Reply-To: <047.0b0cf3afdce7ff5f14f7f40ab4e469a1@haskell.org> References: <047.0b0cf3afdce7ff5f14f7f40ab4e469a1@haskell.org> Message-ID: <062.d51c7f9336bfc911c2d010311715c84a@haskell.org> #15362: Template Haskell ignores bad type family definitions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: mnguyen Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mnguyen): * owner: (none) => mnguyen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 19:05:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 19:05:48 -0000 Subject: [GHC] #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 In-Reply-To: <047.0e132514379b72c39d1662f2412d5748@haskell.org> References: <047.0e132514379b72c39d1662f2412d5748@haskell.org> Message-ID: <062.d623cd8a13fb67e708f664481cc80203@haskell.org> #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 -------------------------------------+------------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): Replying to [comment:4 slyfox]: > Normally '''COPY''' relocations are used only for immutable ('''const''' in C land) data. But '''_closure'''s are mutable. I'll double-check generated C code and file a toolchain bug upstream. James (jrtc27) pointed out that '''COPY''' relocations are fine for mutable data as long as shared library allows interposition of the symbol. James also noted that GHC uses '''-Bsymbolic''' which forbids symbol interposition and binds global symbols to library's definition. '''-Bsymbolic''' is set in '''GHC'''s driver: http://git.haskell.org/ghc.git/blob/HEAD:/compiler/main/SysTools.hs#l550 Thus smaller C-only reproducer that illustrates the problem is the following: {{{#!c /* lib.c: */ int things[] = { 99,98,97,96 }; int shlib_f(int i) { return things[i]; } }}} {{{#!c /* bin.c */ #include /* declarations from lib.c */ extern int things[]; int shlib_f(int i); int main() { printf("main (before store): things[0] = %i\n", things[0]); printf("shlib (before store): things[0] = %i\n", shlib_f(0)); things[0] = 45; /* check if library sees 'things' changed. It should */ printf("main (after store): things[0] = %i\n", things[0]); printf("shlib (after store): things[0] = %i\n", shlib_f(0)); return 0; } }}} {{{#!sh #/bin/bash # a.sh #cross=sh4-unknown-linux-gnu- cc=${cross}gcc cflags="-O1 -Wall" $cc $cflags -shared -fPIC lib.c -o libbug.so -Wl,-Bsymbolic $cc $cflags -fno-PIC -fno-PIE -no-pie bin.c -o bug.no-pie -L. -lbug -Wl,-rpath=. $cc $cflags -fPIC -fPIE -pie bin.c -o bug.pie -L. -lbug -Wl,-rpath=. echo "target: ${cross}; emulator=${emulator}; no-pie:" ${emulator} ./bug.no-pie echo "target: ${cross}; emulator=${emulator}; pie:" ${emulator} ./bug.pie }}} Here we define a shared library with '''things''' global symbol and '''shlib_f()''' that refers to that global symbol. Here is how things break (even on '''x86_64'''): {{{ $ cross=x86_64-pc-linux-gnu- emulator= ./a.sh target: x86_64-pc-linux-gnu-; emulator=; no-pie: main (before store): things[0] = 99 shlib (before store): things[0] = 99 main (after store): things[0] = 45 shlib (after store): things[0] = 99 target: x86_64-pc-linux-gnu-; emulator=; pie: main (before store): things[0] = 99 shlib (before store): things[0] = 99 main (after store): things[0] = 45 shlib (after store): things[0] = 99 }}} Note: the value of '''things[0]''' disagrees between binary and library copy. That's how we get '''stdout''' closure evaluated twice. It matter because '''stdout''' is devined via '''unsafePerformIO''': {{{#!hs -- libraries/base/GHC/IO/Handle/FD.hs stdout :: Handle {-# NOINLINE stdout #-} stdout = unsafePerformIO $ do -- ToDo: acquire lock setBinaryMode FD.stdout enc <- getLocaleEncoding mkHandle FD.stdout "" WriteHandle True (Just enc) nativeNewlineMode{-translate newlines-} (Just stdHandleFinalizer) Nothing }}} Here we effectively allocate the buffer cache as many times as '''stdout''' is evaluated. This breaks the invariant of '''unsafePerformIO''' being evaluated only once. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 19:15:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 19:15:42 -0000 Subject: [GHC] #15363: Do some cleaning up of the testsuite driver Message-ID: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> #15363: Do some cleaning up of the testsuite driver -------------------------------------+------------------------------------- Reporter: lantti | Owner: (none) Type: task | Status: new Priority: low | Milestone: 8.6.1 Component: Test Suite | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When trying to understand the GHC test suite I noticed some small improvements that I could do to it. This would probably work nicely as my first task on GHC: Rewrite the timeout.hs in python, it doesn't seem to do anything that would strictly need the Haskell libraries to be used and it is the only part of the test suite driver that is not written in python. Or; See if the timeout scripts could be eliminated altogether as the python subprocess module that we are using can now (since python 3.3) handle timeouts by itself and using the timeout scripts effectively doubles the number of processes we need to create for each test case. Notice that the timeout scripts do more than just generating the timeout. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 19:16:21 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 19:16:21 -0000 Subject: [GHC] #15363: Do some cleaning up of the testsuite driver In-Reply-To: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> References: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> Message-ID: <060.d2c87865ec03d5f50c5dddf740ff08a3@haskell.org> #15363: Do some cleaning up of the testsuite driver -------------------------------------+------------------------------------- Reporter: lantti | Owner: lantti Type: task | Status: new Priority: low | Milestone: 8.6.1 Component: Test Suite | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lantti): * owner: (none) => lantti -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 19:39:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 19:39:44 -0000 Subject: [GHC] #15364: Replace the atomicModifyMutVar# primop Message-ID: <045.aa8fbba8dcbd166d60f806e361779d6c@haskell.org> #15364: Replace the atomicModifyMutVar# primop -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Runtime | Version: 8.5 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4884 | Wiki Page: -------------------------------------+------------------------------------- This was [https://github.com/ghc-proposals/ghc- proposals/blob/master/proposals/0027-atomicModifyMutVar.rst accepted proposal #27]. Specifically: 1. Replace `atomicModifyMutVar#` with `atomicModifyMutVar2#`. 2. Add `atomicModifyMutVar_#` and `atomicSwapMutVar#`. 3. Add a function imitating `atomicModifyMutVar#` to `GHC.Exts` for backwards compatibility. 4. Use the new primops where appropriate throughout `base`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 19:48:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 19:48:25 -0000 Subject: [GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 In-Reply-To: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> References: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> Message-ID: <066.c993d6834e1e553db58426e5779bbf0b@haskell.org> #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Great, thanks a lot for that. 95 seconds is a lot more manageable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 19:49:17 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 19:49:17 -0000 Subject: [GHC] #15364: Replace the atomicModifyMutVar# primop In-Reply-To: <045.aa8fbba8dcbd166d60f806e361779d6c@haskell.org> References: <045.aa8fbba8dcbd166d60f806e361779d6c@haskell.org> Message-ID: <060.8d1d335101fe41c6f2fe89c146eb2ece@haskell.org> #15364: Replace the atomicModifyMutVar# primop -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4884 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: fryguybob (added) Comment: I've put up a differential that implements everything except `atomicSwapMutVar#`, and that sets the stage for adding that as well. I could use some help with `atomicSwapMutVar#`, which is the only primop I ''can't'' implement by just removing code from other ones. I think we'll probably need to add C bits to get access to the necessary exchange intrinsic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 20:05:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 20:05:44 -0000 Subject: [GHC] #15365: Argument-less infix declarations printed without parentheses in -ddump-splices Message-ID: <050.44adfa65cdb3af03785c9fae8905524a@haskell.org> #15365: Argument-less infix declarations printed without parentheses in -ddump- splices -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template | Version: 8.4.3 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Debugging Unknown/Multiple | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compile this: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where $([d| type (|||) = Either (&&&) :: Bool -> Bool -> Bool (&&&) = (&&) data (***) |]) }}} And you'll get this: {{{ $ /opt/ghc/8.4.3/bin/ghci Bug.hs GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(6,3)-(12,6): Splicing declarations [d| (&&&_a1xt) :: Bool -> Bool -> Bool (&&&_a1xt) = (&&) type |||_a1xs = Either data ***_a1xr |] ======> type |||_a5bW = Either (&&&_a5bV) :: Bool -> Bool -> Bool (&&&_a5bV) = (&&) data ***_a5bX Ok, one module loaded. }}} Notice the pretty-printed declarations of `type |||_a5bW` and `data ***_a5bX`, which are lacking some necessary parentheses. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 21:33:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 21:33:25 -0000 Subject: [GHC] #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 In-Reply-To: <047.0e132514379b72c39d1662f2412d5748@haskell.org> References: <047.0e132514379b72c39d1662f2412d5748@haskell.org> Message-ID: <062.729c6afeb99c8fee0c7c5107ccd459f2@haskell.org> #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 -------------------------------------+------------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrtc27): Replying to [comment:5 slyfox]: > Replying to [comment:4 slyfox]: > > Normally '''COPY''' relocations are used only for immutable ('''const''' in C land) data. But '''_closure'''s are mutable. I'll double-check generated C code and file a toolchain bug upstream. > > James (jrtc27) pointed out that '''COPY''' relocations are fine for mutable data as long as shared library allows interposition of the symbol. James also noted that GHC uses '''-Bsymbolic''' which forbids symbol interposition and binds global symbols to library's definition. Even for immutable data it can pose problematic if you perform address comparisons, but you're right that mutable data can lead to more problems. > {{{ > $ cross=x86_64-pc-linux-gnu- emulator= ./a.sh > > target: x86_64-pc-linux-gnu-; emulator=; no-pie: > main (before store): things[0] = 99 > shlib (before store): things[0] = 99 > main (after store): things[0] = 45 > shlib (after store): things[0] = 99 > target: x86_64-pc-linux-gnu-; emulator=; pie: > main (before store): things[0] = 99 > shlib (before store): things[0] = 99 > main (after store): things[0] = 45 > shlib (after store): things[0] = 99 > }}} > > Note: the value of '''things[0]''' disagrees between binary and library copy. Actually x86_64 is more unusual here in that PIE is *also* broken by this. Most architectures will fall back on the normal GOT mechanisms for PIE, but on x86_64 RIP-relative addressing is available, giving a cheaper position-independent way to access globals (and of course it's still fine for PIE because we can still use COPY relocations). If you were to run that for i386 or a traditional RISC architecture, you would see that PIE did not exhibit the bug. Surely the way forward is to ditch `-Bsymbolic`, and ensure that whatever non-PIC patterns exist (as mentioned by https://ghc.haskell.org/trac/ghc/wiki/Commentary/PositionIndependentCode#LinkingonELF) in the DSOs produced are fixed? Presumably the only non-PIC bits are whatever would work for PIE (otherwise how on earth can you have a variable image base) and must be PC-relative? For code that should be fine (you could even use `-Bsymbolic-functions` and I believe it would work), and for data there can't be many instances. In fact, I think `-Bsymbolic` might well work just fine for NCG as it already tries to avoid COPY relocations (does it always successfully avoid them?), in which case we could just drop `-Bsymbolic` when compiling via C (GCC should just do the right thing if you give it valid C). Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 21:48:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 21:48:33 -0000 Subject: [GHC] #15363: Do some cleaning up of the testsuite driver In-Reply-To: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> References: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> Message-ID: <060.327bb1ac4040d210db0e7abc55ad7816@haskell.org> #15363: Do some cleaning up of the testsuite driver -------------------------------------+------------------------------------- Reporter: lantti | Owner: lantti Type: task | Status: new Priority: low | Milestone: 8.6.1 Component: Test Suite | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): There's already a Python version (timeout.py), it's apparently needed sometimes on Windows; see TIMEOUT_PROGRAM in Makefile. This specialcasing is from 2009, it's likely it can be removed but it needs checking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 22:06:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 22:06:50 -0000 Subject: [GHC] #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 In-Reply-To: <047.0e132514379b72c39d1662f2412d5748@haskell.org> References: <047.0e132514379b72c39d1662f2412d5748@haskell.org> Message-ID: <062.525141b40258a581bd1c74f8defbc2da@haskell.org> #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 -------------------------------------+------------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jrtc27): * cc: jrtc27 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 22:24:31 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 22:24:31 -0000 Subject: [GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 In-Reply-To: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> References: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> Message-ID: <066.61071b26600c406d697f6c7ba16f5207@haskell.org> #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): You can make the process faster by removing methods from `instance Floating Cl3` - it seems that every one of the 12 methods slows down the compilation by few seconds. For example, if you keep `exp` and `log` only it's 22 sec (and the root cause should still be present). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 22:54:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 22:54:01 -0000 Subject: [GHC] #15361: Error message displays redundant equality constraint In-Reply-To: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> References: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> Message-ID: <065.c109689edad77cc488e13ac4d52e295c@haskell.org> #15361: Error message displays redundant equality constraint -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14394 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): But you put it there, by matching on heterogeneous equality on types all of kind `Type`. Do you propose that GHC not mention givens that are implied by other givens? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 23:09:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 23:09:01 -0000 Subject: [GHC] #15361: Error message displays redundant equality constraint In-Reply-To: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> References: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> Message-ID: <065.51788d043c01a611a9ce506614d5d0c9@haskell.org> #15361: Error message displays redundant equality constraint -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14394 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:1 goldfire]: > Do you propose that GHC not mention givens that are implied by other givens? Certainly not, and moreover, GHC already does not mention redundant implied givens in certain situations. In this code: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeOperators #-} import Data.Type.Equality data Goo a where MkGoo :: (Ord a, a ~ Bool) => a -> Goo a goo :: Goo a -> a :~: b goo MkGoo{} = Refl }}} {{{ Bug.hs:10:15: error: • Could not deduce: b ~ Bool from the context: (Ord a, a ~ Bool) bound by a pattern with constructor: MkGoo :: forall a. (Ord a, a ~ Bool) => a -> Goo a, in an equation for ‘goo’ at Bug.hs:10:5-11 ‘b’ is a rigid type variable bound by the type signature for: goo :: forall a b. Goo a -> a :~: b at Bug.hs:9:1-23 Expected type: a :~: b Actual type: a :~: a • In the expression: Refl In an equation for ‘goo’: goo MkGoo {} = Refl • Relevant bindings include goo :: Goo a -> a :~: b (bound at Bug.hs:10:1) | 10 | goo MkGoo{} = Refl | ^^^^ }}} GHC does not bother warning about an `Eq a` constraint being in the context bound by the `MkGoo` pattern match, even though it is implied by `Ord a`. Moreover, in this code: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeOperators #-} import Data.Type.Equality hoo :: Int :~: Int -> a :~: b -> a :~: c hoo Refl Refl = Refl }}} {{{ Bug.hs:7:17: error: • Could not deduce: a ~ c from the context: b ~ a bound by a pattern with constructor: Refl :: forall k (a :: k). a :~: a, in an equation for ‘hoo’ at Bug.hs:7:10-13 ‘a’ is a rigid type variable bound by the type signature for: hoo :: forall a b c. (Int :~: Int) -> (a :~: b) -> a :~: c at Bug.hs:6:1-40 ‘c’ is a rigid type variable bound by the type signature for: hoo :: forall a b c. (Int :~: Int) -> (a :~: b) -> a :~: c at Bug.hs:6:1-40 Expected type: a :~: c Actual type: a :~: a • In the expression: Refl In an equation for ‘hoo’: hoo Refl Refl = Refl • Relevant bindings include hoo :: (Int :~: Int) -> (a :~: b) -> a :~: c (bound at Bug.hs:7:1) | 7 | hoo Refl Refl = Refl | ^^^^ }}} GHC does not warn about an `Int ~ Int` constraint, even though we "put it there" by matching on a value of type `Int :~: Int`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 11 23:59:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 11 Jul 2018 23:59:26 -0000 Subject: [GHC] #15363: Do some cleaning up of the testsuite driver In-Reply-To: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> References: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> Message-ID: <060.1525e68a16ff9e49462dfb4de09c0fed@haskell.org> #15363: Do some cleaning up of the testsuite driver -------------------------------------+------------------------------------- Reporter: lantti | Owner: lantti Type: task | Status: new Priority: low | Milestone: 8.6.1 Component: Test Suite | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lantti): If I'm reading correctly the Python version is the POSIX-only one. The Haskell version is used for all Windows runs. In order to not rely on my code reading skills I manually run timeout.py on Windows and Linux (python3 timeout3 10 "sleep 2"), results: Windows says "module 'os' has no attribute 'fork'", Linux just works. The Windows version definitely still relies on the Haskell implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 00:10:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 00:10:03 -0000 Subject: [GHC] #15363: Do some cleaning up of the testsuite driver In-Reply-To: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> References: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> Message-ID: <060.f35bbb96aaf0c3d0f8873f27fe37e6ec@haskell.org> #15363: Do some cleaning up of the testsuite driver -------------------------------------+------------------------------------- Reporter: lantti | Owner: lantti Type: task | Status: new Priority: low | Milestone: 8.6.1 Component: Test Suite | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by lantti: Old description: > When trying to understand the GHC test suite I noticed some small > improvements that I could do to it. This would probably work nicely as my > first task on GHC: > > Rewrite the timeout.hs in python, it doesn't seem to do anything that > would strictly need the Haskell libraries to be used and it is the only > part of the test suite driver that is not written in python. > > Or; > > See if the timeout scripts could be eliminated altogether as the python > subprocess module that we are using can now (since python 3.3) handle > timeouts by itself and using the timeout scripts effectively doubles the > number of processes we need to create for each test case. Notice that the > timeout scripts do more than just generating the timeout. New description: When trying to understand the GHC test suite I noticed some small improvements that I could do to it. This would probably work nicely as my first task on GHC: Rewrite the timeout.hs in python, it is used for Windows runs but it doesn't seem to do anything that would strictly need the Haskell libraries to be used and it is the only part of the test suite driver that is not written in python. Or; See if the timeout scripts could be eliminated altogether as the python subprocess module that we are using can now (since python 3.3) handle timeouts by itself and using the timeout scripts effectively doubles the number of processes we need to create for each test case. Notice that the timeout scripts do more than just generating the timeout. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 00:16:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 00:16:16 -0000 Subject: [GHC] #15366: GHC.Conc.Windows has a surprising queue Message-ID: <045.4d027c14d6779c15e2428ddd193b98f5@haskell.org> #15366: GHC.Conc.Windows has a surprising queue -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Core | Version: 8.4.3 Libraries | 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: -------------------------------------+------------------------------------- `GHC.Conc.Windows` seems to use `[DelayReq]` as a priority queue, and uses `foldr` to insert multiple elements into it. Unless these lists are always very short (are they?) that seems like a bad idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 00:23:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 00:23:42 -0000 Subject: [GHC] #15366: GHC.Conc.Windows has a surprising queue In-Reply-To: <045.4d027c14d6779c15e2428ddd193b98f5@haskell.org> References: <045.4d027c14d6779c15e2428ddd193b98f5@haskell.org> Message-ID: <060.2e2881b3dabc8921f3041308ea889749@haskell.org> #15366: GHC.Conc.Windows has a surprising queue -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 00:31:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 00:31:56 -0000 Subject: [GHC] #15359: Quantified constraints do not work with equality constraints In-Reply-To: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> References: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> Message-ID: <062.f9d6a3660a67d03e9ea898d095b4af50@haskell.org> #15359: Quantified constraints do not work with equality constraints -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:1 RyanGlScott]: > It's very strange to me that we allow quantified `Coercible` constraints but not quantified `(~)` constraints. What is the rationale behind this decision choice? Yes, I'm gravely disappointed to learn that: I've been posting lots of suggestions using `~` inside quantified (implication) constraints. {{{ • Class ‘~’ does not support user-specified instances }}} Before there was `~`, there were plenty of ways for a user to specify a unifiability constraint -- see for example `TypeCast` in the HList paper. (Using bi-directional FunDeps.) And other examples of Quantified Constraints are using FunDeps for type improvement. So just do that instead of `~`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 01:43:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 01:43:38 -0000 Subject: [GHC] #15361: Error message displays redundant equality constraint In-Reply-To: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> References: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> Message-ID: <065.65b86d0bf88547a99dbba3c875155b0d@haskell.org> #15361: Error message displays redundant equality constraint -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14394 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I find the second example more convincing than the first. I wonder how we do that... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 01:46:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 01:46:01 -0000 Subject: [GHC] #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 In-Reply-To: <047.0e132514379b72c39d1662f2412d5748@haskell.org> References: <047.0e132514379b72c39d1662f2412d5748@haskell.org> Message-ID: <062.015d6e64a7a55363e57dbc8250aaced1@haskell.org> #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 -------------------------------------+------------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed we had similar [https://sourceware.org/bugzilla/show_bug.cgi?id=16177 issues] on ARM resulting in #4210. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 01:47:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 01:47:43 -0000 Subject: [GHC] #15359: Quantified constraints do not work with equality constraints In-Reply-To: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> References: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> Message-ID: <062.92c64a07761b0a295d2cbe5af351abbb@haskell.org> #15359: Quantified constraints do not work with equality constraints -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Simon and I discussed this today. The lack of symmetry between `Coercible` and `~` here is by design. Essentially, any equality implication constraint is guaranteed to be redundant, because GHC can already deduce all equalities from whatever assumptions are at hand. On the other hand, `Coercible` implication constraints are quite useful, because coercibility is fundamentally incomplete. So the trouble I saw isn't so bad. But I still think we should document the restriction and report a better error message here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 03:04:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 03:04:00 -0000 Subject: [GHC] #15359: Quantified constraints do not work with equality constraints In-Reply-To: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> References: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> Message-ID: <062.68504bd2cf7395cea1e07cd04e847c3a@haskell.org> #15359: Quantified constraints do not work with equality constraints -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) Comment: Redundant in what sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 06:34:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 06:34:59 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.b4a84c9c61bb7e32d950185c8ee83a38@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): I also tried checking out the actual phab patch, but that too fails to build during `validate`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 07:23:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 07:23:47 -0000 Subject: [GHC] #15359: Quantified constraints do not work with equality constraints In-Reply-To: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> References: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> Message-ID: <062.ed41a74619a54b9119e6329dac139a07@haskell.org> #15359: Quantified constraints do not work with equality constraints -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Redundant in what sense? Well, can you show me a quantified constraint with an equality in the head that is not useless? For example what about this (by analogy with `Coercible`) {{{ f :: forall m. (forall a b. a ~ b => m a ~ m b) => blah }}} No, that redundant. If we have `[W] t1 a ~ t2 b` there is a built-in rule to decompose it to `[W] t1 ~ t2` and `[W] a ~ b`. (There is no such rule in general for `Coercible` which is why we need to allow it.) So that quantified constraint wasn't useful. Can you think of one that is? I can't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 08:21:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 08:21:13 -0000 Subject: [GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 In-Reply-To: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> References: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> Message-ID: <066.183d63d62842f4e04355f192784c2f9a@haskell.org> #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): This is very useful. The reduced `Cl3.hs` with all `Floating` methods except `exp` and `log` removed gives a much cleaner result. Looking at `-ddump-rule-firings` output, here's counters of how often each rule fired on 8.0.2 and 8.4.3: {{{ rule | 8.0 8.4 --------------------------+------------ *## | 127 44 +## | 26 372 ^2/Integer | 55 55 Class op - | 419 417 Class op / | 15 8 Class op * | 1698 1693 Class op ** | 3 2 Class op + | 737 734 Class op abs | 5 5 Class op atan2 | 1 1 Class op cos | 7 5 Class op cosh | 3 2 Class op exp | 14 10 Class op fromInteger | 13 8 Class op fromRational | 4 2 Class op log | 20 14 Class op log1p | 6 4 Class op negate | 109 106 Class op $p1Floating | 25 16 Class op $p1Fractional | 20 12 Class op pi | 1 1 Class op recip | 4 3 Class op sin | 7 5 Class op sinh | 3 2 Class op sqrt | 14 14 doubleFromInteger | 9 7 SC:$clog0 | 6 0 SC:$w$catan20 | 1 0 }}} So it looks like a change to the way `SpecConstr`s are handled is preventing either specializations, or `RULES` that follow from them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 08:23:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 08:23:08 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.f6896711daa868ceb28f41091e4b5ed3@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): This is probably a StgCSE bug as disabling it fixes this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 09:00:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 09:00:31 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.66f337c11313f9122b103d3bc97b7ccf@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Looking at STG before and after CSE, the only difference is: {{{ case val_scuG of { (#_|#) err_scuJ [Occ=Once] -> case (#_|#) [err_scuJ] of sat_scuK [Occ=Once] { __DEFAULT -> Main.$w$j ipv_scuC leftovers1_scuF sat_scuK; }; ... }}} becomes: {{{ case val_scuG of { (#_|#) err_scuJ [Occ=Once] -> case wild2_scuI of sat_scuK [Occ=Once] { __DEFAULT -> Main.$w$j ipv_scuC leftovers1_scuF sat_scuK; }; ... }}} But note that wild2_scuI was dead before (dead binders are not printed by the STG printer so I'm not sure where it's bound). If the problem is reviving wild2_scuI then this is a duplicate of #14895. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 09:38:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 09:38:37 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.33b4ae6a0b79be4501b0b0214e34d23b@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Confirmed that the transformation above is the problem. With this transformation the unarised expression: {{{ Main.$w$j GHC.Prim.void# us_gcvd us_gcve us_gcvf us_gcvg us_gcvh 1# us_gcvj; }}} becomes {{{ Main.$w$j GHC.Prim.void# us_gcvd us_gcve us_gcvf us_gcvg us_gcvh us_gcvi us_gcvj us_gcvk us_gcvl; }}} We now pass more arguments to `$w$j`! I had spent some time debugging this in the assembly level and found out that `stg_ap_n` is trying to apply a non-pointer to a constructor. If we're passing more arguments to function or a constructor than this kind of error makes sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 10:04:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 10:04:18 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.ae0fb6cc5901ba61885652b054bcb322@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I hacked the Id printer to print dead binders with their types. It turns out the dead-but-used binder is this: {{{ wild2_scuI [Occ=Dead] :: (# GHC.Maybe.Maybe GHC.Types.Any | Packed.Bytes.Parser.Bytes# #) }}} This kind of variables (dead case binders with unboxed sum/tuple types) are not supposed to be used! We even have a comment about this in `UnariseStg`: {{{ unariseExpr rho (StgCase scrut bndr alt_ty alts) ... -- general case | otherwise = do scrut' <- unariseExpr rho scrut alts' <- unariseAlts rho alt_ty bndr alts return (StgCase scrut' bndr alt_ty alts') -- bndr may have a unboxed sum/tuple type but it will be -- dead after unarise (checked in StgLint) }}} and we actually check this in StgLint: {{{ lintStgExpr (StgCase scrut bndr alts_type alts) = do ... -- Case binders of unboxed tuple or unboxed sum type always dead -- after the unariser has run. -- See Note [Post-unarisation invariants]. MultiValAlt _ -> not (lf_unarised lf) ... }}} I don't understand yet why this program passes StgLint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 10:45:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 10:45:04 -0000 Subject: [GHC] #14164: GHC hangs on type family dependency In-Reply-To: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> References: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> Message-ID: <066.37eae18adf69c162b71addd5dcf9a2f2@haskell.org> #14164: GHC hangs on type family dependency -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T14164 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: fixed => Comment: Richard and I had a chat yesterday. He is going to * Write the invariant in comment:13, along with a Note to explain it (based on this ticket). * Add an ASSERT to check it. * Comment `substTy` and `substCo`, in the variable cases, to explain why we do not need to substitute in the kind of a type variable, or the type of a coercion variable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 10:46:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 10:46:01 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.935c2875b05897f0daa519a7c46e4212@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Aha! The problem is StgCse's term equality check does not work on unboxed sums. Are these two equal? (and a binder to one could be substituted for the other?) - `(# 1# | #) :: (# Int# | Bool #)` - `(# 1# | #) :: (# Int# | Int# #)` Of course not, becuse first one unarises to `(# 1#, 1#, absentSumField #)` while the second one unarises to `(# 1#, 1# #)`. Not sure how to compare unboxed sums for equality in StgCse as we don't have enough type information at that point. However, it seems to me that CSE on unboxed sums is useless as unboxed sums are not allocated (so CSE doesn't buy us anything). Maybe we should just not do CSE on unboxed sum (and maybe even tuple) terms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 10:51:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 10:51:10 -0000 Subject: [GHC] #14164: GHC hangs on type family dependency In-Reply-To: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> References: <051.ccd0e08cf369acbbc420327bafc96397@haskell.org> Message-ID: <066.15e92100a65b492650fbc78976590cbb@haskell.org> #14164: GHC hangs on type family dependency -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T14164 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yikes! I've just rediscovered #13959 which is precisely the same territory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 11:16:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 11:16:57 -0000 Subject: [GHC] #14873: The well-kinded type invariant (in TcType) In-Reply-To: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> References: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> Message-ID: <065.11991a9490e69299733ab8476f4f74d7@haskell.org> #14873: The well-kinded type invariant (in TcType) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Another thing that came up yesterday: there are some calls to `eqType` where we know for sure the the kinds are the same, so checking the kinds as well is redundant. e.g. the use of `eqType` in `checkExpectedKinds`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 11:34:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 11:34:37 -0000 Subject: [GHC] #15367: Misleading error message when unboxed tuples used in sums without -XUnboxedTuples Message-ID: <043.fdd57e403d89bbe323256da83c97f6b3@haskell.org> #15367: Misleading error message when unboxed tuples used in sums without -XUnboxedTuples -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ cat lib.hs {-# LANGUAGE UnboxedSums #-} module Lib where type Foo = (# (# Int, Int #) | Int #) $ ghc lib.hs [1 of 1] Compiling Lib ( lib.hs, lib.o ) lib.hs:5:1: error: • Illegal unboxed tuple type as function argument: (# Int, Int #) • In the type synonym declaration for ‘Foo’ | 5 | type Foo = (# (# Int, Int #) | Int #) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} But there's nothing illegal about this type, we just need to enable `UnboxedTuples`. The error message is misleading. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 11:35:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 11:35:25 -0000 Subject: [GHC] #15367: Misleading error message when unboxed tuples used in sums without -XUnboxedTuples In-Reply-To: <043.fdd57e403d89bbe323256da83c97f6b3@haskell.org> References: <043.fdd57e403d89bbe323256da83c97f6b3@haskell.org> Message-ID: <058.c9847587d14ba98d233d4256a63a7e6a@haskell.org> #15367: Misleading error message when unboxed tuples used in sums without -XUnboxedTuples -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: > {{{ > $ cat lib.hs > {-# LANGUAGE UnboxedSums #-} > > module Lib where > > type Foo = (# (# Int, Int #) | Int #) > > $ ghc lib.hs > [1 of 1] Compiling Lib ( lib.hs, lib.o ) > > lib.hs:5:1: error: > • Illegal unboxed tuple type as function argument: (# Int, Int #) > • In the type synonym declaration for ‘Foo’ > | > 5 | type Foo = (# (# Int, Int #) | Int #) > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > }}} > > But there's nothing illegal about this type, we just need to enable > `UnboxedTuples`. The error message is misleading. New description: {{{ $ cat lib.hs {-# LANGUAGE UnboxedSums #-} module Lib where type Foo = (# (# Int, Int #) | Int #) $ ghc lib.hs [1 of 1] Compiling Lib ( lib.hs, lib.o ) lib.hs:5:1: error: • Illegal unboxed tuple type as function argument: (# Int, Int #) • In the type synonym declaration for ‘Foo’ | 5 | type Foo = (# (# Int, Int #) | Int #) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} But there's nothing illegal about this type, we just need to enable `UnboxedTuples`. The error message is misleading. (We should also check using unboxed sums inside tuples) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 11:53:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 11:53:51 -0000 Subject: [GHC] #15359: Quantified constraints do not work with equality constraints In-Reply-To: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> References: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> Message-ID: <062.e77959082b0adf5b342da00b941e5a7b@haskell.org> #15359: Quantified constraints do not work with equality constraints -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:6 simonpj]: > > Well, can you show me a quantified constraint with an equality in the head that is not useless? Remembering that this extension includes implication constraints, not only quantified, I can think of plenty. Here's one close to David's heart, per [https://mail.haskell.org/pipermail/ghc-devs/2017-November/015073.html this message]. "Reasoning backwards with type families". Suppose a class (rather than Type Family) for `And` over type-level Booleans: if we know the result is `True`, that gives an implication for the arguments: {{{ class (c ~ 'True => a ~ 'True, c ~ 'True => b ~ 'True) => And (a :: Bool) (b :: Bool) (c :: Bool) }}} (And further implications would apply, per David's message. So this is a general technique for injectivity or partial/quasi-injectivity. Doesn't Richard's "fundamentally incomplete" apply here: there is not complete injectivity from result to arguments. So the implication `=>` says: ''if'' the lhs constraint/equality holds, ''then'' you can use the rhs constraint/equality; otherwise (i.e. the lhs doesn't hold) the `=>` holds anyway.) Richard says >> any equality implication constraint is guaranteed to be redundant, because GHC can already deduce all equalities from whatever assumptions are at hand. For `And` that would need taking the instances as assumptions, **plus** making an assumption those are the only instances. Whereas my reading of the papers (seems I'm wrong) is that when `QuantifiedConstraints` sees those superclass constraints, it will assume them for type improvement, and verify they hold for each instance decl. > > Can you think of one that is? I can't. If you want an example with quantification: {{{ class (forall b'. C a b' => b' ~ b) => C a b where ... }}} Which is more-or-less verbatim from the textbooks as a FOPL definition of ... a Functional Dependency -- that is, in relational database textbooks. And appears more-or-less verbatim in Mark P Jones papers on FunDeps and in the 'FDs through CHRs' paper. I'm talking about FOPL because the hs2017 paper (opening sentence) says "Quantified class constraints have been proposed many years ago to raise the expressive power of type classes from Horn clauses to first-order logic." That "proposed many years ago" cites your 2000 paper (with Ralf). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 12:07:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 12:07:21 -0000 Subject: [GHC] #15367: Misleading error message when unboxed tuples used in sums without -XUnboxedTuples In-Reply-To: <043.fdd57e403d89bbe323256da83c97f6b3@haskell.org> References: <043.fdd57e403d89bbe323256da83c97f6b3@haskell.org> Message-ID: <058.b6751fb68bda3c04c77086d95c77585a@haskell.org> #15367: Misleading error message when unboxed tuples used in sums without -XUnboxedTuples -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Indeed. Perhaps you can enhance the message to say "Perhaps you intended to use UnboxedTuples` (or whatever our standard wording is for such suggestions)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 12:09:50 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 12:09:50 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.a88757776c685b6017f52fbe3c1e8259@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks for finishing this up! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 12:17:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 12:17:21 -0000 Subject: [GHC] #15367: Misleading error message when unboxed tuples used in sums without -XUnboxedTuples In-Reply-To: <043.fdd57e403d89bbe323256da83c97f6b3@haskell.org> References: <043.fdd57e403d89bbe323256da83c97f6b3@haskell.org> Message-ID: <058.ef433aeba9e9a269292899234e8ad551@haskell.org> #15367: Misleading error message when unboxed tuples used in sums without -XUnboxedTuples -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15073 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #15073 Comment: This is an (indirect) duplicate of #15073, which has been fixed in GHC 8.6.1. In GHC 8.6.1, your program does indeed suggest enabling `UnboxedTuples`: {{{ $ /opt/ghc/8.6.1/bin/ghc Bug.hs [1 of 1] Compiling Lib ( Bug.hs, Bug.o ) Bug.hs:5:1: error: • Illegal unboxed tuple type as function argument: (# Int, Int #) Perhaps you intended to use UnboxedTuples • In the type synonym declaration for ‘Foo’ | 5 | type Foo = (# (# Int, Int #) | Int #) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 12:42:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 12:42:19 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.cd6f6511af20198cac944d23f53c917f@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I had posted about the fix for that behavior on the Well-Typed GitLab page, but I've now also updated Phab. If you download again from there, you should hopefully be OK. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 13:04:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 13:04:32 -0000 Subject: [GHC] #15368: Type families, holes and -fdefer-type-errors may cause 'opt_univ fell into a hole' panic Message-ID: <050.73f861b4bff033457b6f954137086e2e@haskell.org> #15368: Type families, holes and -fdefer-type-errors may cause 'opt_univ fell into a hole' panic -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program, when compiled like `ghc -fdefer-type-errors -c panic.hs`: {{{#!hs {-# LANGUAGE TypeFamilies #-} module MorePanic where transitive :: (a, b) -> (b, c) -> (a, c) transitive = undefined trigger :: a -> b -> (F a b, F b a) trigger _ _ = _ `transitive` trigger _ _ type family F (n :: *) (m :: *) :: * }}} Gives this panic after several error messages: {{{ ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-mingw32): opt_univ fell into a hole {co_a7Sj} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler\utils\Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler\\types\\OptCoercion.hs:242:5 in ghc:OptCoercion Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This bug also affects GHCi. Attached is full output -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 13:05:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 13:05:04 -0000 Subject: [GHC] #15368: Type families, holes and -fdefer-type-errors may cause 'opt_univ fell into a hole' panic In-Reply-To: <050.73f861b4bff033457b6f954137086e2e@haskell.org> References: <050.73f861b4bff033457b6f954137086e2e@haskell.org> Message-ID: <065.eb7a046f15276c2cfa3fe06ba5570586@haskell.org> #15368: Type families, holes and -fdefer-type-errors may cause 'opt_univ fell into a hole' panic -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dramforever): * Attachment "fell-into-a-hole.txt" added. Full output when using GHC 8.4.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 13:18:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 13:18:52 -0000 Subject: [GHC] #15368: Type families, holes and -fdefer-type-errors may cause 'opt_univ fell into a hole' panic In-Reply-To: <050.73f861b4bff033457b6f954137086e2e@haskell.org> References: <050.73f861b4bff033457b6f954137086e2e@haskell.org> Message-ID: <065.eec4003d0d23c863b25e2790a52e95d9@haskell.org> #15368: Type families, holes and -fdefer-type-errors may cause 'opt_univ fell into a hole' panic -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Seems ok in HEAD, I'm happy to say. I'm not sure about the 8.6 branch. Regardless, could someone add a regression test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 13:23:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 13:23:08 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.4a0cdf992d0dc373a1f5aac73a2039d7@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Good sleuthing! What about doing StgCse after unarising? Then the difference would be obvious! We do CSE in STG even though we've done it already in Core, because we can sometimes common-up things that have the same representation in STG even though they have different types in Core. So it's possible that as well as prevent bogus CSE in the case you describe, you might get extra CSE in some other case. But I'm not close enough to StgCSE to think of an example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 13:35:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 13:35:26 -0000 Subject: [GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 In-Reply-To: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> References: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> Message-ID: <066.b5a1d6b7ad27276638bdb70c85e4197f@haskell.org> #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Compiling with `-fno-spec-constr` makes no difference performance wise, but gets rid of the SC:... rule firings, so those weren't the culprit after all. Investigating further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 14:52:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 14:52:21 -0000 Subject: [GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 In-Reply-To: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> References: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> Message-ID: <066.12f059c6034b8c8b66b4c00303fea68d@haskell.org> #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): OK, next experiment: compile with `-fno-specialise`, and diff `-ddump- simpl-stats` output (minus the PreInline and PostInline parts). Which gives us: {{{#!diff --- stats-8.0.2/Cl3.dump-simpl-stats 2018-07-12 16:25:23.219578828 +0200 +++ stats-8.4.3/Cl3.dump-simpl-stats 2018-07-12 16:42:41.644219237 +0200 @@ -1,74 +1,78 @@ ==================== FloatOut stats: ==================== -2018-07-12 13:46:13.85196043 UTC +2018-07-12 14:25:41.716397419 UTC -140 Lets floated to top level; 0 Lets floated elsewhere; from 35 Lambda groups +131 Lets floated to top level; 0 Lets floated elsewhere; from 22 Lambda groups ==================== FloatOut stats: ==================== -2018-07-12 13:46:17.767931325 UTC +2018-07-12 14:26:18.231633767 UTC -24 Lets floated to top level; 0 Lets floated elsewhere; from 42 Lambda groups +1 Lets floated to top level; 0 Lets floated elsewhere; from 25 Lambda groups ==================== Grand total simplifier statistics ==================== -2018-07-12 13:46:19.653844196 UTC +2018-07-12 14:26:39.421166819 UTC -Total ticks: 44196 +Total ticks: 91304 -6609 UnfoldingDone - 1681 GHC.Float.$fNumDouble_$c* +5077 UnfoldingDone 1681 GHC.Float.timesDouble - 729 GHC.Float.$fNumDouble_$c+ 729 GHC.Float.plusDouble - 415 GHC.Float.$fNumDouble_$c- 415 GHC.Float.minusDouble + 177 $j_s6gs + 177 $j_s6kx 137 Algebra.Geometric.Cl3.$WAPS + 132 $j_s6gn + 132 $j_s6gq + 132 $j_s6ks + 132 $j_s6kv + 121 $j_s6cS + 121 $j_s6gX + 110 $j_s6PQ + 110 $j_s71Q 102 GHC.Base.$ - 102 GHC.Float.$fNumDouble_$cnegate 102 GHC.Float.negateDouble - 62 $j_s5Li - 62 $j_s5LN + 44 $j_s6gm + 44 $j_s6gr + 44 $j_s6kr + 44 $j_s6kw + 25 Algebra.Geometric.Cl3.$WR + 22 $j_s6gi + 22 $j_s6go + 22 $j_s6kn + 22 $j_s6kt 19 Algebra.Geometric.Cl3.$WH 19 Algebra.Geometric.Cl3.$WODD - 17 Algebra.Geometric.Cl3.$WR 17 Algebra.Geometric.Cl3.$WBPV - 15 $c/_a1Af - 14 GHC.Float.$fFloatingDouble_$csqrt + 17 $j_s6cc 14 GHC.Float.sqrtDouble 14 Algebra.Geometric.Cl3.$WC - 12 $j_s5Le - 12 $j_s5Lg - 12 $j_s5LJ - 12 $j_s5LL 11 Algebra.Geometric.Cl3.$WPV 11 Algebra.Geometric.Cl3.$WTPV - 10 $j_s5Lf - 10 $j_s5LK - 9 $cfromInteger_a3eU - 8 $c*_a1He - 7 $c+_a1Az - 6 $clog1p_a1zz - 6 $s$clog_s614 - 5 $cnegate_a36c + 8 $c*_a2h6 + 8 GHC.Float.$fNumDouble_$cfromInteger + 7 $cfromInteger_a3OM + 7 $j_s6gp + 7 $j_s6ku + 6 $c/_a2ad + 6 $c+_a2at 5 Algebra.Geometric.Cl3.$WV3 5 Algebra.Geometric.Cl3.$WBV - 5 lvl_s5VO - 5 lvl_s5VP - 4 $c-_a1H7 - 4 GHC.Float.$fNumDouble_$cabs - 4 $j_s5Lb - 4 $j_s5Lc - 4 $j_s5Ld - 4 $j_s5Lh - 4 $j_s5LG - 4 $j_s5LH - 4 $j_s5LI - 4 $j_s5LM - 3 $c**_a1yF + 4 $clog1p_a29F + 4 $cnegate_a3G4 + 4 GHC.Float.fabsDouble + 4 $j_s6c8 + 4 $j_s6ca + 4 $j_s6gj + 4 $j_s6gk + 4 $j_s6ko + 4 $j_s6kp + 3 Algebra.Geometric.Cl3.projEigs 3 Algebra.Geometric.Cl3.$WI - 3 $j_s5J8 - 3 $j_s5Jo + 2 $c**_a28T + 2 $crecip_a2ak + 2 $c-_a2h1 2 GHC.Base.$! 2 GHC.Float.$dm** 2 GHC.Float.$dmexpm1 @@ -82,318 +86,359 @@ 2 GHC.Real.$dm/ 2 GHC.Real.$dmrecip 2 GHC.Num.$dm- + 2 Algebra.Geometric.Cl3.spectraldcmp 2 Algebra.Geometric.Cl3.reduce - 2 $dNum_s5Id - 2 $dNum_s5It - 2 lvl_s5VK - 1 $cabs_a36g - 1 GHC.Float.$fRealFloatDouble_$catan2 - 1 GHC.Float.$fNumDouble_$cfromInteger - 1 GHC.Float.$fFractionalDouble_$crecip - 1 GHC.Float.$fFloatingDouble_$ccos - 1 GHC.Float.$fFloatingDouble_$csin - 1 GHC.Float.$fFloatingDouble_$clog - 1 GHC.Float.$fFloatingDouble_$cexp - 1 GHC.Float.sinDouble - 1 GHC.Float.logDouble - 1 GHC.Float.expDouble + 2 $j_s6gl + 2 $j_s6kq + 1 $cabs_a3G8 1 GHC.Float.cosDouble - 1 Algebra.Geometric.Cl3.projEigs - 1 $s$dmlog1pexp_s5Ge - 1 lvl_s5I8 - 1 lvl_s5I9 - 1 $dFractional_s5Ib - 1 lvl_s5Ik - 1 lvl_s5Il - 1 lvl_s5Im - 1 lvl_s5In - 1 lvl_s5Io - 1 lvl_s5Ip - 1 $dFractional_s5Ir - 1 lvl_s5Iw - 1 lvl_s5W0 -3337 RuleFired - 1695 Class op * - 737 Class op + - 419 Class op - - 127 *## - 109 Class op negate + 1 GHC.Float.expDouble + 1 GHC.Float.logDouble + 1 GHC.Float.sinDouble + 1 GHC.Float.$fFractionalDouble_$crecip + 1 GHC.Float.$fRealFloatDouble_$catan2 + 1 lvl_s6br + 1 lvl_s6bs + 1 lvl_s6bu + 1 lvl_s6bv + 1 lvl_s6bx + 1 $j_s6c9 + 1 lvl_s7OD + 1 lvl_s7OE +3532 RuleFired + 1691 Class op * + 734 Class op + + 417 Class op - + 372 +## + 106 Class op negate 55 ^2/Integer - 26 +## - 25 Class op $p1Floating - 20 Class op $p1Fractional - 15 Class op / - 14 Class op exp - 14 Class op log + 44 *## + 16 Class op $p1Floating 14 Class op sqrt - 13 Class op fromInteger - 9 doubleFromInteger - 6 Class op log1p - 6 SC:$clog0 + 12 Class op $p1Fractional + 10 Class op exp + 10 Class op log + 8 Class op / + 8 Class op fromInteger + 7 doubleFromInteger 5 Class op abs - 4 Class op cos - 4 Class op fromRational - 4 Class op recip - 4 Class op sin - 3 Class op ** - 3 Class op cosh - 3 Class op sinh + 4 Class op log1p + 3 Class op cos + 3 Class op recip + 3 Class op sin + 2 Class op ** + 2 Class op cosh + 2 Class op fromRational + 2 Class op sinh 1 Class op atan2 1 Class op pi - 1 SC:$w$catan20 -25 LetFloatFromLet 25 -1 EtaReduction 1 x_a5bv -9652 BetaReduction - 1681 ds_a5IW - 1681 ds1_a5IX - 729 ds_a5IM - 729 ds1_a5IN - 415 ds_a5Jb - 415 ds1_a5Jc - 137 dt_a1fe - 137 dt_a1ff - 137 dt_a1fg - 137 dt_a1fh - 137 dt_a1fi - 137 dt_a1fj - 137 dt_a1fk - 137 dt_a1fl - 124 dt_d5iD - 124 dt_d5iE - 124 dt_d5iF - 124 dt_d5iG - 124 dt_d5iH - 124 dt_d5iI - 124 dt_d5iJ - 124 dt_d5iK - 102 a_12 - 102 b_13 - 102 r_1j - 102 tpl_B1 - 102 tpl_B2 - 102 ds_a5JB - 55 a_a5nS - 55 $dNum_a5nT - 55 $dIntegral_a5nU - 55 x_a5nV - 24 dt_d5iP - 24 dt_d5iQ - 24 dt_d5iR - 24 dt_d5iS - 24 dt_d5j1 - 24 dt_d5j2 - 24 dt_d5j3 - 24 dt_d5j4 - 20 dt_d5iT - 20 dt_d5iU - 20 dt_d5iV - 20 dt_d5iW - 20 dt_d5iX - 20 dt_d5iY - 19 dt_a1eq - 19 dt_a1er - 19 dt_a1es - 19 dt_a1et - 19 dt_a1eU - 19 dt_a1eV - 19 dt_a1eW - 19 dt_a1eX - 17 dt_a1dS - 17 dt_a1eG - 17 dt_a1eH - 17 dt_a1eI - 17 dt_a1eJ - 17 dt_a1eK - 17 dt_a1eL - 16 eta_a53E - 16 eta1_a53F - 14 dt_a1eA - 14 dt_a1eB - 14 ds_a5IH - 12 sc_s60u - 12 sc_s60v - 11 dt_a1eg - 11 dt_a1eh - 11 dt_a1ei - 11 dt_a1ej - 11 dt_a1f4 - 11 dt_a1f5 - 11 dt_a1f6 - 11 dt_a1f7 - 9 int_a1bM - 8 ds_d4ON - 8 ds_d4OO - 8 dt_d5iL - 8 dt_d5iM - 8 dt_d5iN - 8 dt_d5iO - 8 dt_d5j5 - 8 dt_d5j6 - 8 dt_d5j7 - 8 dt_d5j8 - 8 dt_d5ja - 8 dt_d5jb - 8 dt_d5jc - 8 dt_d5jd - 8 dt_d5je - 8 dt_d5jf - 7 eta_a53o - 7 ds_d4CK - 7 ds_d4CL - 6 y_X5Nf - 5 x_a1bN - 5 dt_a1dW - 5 dt_a1dX - 5 dt_a1dY - 5 dt_a1e4 - 5 dt_a1e5 - 5 dt_a1e6 - 5 x_a5bv - 5 y_a5bw - 4 eta_a53a - 4 eta1_a53b - 4 x_a5mY - 3 dt_a1ec - 2 cliffor_aIx - 2 r_aIz - 2 a_a533 - 2 $dFloating_a534 - 2 a_a538 - 2 $dFloating_a539 - 2 a_a53c - 2 $dFloating_a53d - 2 a_a53g - 2 $dFloating_a53h - 2 a_a53j - 2 $dFloating_a53k - 2 a_a53m - 2 $dFloating_a53n - 2 a_a53r - 2 $dFloating_a53s - 2 a_a53w - 2 $dFloating_a53x - 2 a_a53z - 2 $dFloating_a53A - 2 a_a53C - 2 $dFractional_a53D - 2 a_a53G - 2 $dFractional_a53H - 2 a_a5bt - 2 $dNum_a5bu - 2 a_a5mH - 2 b_a5mI - 2 f_a5mJ - 2 x_a5mK - 2 dt_d5et - 2 dt_d5eu - 1 eta_a535 - 1 eta_a53e - 1 eta1_a53f - 1 eta_a53i - 1 eta_a53l - 1 eta_a53t - 1 x_a53y - 1 eta_a53B - 1 eta_a53I - 1 i_a5mT - 1 x_a5oJ - 1 w_a5p8 - 1 w1_a5p9 - 1 ds_a5K6 - 1 ds_a5Kc - 1 ds_a5Kh - 1 ds_a5Kp - 1 sc_a5PU - 1 sc1_a5PV - 1 ds_d4AC - 1 ds_d4BO - 1 ds_d4CI - 1 ds_d50R - 1 ds_d52M - 1 w_s5RT -9 CaseOfCase - 2 wild_X9 - 2 wild_XV - 2 dt_X1dU - 2 wild1_a5J2 - 1 ww_s5RV -7664 KnownBranch - 1685 wild1_a5J2 - 1681 wild_a5IY - 729 wild_a5IO - 729 wild1_a5IS - 415 wild_a5Jd - 415 wild1_a5Jh - 248 wild_X9 - 137 dt_X1fn - 137 dt_X1fq - 137 dt_X1ft - 137 dt_X1fw - 137 dt_X1fz - 137 dt_X1fC - 137 dt_X1fF - 137 dt_X1fI - 102 wild_a5JC - 36 dt_X1eZ - 36 dt_X1f2 - 25 wild_XV - 21 dt_X1dU - 19 dt_X1ev - 19 dt_X1ey - 19 dt_X1eB - 19 dt_X1eE - 19 dt_X1f5 - 19 dt_X1f8 - 19 ww_s5RV - 17 dt_X1eN - 17 dt_X1eQ - 17 dt_X1eT - 17 dt_X1eW - 14 dt_X1eD - 14 dt_X1eG - 14 wild_a5II - 12 wild_Xf - 11 dt_X1el - 11 dt_X1eo - 11 dt_X1er - 11 dt_X1eu - 11 dt_X1f9 - 11 dt_X1fc - 11 dt_X1ff - 11 dt_X1fi - 9 wild_a5mU - 8 wild_Xg - 8 dt_X1ee - 6 wild_Xd - 5 wild_Xb - 5 wild_XW - 5 dt_X1e0 - 5 dt_X1e3 - 5 dt_X1e6 - 5 dt_X1e8 - 5 dt_X1eb - 4 wild_Xa +687 LetFloatFromLet 687 +2 EtaReduction + 1 eta_B2 + 1 x_a5TK +14750 BetaReduction + 1681 ds_a65p + 1681 ds1_a65q + 729 ds_a64o + 729 ds1_a64p + 415 ds_a65z + 415 ds1_a65A + 354 dt_d5SW + 354 dt_d5SX + 354 dt_d5SY + 354 dt_d5SZ + 354 dt_d5T0 + 354 dt_d5T1 + 354 dt_d5T2 + 354 dt_d5T3 + 264 dt_d5Po + 264 dt_d5Pp + 264 dt_d5Pq + 264 dt_d5Pr + 264 dt_d5Rw + 264 dt_d5Rx + 264 dt_d5Ry + 264 dt_d5Rz + 242 vx_a63F + 226 ds_d5kP + 137 dt_a1Gh + 137 dt_a1Gi + 137 dt_a1Gj + 137 dt_a1Gk + 137 dt_a1Gl + 137 dt_a1Gm + 137 dt_a1Gn + 137 dt_a1Go + 102 a_11 + 102 b_12 + 102 r_1i + 102 v_B1 + 102 v_B2 + 102 ds_a65W + 88 dt_d5OG + 88 dt_d5OH + 88 dt_d5OI + 88 dt_d5OJ + 88 dt_d5Se + 88 dt_d5Sf + 88 dt_d5Sg + 88 dt_d5Sh + 55 a_a64W + 55 $dNum_a64X + 55 $dIntegral_a64Y + 55 x_a64Z + 44 dt_d5LY + 44 dt_d5Q6 + 44 dt_d5Q7 + 25 dt_a1EV + 19 dt_a1Ft + 19 dt_a1Fu + 19 dt_a1Fv + 19 dt_a1Fw + 19 dt_a1FX + 19 dt_a1FY + 19 dt_a1FZ + 19 dt_a1G0 + 17 dt_a1FJ + 17 dt_a1FK + 17 dt_a1FL + 17 dt_a1FM + 17 dt_a1FN + 17 dt_a1FO + 17 dt_d5Uj + 17 dt_d5Uk + 17 dt_d5Ul + 17 dt_d5Um + 17 dt_d5Un + 17 dt_d5Uo + 17 dt_d5Up + 17 dt_d5Uq + 14 dt_a1FD + 14 dt_a1FE + 14 ds_a64j + 14 dt_d5QM + 14 dt_d5QN + 14 dt_d5QO + 14 dt_d5QP + 14 dt_d5QQ + 14 dt_d5QR + 11 dt_a1Fj + 11 dt_a1Fk + 11 dt_a1Fl + 11 dt_a1Fm + 11 dt_a1G7 + 11 dt_a1G8 + 11 dt_a1G9 + 11 dt_a1Ga + 8 i_a63N + 8 ds_d5wR + 8 ds_d5wS + 8 dt_d5MD + 8 dt_d5ME + 8 dt_d5MF + 8 dt_d5Nk + 8 dt_d5Nl + 8 dt_d5Nm + 7 int_a1BT + 6 ds_d5kO + 6 w_s6Mj + 6 w_s6Mk + 5 dt_a1EZ + 5 dt_a1F0 + 5 dt_a1F1 + 5 dt_a1F7 + 5 dt_a1F8 + 5 dt_a1F9 + 5 x_a5LB + 4 x_a1BU + 4 ds_a63S + 4 dt_d5O1 + 4 dt_d5TZ + 4 dt_d5U0 + 4 dt_d5U1 + 4 dt_d5U2 + 4 dt_d5Ub + 4 dt_d5Uc + 4 dt_d5Ud + 4 dt_d5Ue + 3 dt_a1Ff + 3 x_a5Li + 3 y_a5Lj + 3 x_a5LX + 3 w_s6Mz + 2 function_a1BV + 2 cliffor_a1BW + 2 r_a1C1 + 2 a_a5L7 + 2 $dFloating_a5L8 + 2 a_a5Le + 2 $dFloating_a5Lf + 2 a_a5Lk + 2 $dFloating_a5Ll + 2 a_a5Lp + 2 $dFloating_a5Lq + 2 a_a5Lt + 2 $dFloating_a5Lu + 2 a_a5Lx + 2 $dFloating_a5Ly + 2 a_a5LC + 2 $dFloating_a5LD + 2 a_a5LH + 2 $dFloating_a5LI + 2 a_a5LK + 2 $dFloating_a5LL + 2 a_a5LP + 2 $dFractional_a5LQ + 2 a_a5LU + 2 $dFractional_a5LV + 2 a_a5TI + 2 $dNum_a5TJ + 2 a_a63B + 2 b_a63C + 2 f_a63D + 2 x_a63E + 1 x_a5La + 1 x_a5Ln + 1 y_a5Lo + 1 x_a5Ls + 1 x_a5Lw + 1 x_a5LG + 1 x_a5LJ + 1 x_a5LO + 1 x_a5LS + 1 y_a5LT + 1 x_a5TK + 1 y_a5TL + 1 x_a66T + 1 ds_a67a + 1 ds_a67g + 1 ds_a67l + 1 ds_a67s + 1 w_a67O + 1 w1_a67P + 1 dt_d5TO + 1 dt_d5TP + 1 dt_d5TQ + 1 dt_d5TR + 1 dt_d5TS + 1 dt_d5TT + 1 dt_d5TV + 1 dt_d5TW + 1 dt_d5TX + 1 dt_d5TY + 1 dt_d5U5 + 1 dt_d5U6 + 1 dt_d5U7 + 1 dt_d5U8 + 1 dt_d5U9 + 1 dt_d5Ua + 1 dt_d5Uf + 1 dt_d5Ug + 1 dt_d5Uh + 1 dt_d5Ui + 1 dt_d5XU + 1 dt_d5XV + 1 w_s6M9 +7 CaseOfCase + 2 wild_X16 + 2 vx_a63F + 1 wild_X9 + 1 wild_X15 + 1 ww_s6Mb +13525 KnownBranch + 1681 wild_a65r + 1681 wild1_a65v + 1211 wild_Xo + 888 wild_Xf + 884 wild_Xg + 729 wild_a64q + 729 wild1_a64u + 565 wild_X9 + 444 wild_Xd + 415 wild_a65B + 415 wild1_a65F + 266 wild_Xa + 242 wild_X1i + 242 vx_a63F + 223 wild_Xb + 223 wild_X16 + 222 wild_Xj + 222 wild_Xn + 221 wild_Xc + 178 wild_Xe + 155 wild_Xk + 137 dt_X1Gq + 137 dt_X1Gt + 137 dt_X1Gw + 137 dt_X1Gz + 137 dt_X1GC + 137 dt_X1GF + 137 dt_X1GI + 137 dt_X1GL + 102 wild_a65X + 36 dt_X1G2 + 36 dt_X1G5 + 25 dt_X1EX + 19 dt_X1Fy + 19 dt_X1FB + 19 dt_X1FE + 19 dt_X1FH + 19 dt_X1G8 + 19 dt_X1Gb + 17 dt_X1FQ + 17 dt_X1FT + 17 dt_X1FW + 17 dt_X1FZ + 14 dt_X1FG + 14 dt_X1FJ + 14 wild_a64k + 12 wild_X15 + 11 dt_X1Fo + 11 dt_X1Fr + 11 dt_X1Fu + 11 dt_X1Fx + 11 dt_X1Gc + 11 dt_X1Gf + 11 dt_X1Gi + 11 dt_X1Gl + 11 ww_s6Mb + 8 dt_X1Fh + 7 wild_a63O + 5 dt_X1F3 + 5 dt_X1F6 + 5 dt_X1F9 + 5 dt_X1Fb + 5 dt_X1Fe + 4 wild_X2i + 4 wild_a63T + 1 wild_X2a + 1 wild_a66U + 1 wild_a67b + 1 wild_a67h + 1 wild_a67m + 1 wild_a67t + 1 ww_a67Q + 1 ds_d5JX + 1 ww_s6MB + 1 ww_s6MH + 1 ww_s6Ne +18 SimplifierDone 18 +76 AltMerge + 8 wild_X4B + 8 wild_X4C + 8 wild_X4E + 8 wild_X4F + 8 wild_X4G + 6 wild_X4D 4 wild_Xe - 4 wild_a5mZ - 3 wild_Xj - 3 wild_Xn + 4 wild_Xg + 4 wild_X4H + 3 wild_X4x + 3 wild_X4y + 3 wild_X4I + 2 wild_Xa 2 wild_Xc - 2 wild_Xk - 2 wild_Xo - 1 wild_X1C - 1 wild_X1M - 1 wild_X1O - 1 wild_a5oK - 1 ww_a5pa - 1 wild_a5K7 - 1 wild_a5Kd - 1 wild_a5Ki - 1 wild_a5Kq - 1 ds_d4AR - 1 ds_d4AS - 1 ds_d51T - 1 ww_s5Sj -2 CaseMerge 2 vx_a5mL -1 CaseIdentity 1 wild_X9 -21 SimplifierDone 21 + 2 wild_X4z + 2 wild_X4A + 1 wild_X4J }}} (Left / before / red: GHC 8.0.2; right / after / green: GHC 8.4.3). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 15:05:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 15:05:10 -0000 Subject: [GHC] #15138: Unable to instantiate data members of kind Nat in backpack signatures. In-Reply-To: <042.e290873b59fcee0c98fbf371f48d1238@haskell.org> References: <042.e290873b59fcee0c98fbf371f48d1238@haskell.org> Message-ID: <057.82655b70aed91ff9b7ec87220e6804ac@haskell.org> #15138: Unable to instantiate data members of kind Nat in backpack signatures. -------------------------------------+------------------------------------- Reporter: ppk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4951 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4951 * milestone: 8.8.1 => 8.6.1 Comment: This looks simple enough that I think we can sneak it in to 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 15:07:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 15:07:40 -0000 Subject: [GHC] #314: #line pragmas not respected inside nested comments In-Reply-To: <045.e2d94babc1a72770327e5dfb6388ae06@haskell.org> References: <045.e2d94babc1a72770327e5dfb6388ae06@haskell.org> Message-ID: <060.dda174ad12dea711ea713316a7eb3479@haskell.org> #314: #line pragmas not respected inside nested comments -------------------------------------+------------------------------------- Reporter: nobody | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 6.4 (Parser) | Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: read032 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4934 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4934 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 15:27:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 15:27:47 -0000 Subject: [GHC] #15369: GHCi doesn't honor ':set +c' when loading, for a second time, a file that has .hi/.o Message-ID: <050.a3b7fabd1dfe8f036f7828f2ade0cf8e@haskell.org> #15369: GHCi doesn't honor ':set +c' when loading, for a second time, a file that has .hi/.o -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If a file `foo.hs` is compiled and has `foo.hi` and `foo.o` lying around, then the ''second time'' `foo.hs` is loaded in GHCi (with `set +c` set), even with `:load *foo.hs` to force interpretation, the file loads fine but the type information is not collected, as if `:set +c` wasn't in effect. This means that commands like `:type-at` and `:all-types` work as if they had the old file. I expect that given `:set +c`, a successful `:load *foo.hs` would always collect the new type information for `foo.hs`. == Steps to reproduce The contents of `setc.hs` is the following, although it's pretty surely irrelevant. {{{#!hs module SetC where }}} The following is a GHCi session showing the problem (my comments are marked with `--`). {{{ GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> :set +c -- dir /b is basically ls on Windows Prelude> :! dir /b setc* setc.hs -- When I load a file multiple times it works fine Prelude> :load *setc.hs [1 of 1] Compiling SetC ( setc.hs, interpreted ) Ok, one module loaded. Collecting type info for 1 module(s) ... -- Collected *SetC> :load *setc.hs [1 of 1] Compiling SetC ( setc.hs, interpreted ) Ok, one module loaded. Collecting type info for 1 module(s) ... -- Collected -- But if I compile it *SetC> :! ghc -c setc.hs *SetC> :! dir /b setc* setc.hi setc.hs setc.o -- The first time the type info is collected *SetC> :load *setc.hs [1 of 1] Compiling SetC ( setc.hs, interpreted ) Ok, one module loaded. Collecting type info for 1 module(s) ... -- Collected -- But then it is no longer collected *SetC> :load *setc.hs [1 of 1] Compiling SetC ( setc.hs, interpreted ) Ok, one module loaded. -- NOT collected! *SetC> }}} Then if I change `setc.hs` to add some expressions: {{{#!hs module SetC where x :: Int x = 1 }}} {{{ *SetC> :load *setc.hs [1 of 1] Compiling SetC ( setc.hs, interpreted ) Ok, one module loaded. -- NOT collected! -- The new definition is loaded fine *SetC> x 1 -- But the type information is not there (no output!) *SetC> :all-types *SetC> -- Then if I delete the compiled .hi and .o files *SetC> :! del setc.hi setc.o -- ... and load again, :all-types suddenly works *SetC> :load *setc.hs [1 of 1] Compiling SetC ( setc.hs, interpreted ) Ok, one module loaded. Collecting type info for 1 module(s) ... -- Collected *SetC> :all-types setc.hs:(4,1)-(4,2): GHC.Types.Int setc.hs:(4,5)-(4,6): GHC.Types.Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 15:37:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 15:37:22 -0000 Subject: [GHC] #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.457d64a4e17c588b1564d832bef27538@haskell.org> #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context -------------------------------------+------------------------------------- Reporter: cactus | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"471a992ab956fe90d51b875a81d6963592db5553/ghc" 471a992/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="471a992ab956fe90d51b875a81d6963592db5553" Trac #8581 users_guide/glasgow_exts section 10.7 as per comments on the ticket; also linked to Haskell folk art of 'Smart constructors'. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 15:37:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 15:37:52 -0000 Subject: [GHC] #15350: gcdExtInteger violates assertion In-Reply-To: <047.463f72a51535cf21b879b51cdb0841bf@haskell.org> References: <047.463f72a51535cf21b879b51cdb0841bf@haskell.org> Message-ID: <062.fcdddccd4b24d261fcc49d482f31207d@haskell.org> #15350: gcdExtInteger violates assertion -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7c207c86ab0de955ebec70eeeb366ba0d94acc4a/ghc" 7c207c86/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7c207c86ab0de955ebec70eeeb366ba0d94acc4a" Fix gcdExtInteger (trac#15350) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 15:40:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 15:40:42 -0000 Subject: [GHC] #14471: Certain do blocks cause TH to barf when ApplicativeDo is enabled In-Reply-To: <050.4f7b341f8e72d76f8691291adb62b498@haskell.org> References: <050.4f7b341f8e72d76f8691291adb62b498@haskell.org> Message-ID: <065.620341ce3deb042c9c1bbc86a744d73a@haskell.org> #14471: Certain do blocks cause TH to barf when ApplicativeDo is enabled -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: mgsloan Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: th/T14471 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4912 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"234093cf1562d032b38382a5cc08be8dd71c4fe3/ghc" 234093cf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="234093cf1562d032b38382a5cc08be8dd71c4fe3" Fix handling of ApplicativeDo in TH AST quotes See https://ghc.haskell.org/trac/ghc/ticket/14471 Also fixes a parenthesization bug in pprStmt when ret_stripped is True Test Plan: tests added to testsuite Trac issues: #14471 Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4912 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 16:02:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 16:02:41 -0000 Subject: [GHC] #15369: GHCi doesn't honor ':set +c' when loading, for a second time, a file that has .hi/.o In-Reply-To: <050.a3b7fabd1dfe8f036f7828f2ade0cf8e@haskell.org> References: <050.a3b7fabd1dfe8f036f7828f2ade0cf8e@haskell.org> Message-ID: <065.01c31abd405dbe8637dc0cd767cea0b6@haskell.org> #15369: GHCi doesn't honor ':set +c' when loading, for a second time, a file that has .hi/.o -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dramforever): This seems similar to #15085. However, as far as I tried, I wasn't able to reproduce that bug, while I'm still having this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 16:08:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 16:08:03 -0000 Subject: [GHC] #15350: gcdExtInteger violates assertion In-Reply-To: <047.463f72a51535cf21b879b51cdb0841bf@haskell.org> References: <047.463f72a51535cf21b879b51cdb0841bf@haskell.org> Message-ID: <062.4382b8e36fcfa6653c4b66daafaea20b@haskell.org> #15350: gcdExtInteger violates assertion -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: Bodigrim Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Bodigrim): * owner: (none) => Bodigrim -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 16:14:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 16:14:17 -0000 Subject: [GHC] #15085: :type-at/:all-types and :r don't mix In-Reply-To: <044.f4e4f79c3e387be82389134e302aff88@haskell.org> References: <044.f4e4f79c3e387be82389134e302aff88@haskell.org> Message-ID: <059.658ed14153396885ed4db2df71f81d1a@haskell.org> #15085: :type-at/:all-types and :r don't mix -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.4.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 dramforever): Could you please show the exact command line used and a log of your interaction session? I suspect that this may be related to #15369 but I'm not sure, and I wasn't able to reproduce your issue (on 8.4.3). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 17:24:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 17:24:37 -0000 Subject: [GHC] #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) Message-ID: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypedHoles | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program panics on GHC 8.6 and HEAD: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind import Data.Type.Equality import Data.Void data family Sing :: forall k. k -> Type data (~>) :: Type -> Type -> Type infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 newtype instance Sing (f :: k1 ~> k2) = SLambda { applySing :: forall t. Sing t -> Sing (Apply f t) } mkRefl :: n :~: j mkRefl = Refl right :: forall (r :: (x :~: y) ~> z). Sing r -> () right no = case mkRefl @x @y of Refl -> applySing no _ }}} {{{ $ /opt/ghc/8.6.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.6.0.20180627 for x86_64-unknown-linux): tcTyVarDetails co_a1BG :: y_a1Bz[sk:1] ~# x_a1By[sk:1] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Var.hs:497:22 in ghc:Var }}} On GHC 8.4, this simply errors: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:23:10: error: • Couldn't match type ‘n’ with ‘j’ ‘n’ is a rigid type variable bound by the type signature for: mkRefl :: forall k1 (n :: k1) (j :: k1). n :~: j at Bug.hs:22:1-17 ‘j’ is a rigid type variable bound by the type signature for: mkRefl :: forall k1 (n :: k1) (j :: k1). n :~: j at Bug.hs:22:1-17 Expected type: n :~: j Actual type: n :~: n • In the expression: Refl In an equation for ‘mkRefl’: mkRefl = Refl • Relevant bindings include mkRefl :: n :~: j (bound at Bug.hs:23:1) | 23 | mkRefl = Refl | ^^^^ Bug.hs:29:13: error: • Couldn't match type ‘Sing (Apply r t0)’ with ‘()’ Expected type: () Actual type: Sing (Apply r t0) • In the expression: applySing no _ In a case alternative: Refl -> applySing no _ In the expression: case mkRefl @x @y of { Refl -> applySing no _ } • Relevant bindings include no :: Sing r (bound at Bug.hs:27:7) right :: Sing r -> () (bound at Bug.hs:27:1) | 29 | Refl -> applySing no _ | ^^^^^^^^^^^^^^ Bug.hs:29:26: error: • Found hole: _ :: Sing t0 Where: ‘t0’ is an ambiguous type variable ‘y’, ‘x’, ‘k’ are rigid type variables bound by the type signature for: right :: forall k1 (x1 :: k1) (y1 :: k1) z (r :: (x1 :~: y1) ~> z). Sing r -> () at Bug.hs:(25,1)-(26,21) • In the second argument of ‘applySing’, namely ‘_’ In the expression: applySing no _ In a case alternative: Refl -> applySing no _ • Relevant bindings include no :: Sing r (bound at Bug.hs:27:7) right :: Sing r -> () (bound at Bug.hs:27:1) Valid substitutions include undefined :: forall (a :: TYPE r). GHC.Stack.Types.HasCallStack => a (imported from ‘Prelude’ at Bug.hs:7:8-10 (and originally defined in ‘GHC.Err’)) | 29 | Refl -> applySing no _ | ^ }}} Note that this is distinct from #15142, as this is still reproducible on HEAD, even after commit 030211d21207dabb7a4bf21cc9af6fa5eb066db1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 17:26:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 17:26:46 -0000 Subject: [GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin In-Reply-To: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> References: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> Message-ID: <062.e2970bbfa4dc7511d5c193c0e2e9f918@haskell.org> #15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | typeable,knownnat Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10348 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by diatchki): I don't think the apartness issue is specific to `KnownNat` or nats for that matter, it really is more about type functions. From what I've seen, people tend to notice the issue more when working with nats for two reasons (1) they are used to `0` and `succ` being constructors, and so one can define things inductively using them; (2) when using type nats, one simply uses type functions a lot more than in ordinary code. I also think that it would be quite cool to work out a system for matching on type functions (at least in some special cases), but I'd rather not do it through plugins. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 17:31:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 17:31:43 -0000 Subject: [GHC] #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) In-Reply-To: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> References: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> Message-ID: <065.915679bbd5e91f05ba21f4ee2e3a6776@haskell.org> #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Simpler example: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Type.Equality data S (a :: Either x y) mkRefl :: n :~: j mkRefl = Refl right :: forall (r :: Either x y). S r -> () right no = case mkRefl @x @y of Refl -> no + _ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 18:57:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 18:57:15 -0000 Subject: [GHC] #15359: Quantified constraints do not work with equality constraints In-Reply-To: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> References: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> Message-ID: <062.f505735306b56c56dafab4093fd1724b@haskell.org> #15359: Quantified constraints do not work with equality constraints -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): All the examples in comment:7 involve superclass constraints, mostly on classes without any methods. This is interesting for type-level programming, but it's not clear where (even in type-level programming) the rubber is hitting the road here. Can you give a concrete example of a function that usefully uses an equality constraint in the head of an implication? This should be a function that I can call (that is, the constraints are satisfiable). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 19:05:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 19:05:23 -0000 Subject: [GHC] #14627: qAddTopDecls: can't convert top-level declarations In-Reply-To: <049.485d47f57c339e482133548d02dc333a@haskell.org> References: <049.485d47f57c339e482133548d02dc333a@haskell.org> Message-ID: <064.87d391253ca99eac40e1ef7c05893220@haskell.org> #14627: qAddTopDecls: can't convert top-level declarations -------------------------------------+------------------------------------- Reporter: tianxiaogu | Owner: mgsloan Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: th/T14627 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4914 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0f79b0ef140e086a48d1aa5b945ad5a3754ccdd1/ghc" 0f79b0e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0f79b0ef140e086a48d1aa5b945ad5a3754ccdd1" Fix handling of unbound constructor names in TH #14627 Also adds a comment to UnboundVarE clarifying that it also is used for unbound constructor identifiers, since that isn't very clear from the name. Test Plan: testsuite/tests/th/T14627.hs Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4923 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 19:05:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 19:05:39 -0000 Subject: [GHC] #15335: Export `findImportUsage` from `rename/RnNames.hs` module In-Reply-To: <047.137c5faaec024c503e5607145a3daa2f@haskell.org> References: <047.137c5faaec024c503e5607145a3daa2f@haskell.org> Message-ID: <062.0d71c67e20954a49fa20246279c75b72@haskell.org> #15335: Export `findImportUsage` from `rename/RnNames.hs` module -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | imports,refactoring,export Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4927 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2b1adaa7817c453df868d928312a9a99a0481eb1/ghc" 2b1adaa/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2b1adaa7817c453df868d928312a9a99a0481eb1" Export findImportUsage and ImportDeclUsage Reviewers: bgamari, alpmestan Reviewed By: alpmestan Subscribers: alpmestan, rwbarton, thomie, carter GHC Trac Issues: #15335 Differential Revision: https://phabricator.haskell.org/D4927 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 19:06:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 19:06:23 -0000 Subject: [GHC] #15315: Renamer plugins could run after each group has been renamed In-Reply-To: <049.364dc4b31c5f3adc156474aa350df00b@haskell.org> References: <049.364dc4b31c5f3adc156474aa350df00b@haskell.org> Message-ID: <064.88c2fb3a2903d8b081666e809bef1169@haskell.org> #15315: Renamer plugins could run after each group has been renamed -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4947 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1a79270c72cfcd98d683cfe7b2c777d8dd353b78/ghc" 1a79270/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1a79270c72cfcd98d683cfe7b2c777d8dd353b78" Run the renamed source plugin after each HsGroup This allows modification of each `HsGroup` after it has been renamed. The old behaviour of keeping the renamed source until later can be recovered if desired by using the `keepRenamedSource` plugin but it shouldn't really be necessary as it can be inspected in the `TcGblEnv`. Reviewers: nboldi, bgamari, alpmestan Reviewed By: nboldi, alpmestan Subscribers: alpmestan, rwbarton, thomie, carter GHC Trac Issues: #15315 Differential Revision: https://phabricator.haskell.org/D4947 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 19:06:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 19:06:38 -0000 Subject: [GHC] #15136: High CPU when asynchronous exception and unblocking retry on TVar raced In-Reply-To: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> References: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> Message-ID: <062.501259843c6e5af11cc715e5c00df80e@haskell.org> #15136: High CPU when asynchronous exception and unblocking retry on TVar raced -------------------------------------+------------------------------------- Reporter: nshimaza | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4956 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7fc418df856d9b58034eeec48915646e67a7a562/ghc" 7fc418df/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7fc418df856d9b58034eeec48915646e67a7a562" Fix deadlock between STM and throwTo There was a lock-order reversal between lockTSO() and the TVar lock, see #15136 for the details. It turns out we can fix this pretty easily by just deleting all the locking code(!). The principle for unblocking a `BlockedOnSTM` thread then becomes the same as for other kinds of blocking: if the TSO belongs to this capability then we do it directly, otherwise we send a message to the capability that owns the TSO. That is, a thread blocked on STM is owned by its capability, as it should be. The possible downside of this is that we might send multiple messages to wake up a thread when the thread is on another capability. This is safe, it's just not very efficient. I'll try to do some experiments to see if this is a problem. Test Plan: Test case from #15136 doesn't deadlock any more. Reviewers: bgamari, osa1, erikd Reviewed By: osa1 Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15136 Differential Revision: https://phabricator.haskell.org/D4956 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 19:09:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 19:09:01 -0000 Subject: [GHC] #15315: Renamer plugins could run after each group has been renamed In-Reply-To: <049.364dc4b31c5f3adc156474aa350df00b@haskell.org> References: <049.364dc4b31c5f3adc156474aa350df00b@haskell.org> Message-ID: <064.3150548ff80629e1c6d3f58286868f5d@haskell.org> #15315: Renamer plugins could run after each group has been renamed -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4947 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 19:26:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 19:26:51 -0000 Subject: [GHC] #14808: GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order In-Reply-To: <050.90702c1fad16a72a2e55cb4eeb0cc78a@haskell.org> References: <050.90702c1fad16a72a2e55cb4eeb0cc78a@haskell.org> Message-ID: <065.8dc273a13783659c719e3358ea72f24d@haskell.org> #14808: GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: fixed | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14529, #14796 | Differential Rev(s): Phab:D4413 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:2 merged in 043466b9aac403553e2aaf8054c064016f963f80. comment:6 merged in e7653bc3c4f57d2282e982b9eb83bd1fcbae6e30. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 19:28:12 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 19:28:12 -0000 Subject: [GHC] #15342: Mark -XAutoDeriveTypeable as deprecated In-Reply-To: <047.58435d34138b96a2bf714e154c899347@haskell.org> References: <047.58435d34138b96a2bf714e154c899347@haskell.org> Message-ID: <062.04f9c4390ec45ee7c5f06458c0a39f07@haskell.org> #15342: Mark -XAutoDeriveTypeable as deprecated -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4933 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: 8.6.1 => 8.8.1 Comment: Perhaps let's just bump this to 8.8 actually. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 19:28:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 19:28:49 -0000 Subject: [GHC] #15341: :info prints kinds in closed type family equations without enabling -fprint-explicit-kinds In-Reply-To: <050.0a6e915f611ee596161321a86f26e2cc@haskell.org> References: <050.0a6e915f611ee596161321a86f26e2cc@haskell.org> Message-ID: <065.98c33c04eee65c92f1f98da167f9b2be@haskell.org> #15341: :info prints kinds in closed type family equations without enabling -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T15341 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4932 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:2 merged in 7b8dcd90c5a622146dfdd3b162a1f1b1d262d5cf. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 19:44:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 19:44:11 -0000 Subject: [GHC] #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) In-Reply-To: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> References: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> Message-ID: <065.db65182a347fe5dc9ff25df5c1ab1d68@haskell.org> #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: quantified- valid program | constraints/T15334 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ryan, how important is this to you? While it is possible to backport this to 8.6, I suspect it will be quite a bit of work. The commit in comment:10 appears to depend quite heavily on 45f44e2c9d5db2f25c52abb402f197c20579400f which is a 1 kLoC refactoring which seems to have a slew of dependencies of its own. Unless this is breaking code in the wild I think it would be best to punt this to 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 19:47:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 19:47:22 -0000 Subject: [GHC] #15335: Export `findImportUsage` from `rename/RnNames.hs` module In-Reply-To: <047.137c5faaec024c503e5607145a3daa2f@haskell.org> References: <047.137c5faaec024c503e5607145a3daa2f@haskell.org> Message-ID: <062.2a12f5cfe4f402638935e9d49cfbeef0@haskell.org> #15335: Export `findImportUsage` from `rename/RnNames.hs` module -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: feature request | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | imports,refactoring,export Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4927 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 19:48:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 19:48:21 -0000 Subject: [GHC] #15136: High CPU when asynchronous exception and unblocking retry on TVar raced In-Reply-To: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> References: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> Message-ID: <062.10d8505de57283d80e4a3227476f5616@haskell.org> #15136: High CPU when asynchronous exception and unblocking retry on TVar raced -------------------------------------+------------------------------------- Reporter: nshimaza | Owner: osa1 Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4956 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 19:49:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 19:49:14 -0000 Subject: [GHC] #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) In-Reply-To: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> References: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> Message-ID: <065.f68a8befe1633ece5796e33fdaa10773@haskell.org> #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: quantified- valid program | constraints/T15334 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): As far as I can tell, the commit in comment:10 only improves error messages, so I don't think it's critical for 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 19:53:50 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 19:53:50 -0000 Subject: [GHC] #15303: API Annotations lost when parsing tyapp In-Reply-To: <044.1aa714aa9f40d3b728af19a48aa49408@haskell.org> References: <044.1aa714aa9f40d3b728af19a48aa49408@haskell.org> Message-ID: <059.18edbc74b17e6039291a1cf518729c64@haskell.org> #15303: API Annotations lost when parsing tyapp -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in 4cfeca02a0a9283e8c9f9ccd9373bc1f2fd8db0a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 20:06:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 20:06:23 -0000 Subject: [GHC] #15289: isUnliftedType GHC panic on pattern with True :: Maybe In-Reply-To: <043.406dc7510cae6790ee47421c68dfc69f@haskell.org> References: <043.406dc7510cae6790ee47421c68dfc69f@haskell.org> Message-ID: <058.54b01fd0846396d0504e11936f64cd36@haskell.org> #15289: isUnliftedType GHC panic on pattern with True :: Maybe -------------------------------------+------------------------------------- Reporter: Remi | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: Resolution: fixed | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in 149d7912eb84a24861b021c13d2ee61b44de5856. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 20:06:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 20:06:55 -0000 Subject: [GHC] #15301: Regression in Natural desugaring In-Reply-To: <045.90c91b42b96252b83bfe60ec247894bd@haskell.org> References: <045.90c91b42b96252b83bfe60ec247894bd@haskell.org> Message-ID: <060.d18a33a0242043ddeda3e10305c27200@haskell.org> #15301: Regression in Natural desugaring -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4885 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in 31f7d21bae5d75621a4077e2966a80ce30c55d46. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 20:11:30 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 20:11:30 -0000 Subject: [GHC] #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) In-Reply-To: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> References: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> Message-ID: <065.51a0ec462090364d60b5cfd723a129fe@haskell.org> #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: Tritlo (added) Comment: This regression was introduced in commit e0b44e2eccd4053852b6c4c3de75a714301ec080 (`Improved Valid Hole Fits`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 21:08:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 21:08:39 -0000 Subject: [GHC] #14873: The well-kinded type invariant (in TcType) In-Reply-To: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> References: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> Message-ID: <065.8328da48aa4fe6b44d03b4670d4dd89f@haskell.org> #14873: The well-kinded type invariant (in TcType) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: goldfire => (none) * status: merge => new Comment: comment:8 merged in 634c07dc2bd9b2be53d707d613df9e7100d543aa. Leaving open due to comment:14. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 21:10:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 21:10:11 -0000 Subject: [GHC] #15331: -ddump-splices does not parenthesize visible type applications correctly In-Reply-To: <050.5bac58b457c421337e97e68faa19a271@haskell.org> References: <050.5bac58b457c421337e97e68faa19a271@haskell.org> Message-ID: <065.17426bc1a71912afa1df403c456cc7a1@haskell.org> #15331: -ddump-splices does not parenthesize visible type applications correctly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T15331 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4920 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:2 merged in f663e507eaf49c6a5e05fd6edb78d649a7611af4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 21:10:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 21:10:32 -0000 Subject: [GHC] #15324: -ddump-splices does not parenthesize rank-n contexts correctly In-Reply-To: <050.ee7a8b6246f694a0997d3f3ae67f6212@haskell.org> References: <050.ee7a8b6246f694a0997d3f3ae67f6212@haskell.org> Message-ID: <065.9275bec4c97e3852365fe2716c93c789@haskell.org> #15324: -ddump-splices does not parenthesize rank-n contexts correctly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T15324 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4910 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in a6a83d9a26db2593fa0e09dcad4c1411d6deb4ac. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 21:10:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 21:10:55 -0000 Subject: [GHC] #15335: Export `findImportUsage` from `rename/RnNames.hs` module In-Reply-To: <047.137c5faaec024c503e5607145a3daa2f@haskell.org> References: <047.137c5faaec024c503e5607145a3daa2f@haskell.org> Message-ID: <062.b5a6a523620e4d8a704ddc6bbb49fb5b@haskell.org> #15335: Export `findImportUsage` from `rename/RnNames.hs` module -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: | imports,refactoring,export Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4927 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in 2f3ec4ea3c0556a5280df3512e512f498dc76cae. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 21:11:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 21:11:45 -0000 Subject: [GHC] #15323: mkGadtDecl does not set con_forall correctly In-Reply-To: <044.5f29299703a0239f45578f0ada455c36@haskell.org> References: <044.5f29299703a0239f45578f0ada455c36@haskell.org> Message-ID: <059.df0a69ebdd6541112e54268b60c20f9a@haskell.org> #15323: mkGadtDecl does not set con_forall correctly -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with a39b58d511f177c9c476cc104999caa67a55de2a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 21:12:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 21:12:20 -0000 Subject: [GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker In-Reply-To: <049.2656489ff85910f6a80bbfa971643315@haskell.org> References: <049.2656489ff85910f6a80bbfa971643315@haskell.org> Message-ID: <064.7a4461e100f3549fafb38218e4054240@haskell.org> #15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11547 #14052 | Differential Rev(s): Phab:D4909 #15202 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): comment:12 merged with 22c951e6aab52adf32499a9568be44dc60e72acb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 21:12:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 21:12:49 -0000 Subject: [GHC] #15318: Core Lint error involving newtype family instances with wrappers In-Reply-To: <050.5e4047b16b9f07feb6a762d8a4dad8f6@haskell.org> References: <050.5e4047b16b9f07feb6a762d8a4dad8f6@haskell.org> Message-ID: <065.af01728a8ae29538948f226019efd7c8@haskell.org> #15318: Core Lint error involving newtype family instances with wrappers -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: indexed- crash or panic | types/should_compile/T15318 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4902 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with eb680f2c0a365b12f9b867da6bb10e9ab4b328e0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 21:13:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 21:13:13 -0000 Subject: [GHC] #15315: Renamer plugins could run after each group has been renamed In-Reply-To: <049.364dc4b31c5f3adc156474aa350df00b@haskell.org> References: <049.364dc4b31c5f3adc156474aa350df00b@haskell.org> Message-ID: <064.7ca3e4b3bb4891f4681e287dcae0c4a2@haskell.org> #15315: Renamer plugins could run after each group has been renamed -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4947 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with b52cfe41e8abb2f1dd1e54ed1cf6ff7fcc0de210. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 21:13:58 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 21:13:58 -0000 Subject: [GHC] #15308: Error message prints explicit kinds when it shouldn't In-Reply-To: <050.8a60180d637a0d8f09dfd184e0f165b6@haskell.org> References: <050.8a60180d637a0d8f09dfd184e0f165b6@haskell.org> Message-ID: <065.ae880fad41d7a7367f1ba9fcea958ed9@haskell.org> #15308: Error message prints explicit kinds when it shouldn't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | dependent/should_fail/T15308 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4891 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:2 merged with 423961132e9d19850e290b38df15006c607744d1. comment:3 merged with 9bcbb222e5b701277ef315c5c4aa76b23f578d0c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 21:14:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 21:14:20 -0000 Subject: [GHC] #15307: Incorrect -ddump-deriv parenthesization for GND'd fmap implementation In-Reply-To: <050.5a1160e153a31f1bbdd2d69e21505079@haskell.org> References: <050.5a1160e153a31f1bbdd2d69e21505079@haskell.org> Message-ID: <065.f9cc702e04eebaf33362fe2afdd18b6c@haskell.org> #15307: Incorrect -ddump-deriv parenthesization for GND'd fmap implementation -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T14578 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4890 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 92925b3dce6631a829e7f61c85da47842472f955. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 21:15:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 21:15:43 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails In-Reply-To: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> References: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> Message-ID: <065.60dea2ec25594aebc546946e436a5f29@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: fixed | TypeFamilies, CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: indexed- crash or panic | types/should_compile/T15142 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with d0dfc5cc4859a07778bc674eb865811616d4d6c6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 21:16:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 21:16:53 -0000 Subject: [GHC] #15061: print022 testcase fails on i386 In-Reply-To: <046.070201c29a49dce5435517538bdcfad1@haskell.org> References: <046.070201c29a49dce5435517538bdcfad1@haskell.org> Message-ID: <061.d9cf6ae80b2a2b73a1dd242dda797848@haskell.org> #15061: print022 testcase fails on i386 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: osa1 Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: fixed | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4906 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 23b4d83f8f71f5e8a9373654ea9bc6f2814dc3fe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 21:23:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 21:23:15 -0000 Subject: [GHC] #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" In-Reply-To: <047.0224facf758b89c9000b13f48465854c@haskell.org> References: <047.0224facf758b89c9000b13f48465854c@haskell.org> Message-ID: <062.891835a670b4c12a8a56ba2eb23d0609@haskell.org> #15290: QuantifiedConstraints: panic "addTcEvBind NoEvBindsVar" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15290{,a,b}, | deriving/should_compile/T15290{c,d}, | deriving/should_compile/T14883 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4895 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This actually wasn't as bad as I was fearing: * 32eb41994f7448caf5fb6b06ed0678d79d029deb was merged with 61adfbe6f9926daf06031b7da2522f73addf75dc. * 9fc40c733ba8822a04bd92883801b214dee099ca was merged with 7e19610c925c45ade589b573a7e1c247cd8265ef * 261dd83cacec71edd551e9c581d05285c9ea3226 was merged with 145f7c663e6df4ecfa848c0e2e478454cf9fb1d9. * 132273f34e394bf7e900d0c15e01e91edd711890 was merged with c0323d979d3676f919d6d02aecad7a8bfdcb8b8d -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 21:24:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 21:24:53 -0000 Subject: [GHC] #15321: Typed holes in Template Haskell splices produce bewildering error messages In-Reply-To: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> References: <050.ec399faeb78ab361cdf855bfe455425a@haskell.org> Message-ID: <065.e4100f9d6b08841ab8fff89f1a61c95d@haskell.org> #15321: Typed holes in Template Haskell splices produce bewildering error messages -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: fixed | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4909 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:13 merged with 22c951e6aab52adf32499a9568be44dc60e72acb. comment:16 merged with 132273f34e394bf7e900d0c15e01e91edd711890. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 22:24:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 22:24:28 -0000 Subject: [GHC] #15355: Functional dependencies can get GHC to print "UnkSkol" In-Reply-To: <047.fc55ac981662395b31d65ce17a7f873f@haskell.org> References: <047.fc55ac981662395b31d65ce17a7f873f@haskell.org> Message-ID: <062.379d3db68aac89117a0e093ed8e0b15d@haskell.org> #15355: Functional dependencies can get GHC to print "UnkSkol" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | FunctionalDependencies Operating System: 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): Re (1), see Trac #12466 for a long discussion, and `Note [Given errors]` in `TcErrors`. Bottom line, we suppress some Given errors, which represent unreachable code, as here. Re (2) HEAD seems better {{{ T15355.hs:12:8: error: * Couldn't match type `Double' with `Bool' arising from a functional dependency between constraints: `C Int _a' arising from a use of `foo' at T15355.hs:12:8-10 `C Int Double' arising from the type signature for: blah :: forall _a. C Int Double => Int -> _a at T15355.hs:11:1-33 * In the expression: foo In an equation for `blah': blah = foo | 12 | blah = foo | ^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 22:33:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 22:33:16 -0000 Subject: [GHC] #14471: Certain do blocks cause TH to barf when ApplicativeDo is enabled In-Reply-To: <050.4f7b341f8e72d76f8691291adb62b498@haskell.org> References: <050.4f7b341f8e72d76f8691291adb62b498@haskell.org> Message-ID: <065.ed6896101f1db95ecd8afe6451d0d0db@haskell.org> #14471: Certain do blocks cause TH to barf when ApplicativeDo is enabled -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: mgsloan Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.2.1 Resolution: fixed | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: th/T14471 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4912 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 22:36:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 22:36:43 -0000 Subject: [GHC] #15368: Type families, holes and -fdefer-type-errors may cause 'opt_univ fell into a hole' panic In-Reply-To: <050.73f861b4bff033457b6f954137086e2e@haskell.org> References: <050.73f861b4bff033457b6f954137086e2e@haskell.org> Message-ID: <065.c8f3bc36d0c83ecd7b2d2c297f11aa7d@haskell.org> #15368: Type families, holes and -fdefer-type-errors may cause 'opt_univ fell into a hole' panic -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Added test in Phab:D4958. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 22:36:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 22:36:56 -0000 Subject: [GHC] #15368: Type families, holes and -fdefer-type-errors may cause 'opt_univ fell into a hole' panic In-Reply-To: <050.73f861b4bff033457b6f954137086e2e@haskell.org> References: <050.73f861b4bff033457b6f954137086e2e@haskell.org> Message-ID: <065.c60a9adf5772b2221406b4405d9459ea@haskell.org> #15368: Type families, holes and -fdefer-type-errors may cause 'opt_univ fell into a hole' panic -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_compile/T15368 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => typecheck/should_compile/T15368 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 22:44:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 22:44:49 -0000 Subject: [GHC] #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 In-Reply-To: <047.0e132514379b72c39d1662f2412d5748@haskell.org> References: <047.0e132514379b72c39d1662f2412d5748@haskell.org> Message-ID: <062.58ed7a88d5317f9b41a6c744d2159df4@haskell.org> #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 -------------------------------------+------------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4959 Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * differential: => Phab:D4959 Comment: Sent https://phabricator.haskell.org/D4959 for review (remove -Bsymbolic from UNREG targets first). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 12 23:01:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 12 Jul 2018 23:01:44 -0000 Subject: [GHC] #15355: Functional dependencies can get GHC to print "UnkSkol" In-Reply-To: <047.fc55ac981662395b31d65ce17a7f873f@haskell.org> References: <047.fc55ac981662395b31d65ce17a7f873f@haskell.org> Message-ID: <062.ef84be0e1891f1a48d4b7f8407334d18@haskell.org> #15355: Functional dependencies can get GHC to print "UnkSkol" -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: worksforme | Keywords: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => worksforme Comment: I'm satisfied with that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 00:04:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 00:04:09 -0000 Subject: [GHC] #15371: Eventlog framework outputs environment variables which may cause a security issue Message-ID: <043.e0598f3eff95a3e71b8c6103a2d86a17@haskell.org> #15371: Eventlog framework outputs environment variables which may cause a security issue -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.4.3 System | 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 eventlog framework currently writes all environment variables to the eventlog file. This may cause a security issue as some external tools expect user to set credentials in environment variables. It's possible for the user to publish an eventlog which contains credentials without knowing it. In general it's not a good idea to set credentials in environment variables but I think GHC should stop writing environment variables to the eventlog implicitly and this feature should be opt-in. I'm not sure if this feature is widely used or if we can just drop it. If it's used to some extend maybe we can provide a function that does this job in a library. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 00:45:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 00:45:26 -0000 Subject: [GHC] #14770: Allow static pointer expressions to have static pointer free variables In-Reply-To: <048.bed690b6ed6632ceb9361aef80b57ffb@haskell.org> References: <048.bed690b6ed6632ceb9361aef80b57ffb@haskell.org> Message-ID: <063.4baea46059757c4bf1ba7a7bc77688f2@haskell.org> #14770: Allow static pointer expressions to have static pointer free variables -------------------------------------+------------------------------------- Reporter: TheKing01 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gershomb): * cc: gershomb (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 00:49:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 00:49:09 -0000 Subject: [GHC] #15371: Eventlog framework outputs environment variables which may cause a security issue In-Reply-To: <043.e0598f3eff95a3e71b8c6103a2d86a17@haskell.org> References: <043.e0598f3eff95a3e71b8c6103a2d86a17@haskell.org> Message-ID: <058.984815f050d51cea64487c5629a95e00@haskell.org> #15371: Eventlog framework outputs environment variables which may cause a security issue -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by maoe: Old description: > The eventlog framework currently writes all environment variables to the > eventlog file. This may cause a security issue as some external tools > expect user to set credentials in environment variables. It's possible > for the user to publish an eventlog which contains credentials without > knowing it. > > In general it's not a good idea to set credentials in environment > variables but I think GHC should stop writing environment variables to > the eventlog implicitly and this feature should be opt-in. > > I'm not sure if this feature is widely used or if we can just drop it. If > it's used to some extend maybe we can provide a function that does this > job in a library. New description: The eventlog framework currently writes all environment variables to the eventlog file. This may cause a security issue as some external tools expect user to set credentials in environment variables. It's possible for the user to publish an eventlog which contains credentials without knowing it. In general it's not a good idea to set credentials in environment variables but I think GHC should stop writing environment variables to the eventlog implicitly and this feature should be opt-in. I'm not sure if this feature is widely used or if we can just drop it. If it's used to some extent maybe we can provide a function that does this job in a library. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 02:01:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 02:01:10 -0000 Subject: [GHC] #15359: Quantified constraints do not work with equality constraints In-Reply-To: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> References: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> Message-ID: <062.0d524c2ccee1f1772c4a77f4c87f1479@haskell.org> #15359: Quantified constraints do not work with equality constraints -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:8 goldfire]: [replying in two instalments] > All the examples in comment:7 involve superclass constraints, ... because your ticket:15351#comment:5 tells me I don't even need instances declared. > mostly on classes without any methods. This is interesting for type- level programming, Yes the `And` example is for type-level programming. You haven't said those superclass constraints are redundant. Those implications/equalities can be derived from examining the instances; but a) needs reasoning from `Bool` being a closed type, b) needs reasoning from a closed set of instances. > but it's not clear where (even in type-level programming) the rubber is hitting the road here. > I don't expect GHC to be a general-purpose logic engine, so if we want type improvement per David's ghc-devs message "Reasoning backwards" -- which seem eminently sensible, and improvements not achievable by injective Type Families (yet), why ''can't'' I use `QuantifiedConstraints` superclass? I could use similar for "Reasoning backwards" in type-level arithmetic over `Nat`: if a sum is `Z`, both arguments must be `Z`. As I said in comment:3, if it can't use `~`, there's plenty of ways to user-define an equivalent. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 03:02:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 03:02:53 -0000 Subject: [GHC] #15372: GHCi leaks in DEBUG mode Message-ID: <047.2ac34cbfa4c72468332be193667a285f@haskell.org> #15372: GHCi leaks in DEBUG mode -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The solution to ticket #15111 fixes some space leaks in GHCi. That ticket also installs `-fghci-leak-check` to the testsuite, so that we'll know when these leaks return. This is all good. However, the `DEBUG` compile still leaks in GHCi. This means that many ghci tests fail in the testsuite when using a `DEBUG` compiler. I thus have two requests: 1. (hopefully quick) Teach the testsuite not to use `-fghci-leak-check` on a `DEBUG` compiler. I tried to do this myself but got lost, never having worked on the testsuite harness. 2. Fix the leaks. If someone could post the fix to (1) in the short term (even if you don't commit it), I'd be grateful. This is holding me up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 03:11:29 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 03:11:29 -0000 Subject: [GHC] #15359: Quantified constraints do not work with equality constraints In-Reply-To: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> References: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> Message-ID: <062.eda82e5fcba02d66e85705369d166eae@haskell.org> #15359: Quantified constraints do not work with equality constraints -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:8 goldfire]: [2 of 2] Considering using quantified implications to emulate FunDeps -- because FunDeps are quantified implications. > it's not clear where ... the rubber is hitting the road here. > Seeing the analogy between type improvement/multi-param type classes and relational theory was a great insight. But FunDeps is a clumsy mechanism. FunDeps and `OverlappingInstances` do not live happily together -- as all the theory says (and often need `UndecidableInstances`). FunDeps and superclass constraints calling Closed Type Families needs clunky machinery to concoct a CTF, give equations disconnected from the class, and still you're liable to need instances that look to GHC like they're overlapping. Then taking the hs2017 paper's "raise expressive power ... to first-order logic": * Superclass constraints with implications express more precisely the logic of the class. * Without an explicit FunDep, we avoid the 'FunDep consistency check', which is onerous and imprecise; and * anyway GHC's implementation is bogus -- as it needs to be, because FunDeps are imprecise. * Sometimes we can avoid `UndecidableInstances` or at least write instances that are less cluttered. > Can you give a concrete example of a function that usefully uses an equality constraint in the head of an implication? This should be a function that I can call (that is, the constraints are satisfiable). The class `C` above is emulating a regular FunDep; no reason it couldn't have methods. Here's something more ambitious (a classic litmus test of expressivity): {{{ data HNil = HNil; data HCons e l = HCons e l -- method to eliminate element 'e' from a heterogeneous list 'l' class ElimElem e l l''' | e l -> l''' where -- here's the classic definition, with FunDep and overlaps elimElem :: e -> l -> l''' -- because overlaps, I can't use an Associated Type in the class instance ElimElem e HNil HNil where elimElem _ HNil = HNil instance {-# OVERLAPPING #-} (ElimElem e l' l''') => ElimElem e (HCons e l') l''' where elimElem _x (HCons _ l') = elimElem _x l' -- instance (ElimElem e l' l''') => ElimElem e (HCons e' l') (HCons e' l''') where -- wrong! instance head not strictly more general instance (ElimElem e l' l'', l''' ~ HCons e' ''') => ElimElem e (HCons e' l') l''' where elimElem _x (HCons y l') = HCons y (elimElem _x l') }}} I'd like to write that without FunDeps -- then can I use implications? {{{ class (l ~ HNil => l''' ~ HNil, ( forall l'. l ~ HCons e l' => (ElimElem e l' l'''), ( forall e' l'. (l ~ HCons e' l', e /~ e') => (ElimElem e l' l'', l''' ~ HCons e' l'') ) => ElimElem e l' l''' where -- no FunDep elimElem :: e -> l -> l''' -- HNil and HCons matching instances as above, but no OVERLAPPING instance (ElimElem e l' l'') => ElimElem e (HCons e' l') (HCons e' l'') where elimElem _x (HCons y l') = HCons y (elimElem _x l') }}} Yes the two `HCons` instances might theoretically overlap (looking only at the instance heads) -- so again I can't use an Associated TF; but we never call elimElem at the intersection type, thanks to the type improvement applied from the superclass constraints. (I'd still prefer to make that explicit with an Apartness Guard ...) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 03:55:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 03:55:58 -0000 Subject: [GHC] #15366: GHC.Conc.Windows has a surprising queue In-Reply-To: <045.4d027c14d6779c15e2428ddd193b98f5@haskell.org> References: <045.4d027c14d6779c15e2428ddd193b98f5@haskell.org> Message-ID: <060.a5a1ba7172445f63c3bc823a19a6cbd3@haskell.org> #15366: GHC.Conc.Windows has a surprising queue -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: simonmar (added) Comment: CCing Simon Marlow, because he seems to have written this bit. Is there some reason to use a list here rather than some sort of heap? The list version is around `O(n^2)`ish. With a heap, pending delays would be inserted into a heap, then when the time came merged with the heap of existing delays. The whole thing would be `n log n`ish and probably rather fast. A pairing heap should work pretty well, although something with better real-time bounds might be better for preventing main-loop stalls. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 08:55:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 08:55:09 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.06536b85c77bc8f862c7eeca005b3cb4@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > What about doing StgCse after unarising? I think this is a good idea, but it reveals another bug in StgCse. Basically StgCse reverts unarise by using case binders when scrutinee is a unboxed tuple, e.g. {{{ case of bndr { } }}} Unarise eliminates all occurances of `bndr` in alts, but StgCse does the opposite, e.g. replaces `(#,#) foo bar` with `bndr`. This is caught by StgLint which is good. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 09:08:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 09:08:07 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.6da7295bdd0c8f565fd419cf942f8f8a@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > Basically StgCse reverts unarise by using case binders when scrutinee is a unboxed tuple I should add that this is only a bug when we run StgCse after unarise. Before unarise unboxed tuple terms can be replaced by case binders. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 09:28:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 09:28:20 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.9961d15dd809eeddba3c117c2ddfdb86@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4962 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D4962 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 09:32:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 09:32:27 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails In-Reply-To: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> References: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> Message-ID: <065.94295f1e51dffa1dd7ea500ae9c67786@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: fixed | TypeFamilies, CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: indexed- crash or panic | types/should_compile/T15142 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Richard, I have augmented the Note as below. Do you agree with it? On the last point, we say that this does not have a CUSK (taken from `dependent/should_compile/kind_levels`): {{{ data C :: B a -> * }}} But why not? The lexical-forall rule means that it's equivalent to {{{ data C :: forall a. B a -> * }}} which now does have a CUSK. Either the rule needs more justification, or its over-restrictive. Here's the new Note: {{{ {- Note [CUSKs: complete user-supplied kind signatures] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We kind-check declarations differently if they have a complete, user- supplied kind signature (CUSK). This is because we can safely generalise a CUSKed declaration before checking all of the others, supporting polymorphic recursion. See ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference#Proposednewstrategy and #9200 for lots of discussion of how we got here. PRINCIPLE: a type declaration has a CUSK iff we could produce a separate kind signature for it, just like a type signature for a function, looking only at the header of the declaration. Examples: * data T1 (a :: *->*) (b :: *) = .... -- Has CUSK; equivalant to T1 :: (*->*) -> * -> * * data T2 a b = ... -- No CUSK; we do not want to guess T2 :: * -> * -> * -- becuase the full decl might be data T a b = MkT (a b) * data T3 (a :: k -> *) (b :: *) = ... -- CUSK; equivalent to T3 :: (k -> *) -> * -> * -- We lexically generalise over k to get -- T3 :: forall k. (k -> *) -> * -> * -- The generalisation is here is purely lexical, just like -- f3 :: a -> a -- means -- f3 :: forall a. a -> a * data T4 (a :: j k) = ... -- CUSK; equivalent to T4 :: j k -> * -- which we lexically generalise to T4 :: forall j k. j k -> * -- and then, if PolyKinds is on, we further generalise to -- T4 :: forall kk (j :: kk -> *) (k :: kk). j k -> * -- Again this is exactly like what happens as the term level -- when you write -- f4 :: forall a b. a b -> Int NOTE THAT * A CUSK does /not/ mean that everything about the kind signature is fully specified by the user. Look at T4 and f4: we had do do kind inference to figure out the kind-quantification. But in both cases (T4 and f4) that inference is done looking /only/ at the header of T4 (or signature for f4), not at the definition thereof. * The CUSK completely fixes the kind of the type constructor, forever. * The precise rules, for each declaration form, for whethher a declaration has a CUSK are given in the user manual section "Complete user- supplied kind signatures and polymorphic recursion". BUt they simply implement PRINCIPLE above. * Open type families are interesting: type family T5 a b :: * There simply /is/ no accompanying declaration, so that info is all we'll ever get. So we it has a CUSK by definition, and we default any un-fixed kind variables to *. * Associated types are a bit tricker: class C6 a where type family T6 a b :: * op :: a Int -> Int Here C6 does not have a CUSK (in fact we ultimately discover that a :: * -> *). And hence neither does T6, the associated family, because we can't fix its kind until we have settled C6. Another way to say it: unlike a top-level, we /may/ discover more about a's kind from C6's definition. * A data definition with a top-level :: must explicitly bind all kind variables to the right of the ::. See test dependent/should_compile/KindLevels, which requires this case. (Naturally, any kind variable mentioned before the :: should not be bound after it.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 09:32:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 09:32:35 -0000 Subject: [GHC] #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) In-Reply-To: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> References: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> Message-ID: <065.ef2b6cbbe08e95fbc3197448ba780826@haskell.org> #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Tritlo): * owner: (none) => Tritlo Comment: I'll get to work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 10:52:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 10:52:15 -0000 Subject: [GHC] #15372: GHCi leaks in DEBUG mode In-Reply-To: <047.2ac34cbfa4c72468332be193667a285f@haskell.org> References: <047.2ac34cbfa4c72468332be193667a285f@haskell.org> Message-ID: <062.9504d11eb3316002415e239eef2c9426@haskell.org> #15372: GHCi leaks in DEBUG mode -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15246 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonmar (added) * related: => #15246 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 10:53:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 10:53:04 -0000 Subject: [GHC] #15246: -fghci-leak-cheak causes many testsuite failures with the quick build flavour In-Reply-To: <050.c93ffe426b77b4e3ab4a606d2f8a144f@haskell.org> References: <050.c93ffe426b77b4e3ab4a606d2f8a144f@haskell.org> Message-ID: <065.a9b6f83cc6109091c87a19c0aaf316b5@haskell.org> #15246: -fghci-leak-cheak causes many testsuite failures with the quick build flavour -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15372 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15372 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 11:06:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 11:06:54 -0000 Subject: [GHC] #15372: GHCi leaks in DEBUG mode In-Reply-To: <047.2ac34cbfa4c72468332be193667a285f@haskell.org> References: <047.2ac34cbfa4c72468332be193667a285f@haskell.org> Message-ID: <062.ab1de7a73bf9688b4cd9028f84734da2@haskell.org> #15372: GHCi leaks in DEBUG mode -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15246 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Try this? {{{ diff --git a/testsuite/config/ghc b/testsuite/config/ghc index f41f372..dde5bac 100644 --- a/testsuite/config/ghc +++ b/testsuite/config/ghc @@ -80,7 +80,7 @@ config.way_flags = { 'prof_no_auto' : ['-prof', '-static', '-fasm'], 'profasm' : ['-O', '-prof', '-static', '-fprof-auto'], 'profthreaded' : ['-O', '-prof', '-static', '-fprof-auto', '-threaded'], - 'ghci' : ['--interactive', '-v0', '-ignore-dot-ghci', '-fno- ghci-history', '-fghci-leak-check', '+RTS', '-I0.1', '-RTS'], + 'ghci' : ['--interactive', '-v0', '-ignore-dot-ghci', '-fno- ghci-history', '+RTS', '-I0.1', '-RTS'] + ['-fghci-leak-check'] if not config.compiler_debugged else [], 'sanity' : ['-debug'], 'threaded1' : ['-threaded', '-debug'], 'threaded1_ls' : ['-threaded', '-debug'], }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 12:13:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 12:13:05 -0000 Subject: [GHC] #15087: Internal Error with Bibliography Profiling In-Reply-To: <047.4e3533cfbf44e6814004409e34e96335@haskell.org> References: <047.4e3533cfbf44e6814004409e34e96335@haskell.org> Message-ID: <062.b5fc08df9a7d7cff10e918fec636395a@haskell.org> #15087: Internal Error with Bibliography Profiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063, #15165, | Differential Rev(s): Phab:D4928 #7836 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"2625f1310edeff62eb3876cc6efbe105a80fe4ad/ghc" 2625f131/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2625f1310edeff62eb3876cc6efbe105a80fe4ad" Fix processHeapClosureForDead CONSTR_NOCAF case CONSTR_NOCAF was introduced with 55d535da10d as a replacement for CONSTR_STATIC and CONSTR_NOCAF_STATIC, however, as explained in Note [static constructors], we copy CONSTR_NOCAFs (which can also be seen in evacuate) during GC, and they can become dead, like other CONSTR_X_Ys. processHeapClosureForDead is updated to reflect this. Test Plan: Validates on x86_64. Existing failures on i386. Reviewers: simonmar, bgamari, erikd Reviewed By: simonmar, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #7836, #15063, #15087, #15165 Differential Revision: https://phabricator.haskell.org/D4928 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 12:13:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 12:13:05 -0000 Subject: [GHC] #15165: GHC 8.2.2: internal error with +RTS -hb In-Reply-To: <043.05bd633e0b8fc1db67420a68577349a9@haskell.org> References: <043.05bd633e0b8fc1db67420a68577349a9@haskell.org> Message-ID: <058.2c3bb400ca4accc641189137b73f6b35@haskell.org> #15165: GHC 8.2.2: internal error with +RTS -hb -------------------------------------+------------------------------------- Reporter: kfiz | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Profiling | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063, #15087, | Differential Rev(s): Phab:D4928 #7836 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"2625f1310edeff62eb3876cc6efbe105a80fe4ad/ghc" 2625f131/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2625f1310edeff62eb3876cc6efbe105a80fe4ad" Fix processHeapClosureForDead CONSTR_NOCAF case CONSTR_NOCAF was introduced with 55d535da10d as a replacement for CONSTR_STATIC and CONSTR_NOCAF_STATIC, however, as explained in Note [static constructors], we copy CONSTR_NOCAFs (which can also be seen in evacuate) during GC, and they can become dead, like other CONSTR_X_Ys. processHeapClosureForDead is updated to reflect this. Test Plan: Validates on x86_64. Existing failures on i386. Reviewers: simonmar, bgamari, erikd Reviewed By: simonmar, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #7836, #15063, #15087, #15165 Differential Revision: https://phabricator.haskell.org/D4928 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 12:13:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 12:13:05 -0000 Subject: [GHC] #15063: T3001-2 fails on i386 Linux In-Reply-To: <046.fa478fb40ce13bbb24172a958e864762@haskell.org> References: <046.fa478fb40ce13bbb24172a958e864762@haskell.org> Message-ID: <061.03bcd68ba40344dd79d5592d112be631@haskell.org> #15063: T3001-2 fails on i386 Linux -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Profiling | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15087, #15165, | Differential Rev(s): Phab:D4928 #7836 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"2625f1310edeff62eb3876cc6efbe105a80fe4ad/ghc" 2625f131/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2625f1310edeff62eb3876cc6efbe105a80fe4ad" Fix processHeapClosureForDead CONSTR_NOCAF case CONSTR_NOCAF was introduced with 55d535da10d as a replacement for CONSTR_STATIC and CONSTR_NOCAF_STATIC, however, as explained in Note [static constructors], we copy CONSTR_NOCAFs (which can also be seen in evacuate) during GC, and they can become dead, like other CONSTR_X_Ys. processHeapClosureForDead is updated to reflect this. Test Plan: Validates on x86_64. Existing failures on i386. Reviewers: simonmar, bgamari, erikd Reviewed By: simonmar, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #7836, #15063, #15087, #15165 Differential Revision: https://phabricator.haskell.org/D4928 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 12:13:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 12:13:05 -0000 Subject: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb In-Reply-To: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> References: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> Message-ID: <064.a998f84703bca3a37495f0306e944b19@haskell.org> #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063, #15087, | Differential Rev(s): Phab:D4928 #15165 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"2625f1310edeff62eb3876cc6efbe105a80fe4ad/ghc" 2625f131/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2625f1310edeff62eb3876cc6efbe105a80fe4ad" Fix processHeapClosureForDead CONSTR_NOCAF case CONSTR_NOCAF was introduced with 55d535da10d as a replacement for CONSTR_STATIC and CONSTR_NOCAF_STATIC, however, as explained in Note [static constructors], we copy CONSTR_NOCAFs (which can also be seen in evacuate) during GC, and they can become dead, like other CONSTR_X_Ys. processHeapClosureForDead is updated to reflect this. Test Plan: Validates on x86_64. Existing failures on i386. Reviewers: simonmar, bgamari, erikd Reviewed By: simonmar, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #7836, #15063, #15087, #15165 Differential Revision: https://phabricator.haskell.org/D4928 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 12:14:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 12:14:16 -0000 Subject: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb In-Reply-To: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> References: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> Message-ID: <064.cce90f52c0bcbc7ba240d43b31b168ed@haskell.org> #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063, #15087, | Differential Rev(s): Phab:D4928 #15165 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 12:14:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 12:14:26 -0000 Subject: [GHC] #15063: T3001-2 fails on i386 Linux In-Reply-To: <046.fa478fb40ce13bbb24172a958e864762@haskell.org> References: <046.fa478fb40ce13bbb24172a958e864762@haskell.org> Message-ID: <061.29fdb58c53d93a2f75096c3e14156dcd@haskell.org> #15063: T3001-2 fails on i386 Linux -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.6.1 Component: Profiling | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15087, #15165, | Differential Rev(s): Phab:D4928 #7836 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 12:14:29 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 12:14:29 -0000 Subject: [GHC] #15087: Internal Error with Bibliography Profiling In-Reply-To: <047.4e3533cfbf44e6814004409e34e96335@haskell.org> References: <047.4e3533cfbf44e6814004409e34e96335@haskell.org> Message-ID: <062.61039214dcdb0da4fb5cf332eefbd9cd@haskell.org> #15087: Internal Error with Bibliography Profiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063, #15165, | Differential Rev(s): Phab:D4928 #7836 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 12:14:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 12:14:35 -0000 Subject: [GHC] #15165: GHC 8.2.2: internal error with +RTS -hb In-Reply-To: <043.05bd633e0b8fc1db67420a68577349a9@haskell.org> References: <043.05bd633e0b8fc1db67420a68577349a9@haskell.org> Message-ID: <058.73678439922ac2c89cc42212941da938@haskell.org> #15165: GHC 8.2.2: internal error with +RTS -hb -------------------------------------+------------------------------------- Reporter: kfiz | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Profiling | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063, #15087, | Differential Rev(s): Phab:D4928 #7836 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 13:18:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 13:18:55 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.b191c6c9eaf120df6ebab6866577e743@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Is this fixed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 13:54:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 13:54:45 -0000 Subject: [GHC] #15373: core-spec.pdf contains parse errors Message-ID: <050.1886863a6e820de56c5048e8275c72f6@haskell.org> #15373: core-spec.pdf contains parse errors -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After commit 2fbe0b5171fd5639845b630faccb9a0c3b564df7, `core-spec.pdf` now contains several gnarly looking parse errors (which I'll attach screenshots of separately). This is because `nth` coercion typing rule was extended to take a role as an argument, but the uses of `nth` in the `S_Push`, `S_CPush`, and `S_CasePush` rules were never updated to reflect this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 13:55:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 13:55:07 -0000 Subject: [GHC] #15373: core-spec.pdf contains parse errors In-Reply-To: <050.1886863a6e820de56c5048e8275c72f6@haskell.org> References: <050.1886863a6e820de56c5048e8275c72f6@haskell.org> Message-ID: <065.106216bef3f37c3ef8134246c9848ca6@haskell.org> #15373: core-spec.pdf contains parse errors -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "core-spec1.png" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 13:55:18 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 13:55:18 -0000 Subject: [GHC] #15373: core-spec.pdf contains parse errors In-Reply-To: <050.1886863a6e820de56c5048e8275c72f6@haskell.org> References: <050.1886863a6e820de56c5048e8275c72f6@haskell.org> Message-ID: <065.41766ac8fe32711687110bfb314efe8d@haskell.org> #15373: core-spec.pdf contains parse errors -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "core-spec2.png" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 14:00:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 14:00:57 -0000 Subject: [GHC] #15373: core-spec.pdf contains parse errors In-Reply-To: <050.1886863a6e820de56c5048e8275c72f6@haskell.org> References: <050.1886863a6e820de56c5048e8275c72f6@haskell.org> Message-ID: <065.df3db6de646974bdb64266c747688f1c@haskell.org> #15373: core-spec.pdf contains parse errors -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4965 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire (added) * status: new => patch * differential: => Phab:D4965 Comment: I took a stab at fixing this in Phab:D4965. Richard, please check my work! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 14:02:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 14:02:32 -0000 Subject: [GHC] #15359: Quantified constraints do not work with equality constraints In-Reply-To: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> References: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> Message-ID: <062.e26423180821003791177db8bde96ae6@haskell.org> #15359: Quantified constraints do not work with equality constraints -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): As you point out, the last two instance always overlap looking only at the instance heads. So I think you'd still need `{-# OVERLAPPING #-}`. Previously, Simon was worried that the equality constraints would always be redundant. I think that's still true in your examples, but with a key twist: the equality constraints can be used for improvement during type checking. That may indeed be correct. As a practical matter though, I can't imagine how to implement them. And, given the fact that we have many ways of expressing these ideas already, without quantified equality constraints, (for example, your `ElimElem` could be implemented as a closed type family), I'm not yet motivated to start thinking about how to write a solver than can deal with these. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 14:04:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 14:04:50 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.d0b53364f79568dcf495e19f4decb34d@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ningning): Replying to [comment:18 RyanGlScott]: > Is this fixed? Not yet. We committed but currently we still have some performance issue. I am still working on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 14:05:51 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 14:05:51 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.96c590d8717be88daafb4ce4fca1d43a@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ningning): * owner: (none) => ningning -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 14:06:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 14:06:19 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.ba33bb06bb73334b43055c9a9d83d29e@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah, my apologies then. (I interpreted comment:14 as "let's just accept the performance regressions and move on".) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 14:17:24 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 14:17:24 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails In-Reply-To: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> References: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> Message-ID: <065.d27c6126a21170e48665ad95a2400a20@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: fixed | TypeFamilies, CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: indexed- crash or panic | types/should_compile/T15142 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I agree with everything in that Note. Why have the explicit `forall`? Because perhaps the user wants inference, not CUSKness. By making a decision based on the `forall`, then the user can get what they want. For example: {{{#!hs data T1 :: k1 k2 -> Type where MkT1 :: forall (k1 :: Type -> Type) (k2 :: Type) (x :: k1 k2). T1 x }}} There are two possible meanings for this. Meaning 1 (M1): {{{#!hs T1 :: forall (k1 :: Type -> Type) (k2 :: Type). k1 k2 -> Type MkT1 :: forall (k1 :: Type -> Type) (k2 :: Type) (x :: k1 k2). T1 k1 k2 x }}} Meaning 2 (M2): {{{#!hs T1 :: forall (k :: Type) (k1 :: k -> Type) (k2 :: k). k1 k2 -> Type MkT1 :: forall (k :: Type) (k1 :: k -> Type) (k2 :: k) (x :: k1 k2). (k ~# Type) -> T1 k k1 k2 x }}} In M1, we do not quantify `T1`'s kind further, and the data constructor is not GADT-like. In M2, though, we ''do'' generalize, making `MkT1` a GADT constructor packing an equality. M1 is what happens if `T1` does not have a CUSK. `M2` is what happens when it does. Having CUSKness depend on the presence of the `forall` allows users to choose which of these interpretations to use. We ''could'' absolutely, remove it, but then I don't know how to write `T1` with meaning M1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 14:32:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 14:32:20 -0000 Subject: [GHC] #15372: GHCi leaks in DEBUG mode In-Reply-To: <047.2ac34cbfa4c72468332be193667a285f@haskell.org> References: <047.2ac34cbfa4c72468332be193667a285f@haskell.org> Message-ID: <062.081d445dd0edbc65754cb6f7677dd79f@haskell.org> #15372: GHCi leaks in DEBUG mode -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15246 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): That almost worked. Here is the correct line: {{{ 'ghci' : ['--interactive', '-v0', '-ignore-dot-ghci', '-fno- ghci-history', '+RTS', '-I0.1', '-RTS'] + (['-fghci-leak-check'] if not config.compiler_debugged else []), }}} Note the parens around the new bit. I will push my changes shortly, hopefully. Thanks for the quick response! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 14:41:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 14:41:16 -0000 Subject: [GHC] #12674: GHC doesn't handle ./ prefixed paths correctly In-Reply-To: <047.897ae5e9c5c47ed13f84034ccb7c5729@haskell.org> References: <047.897ae5e9c5c47ed13f84034ccb7c5729@haskell.org> Message-ID: <062.50d5f8cf0651c0825873497292592dcd@haskell.org> #12674: GHC doesn't handle ./ prefixed paths correctly -------------------------------------+------------------------------------- Reporter: dobenour | Owner: RolandSenn Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): You do have a third option, which is to create a wrapper for normalise in ghc and call that. On posix platforms you then have this special case if the part starts with `./-` this is much safer approach than changing filepath. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 14:53:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 14:53:35 -0000 Subject: [GHC] #15363: Do some cleaning up of the testsuite driver In-Reply-To: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> References: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> Message-ID: <060.6c919a1107d30ce84fb3701533a915d0@haskell.org> #15363: Do some cleaning up of the testsuite driver -------------------------------------+------------------------------------- Reporter: lantti | Owner: lantti Type: task | Status: new Priority: low | Milestone: 8.6.1 Component: Test Suite | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lantti): It seems that timeout.hs is even not fully functional under minTTY/msys2 shell at the moment. Something along the way intercepts Ctrl-c and kills the whole process tree without giving the timeout program or the testsuite cleanup code (stopNow(), etc) a chance to react to it. The bright side to this is that those cleanup routines were mostly concerned with eliminating stray processes which the shell (or whatever intercepts the Ctrl-C) seems to do for us anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 14:54:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 14:54:57 -0000 Subject: [GHC] #15374: Testsuite: compile_timeout_multiplier is fragile Message-ID: <047.7876c280adf4842052a04dcffaef0078@haskell.org> #15374: Testsuite: compile_timeout_multiplier is fragile -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm taking a sweep through the testsuite, trying to eliminate failures in a `DEBUG` compiler. But two tests are stymieing me: `pmcheck/should_compile/T11{276,374}`. Both of these use the `compile_timout_multiplier` option in their `all.T` entries. This option means that, instead of the normal 300s allotted to the test, these tests get only 3s. In my setup, with a `DEBUG` (read: unoptimized) stage2 compiler, these tests fail when I'm running the testsuite in parallel. Then, when I run the tests individually, they succeed. This poses two problems: 1. I can only see the failure when my machine is stressed, and it's disconcerting to have a failure appear and disappear depending on how I look. 2. There is (sometimes) a failure in `DEBUG` mode. What is the goal of `compile_timeout_multiplier`? If we're really testing performance (which #11276 and #11374 indicate), then these tests should be in `perf/compiler` and be "stat" tests, where some wibbling in the numbers is expected (and where `DEBUG` compilers are exempted). I would imagine that `compile_timeout_multiplier` should only ever get values greater than 1, when a non-performance test is so expensive to run that it takes more than 300s. As a local solution here, I think these two tests should move to `perf/compiler`. Other pattern-match tests also have `compile_timeout_multiplier`, too, and I can move these as well. Any objections? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 15:20:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 15:20:36 -0000 Subject: [GHC] #15375: GHC.Exts.Heap.getClosureData doesn't return the payload for AP_STACK Message-ID: <047.b9c11902257dc4d5ecf745bb5f7247f7@haskell.org> #15375: GHC.Exts.Heap.getClosureData doesn't return the payload for AP_STACK -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: Runtime | Version: 8.4.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See Phab:D4955 We used to return the payload, but a stack is a mixture of pointers and non-pointers, so this was bogus. In Phab:D4955 I changed it to ignore the payload, so now at least it doesn't crash, but we don't have any payload info. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 16:21:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 16:21:46 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.01e3687cb64bb0329bf1bed23b8bdd4c@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Thanks! Yes, I'm OK now - too OK in fact, because now it validates cleanly, with no apparent performance problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 16:25:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 16:25:22 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.191ab26412f91eddc292ddce752842e3@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Hooray! :) Would you mind rebasing and committing, then? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 22:20:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 22:20:16 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.d17f9b2ffd8ce6b1457d63dfc4268754@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > with no apparent performance problems. I would love it if it was possible to do a `nofib`-style run on `testsuite/perf`, producing a table showing changes before and after. The current testsuite stuff just tells if you get more than 5% worse (or whatever). There could easily be a big swing we never see. It's laborious running the tests one by one. Would be possible for `nofib-analyse` to look at the logs somehow? It'd be extremely helpful. Meanwhile, yes, let's commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 13 22:48:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 13 Jul 2018 22:48:28 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails In-Reply-To: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> References: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> Message-ID: <065.0288accbc6803533848facdb46d46eaf@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: fixed | TypeFamilies, CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: indexed- crash or panic | types/should_compile/T15142 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): comment:21 is quite debatable as Richard and I agreed on the phone today. It's easier to understand at the term level. Suppose you write {{{ f :: forall a b. a b -> Int f x = let y :: b; y = undefined in 5 }}} With `-XPolyKinds` the type signature is generalised to {{{ f :: forall k. (a :: k->*) (b :: k). a b -> Int }}} But then the definition of `f` is less polymorphic than that! The use of `y::b` forces `b::*`; but the signature says `b::k`, so the definition is rejected. By omitting a `forall` in the final item of the CUSK comment above, the curren system says "not a CUSK", so inference can do its magic. But we can't currently do that in terms. Except perhaps by making a partial type signature like {{{ f :: forall a b. a b -> _ }}} for which inference takes place. The final bullet in the Note, about data types, amounts to a very ad-hoc way of signaling "don't use a CUSK". Ugh. We decided to leave it as-is for now, because we'll end up revisiting all this when we introduce separate kind signatures for type constructors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 01:22:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 01:22:11 -0000 Subject: [GHC] #15363: Do some cleaning up of the testsuite driver In-Reply-To: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> References: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> Message-ID: <060.602dcc637d3ff0d2b9c447b6ff10389c@haskell.org> #15363: Do some cleaning up of the testsuite driver -------------------------------------+------------------------------------- Reporter: lantti | Owner: lantti Type: task | Status: new Priority: low | Milestone: 8.6.1 Component: Test Suite | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lantti): Using winpty instead of mintty on Windows allows the ctrl-c event to propagate through the process tree, but even then the clean up routines are not run and the results from the tests already completed are not displayed. At the moment I presume this is because the timeout.hs is not able to react to the ctrl-c event while waiting on the child process. When run in isolation it only reacts after the child returns (or never if the child ignores ctrl-c). As part of the testsuite it doesn't get a chance to react before being killed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 07:23:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 07:23:54 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.299557a1d294bf681e068b645d11ab30@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): It looks like I am seeing this same bug on GHC 8.2.2. This is again in a streaming library with stream fusion like vector and I am seeing the problem specifically with the "filter" code in the library, though it does not always happen, only in some cases. I have two branches in my repo that reproduce the problem: * See branch https://github.com/composewell/streamly/tree/ghc-8.2.2-bug . The last commit on this branch https://github.com/composewell/streamly/commit/8f08248eba6702159f7bc3fe99e0c2244592dbb0 disables the culprit code. * The second branch is https://github.com/composewell/streamly/tree/ghc-8.2.2-bug2 . The last commit on this branch disables the culprit code. The "filter" API code that is being used in these cases is defined in https://github.com/composewell/streamly/blob/ghc-8.2.2-bug2/src/Streamly/Streams/StreamD.hs . The code goes like this: {{{ {-# INLINE_NORMAL filterM #-} filterM :: Monad m => (a -> m Bool) -> Stream m a -> Stream m a filterM f (Stream step state) = Stream step' state where {-# INLINE_LATE step' #-} step' gst st = do r <- step (rstState gst) st case r of Yield x s -> do b <- f x if b then return $ Yield x s else step' gst s Stop -> return $ Stop {-# INLINE filter #-} filter :: Monad m => (a -> Bool) -> Stream m a -> Stream m a filter f = filterM (return . f) }}} This is very much like the vector code, except that there is no Skip constructor. I was originally thinking that it may have something to do with the join point optimization. I hope this will shed some light on the issue. I am not seeing the issue with GHC-8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 10:33:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 10:33:34 -0000 Subject: [GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin In-Reply-To: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> References: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> Message-ID: <062.2c6768d29eef1282a6922fb0f90361d4@haskell.org> #15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | typeable,knownnat Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10348 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by LeanderK): You are right, the issue mostly stems from the fact (I think? At least that is the most common problem where it all breaks down) that I can't convince the typechecker that things defined by induction (through 0 and (n+1)) are valid and hold for every n. I have no idea what the best technical solution would be. I am just a user. Here's a related issue: https://github.com/clash-lang/ghc-typelits- natnormalise/issues/13, which is very similar to the usual pains when I use type-level nats. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 11:05:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 11:05:43 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.cce3508fea8cf82f0f515542dceeed90@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Ah, never mind, it seems I had misinterpreted what those phabricator tags mean; re-running validate on the correct commit now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 13:30:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 13:30:16 -0000 Subject: [GHC] #15376: GHC determine illegal kind for standalone deriving with Deriving via Message-ID: <053.abe3d7137dc5f177439798cce27772ab@haskell.org> #15376: GHC determine illegal kind for standalone deriving with Deriving via -------------------------------------+------------------------------------- Reporter: | Owner: (none) mizunashi_mana | Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Happy to release GHC 8.6.1-alpha1! I used it to test new extensions, and then I met below errors: {{{ $ ghci-8.6.0.20180627 GHCi, version 8.6.0.20180627: http://www.haskell.org/ghc/ :? for help Prelude> :set -XDerivingVia -XStandaloneDeriving Prelude> newtype FunctorWrapped f a = FunctorWrapped (f a) Prelude> deriving via f instance Functor f => Functor (FunctorWrapped f) :3:33: error: • Expected kind ‘* -> *’, but ‘f’ has kind ‘*’ • In the first argument of ‘Functor’, namely ‘f’ In the stand-alone deriving instance for ‘Functor f => Functor (FunctorWrapped f)’ :3:62: error: • Expected kind ‘* -> *’, but ‘f’ has kind ‘*’ • In the first argument of ‘FunctorWrapped’, namely ‘f’ In the first argument of ‘Functor’, namely ‘(FunctorWrapped f)’ In the stand-alone deriving instance for ‘Functor f => Functor (FunctorWrapped f)’ }}} However, {{{ newtype FunctorWrapped f a = FunctorWrapped (f a) deriving Functor via f }}} is passed through on GHC 8.6.1-alpha1. Is this a bug or my misunderstand? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 14:21:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 14:21:08 -0000 Subject: [GHC] #15376: GHC determine illegal kind for standalone deriving with Deriving via In-Reply-To: <053.abe3d7137dc5f177439798cce27772ab@haskell.org> References: <053.abe3d7137dc5f177439798cce27772ab@haskell.org> Message-ID: <068.ef506d9075295d7868ebe0944af5f9a0@haskell.org> #15376: GHC determine illegal kind for standalone deriving with Deriving via -------------------------------------+------------------------------------- Reporter: mizunashi_mana | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * keywords: => deriving * cc: Iceland_jack, RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 14:53:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 14:53:52 -0000 Subject: [GHC] #15376: GHC determine illegal kind for standalone deriving with Deriving via In-Reply-To: <053.abe3d7137dc5f177439798cce27772ab@haskell.org> References: <053.abe3d7137dc5f177439798cce27772ab@haskell.org> Message-ID: <068.9241c9a3891bdfef36402896d5f0545d@haskell.org> #15376: GHC determine illegal kind for standalone deriving with Deriving via -------------------------------------+------------------------------------- Reporter: mizunashi_mana | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14331 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: kosmikus (added) * blockedby: => 14331 Comment: This is indeed a known limitation of the way `deriving` declarations are typechecked. //Short answer//: You can work around the issue by introducing an explicit type signature, i.e., {{{#!hs deriving via (f :: * -> *) instance Functor f => Functor (FunctorWrapped f) }}} //Long answer//: Any type variables quantified by `via` are kind-checked in isolation, without any information that might be gleaned from bidirectionally kind-checking the instance head. This means that GHC sees: {{{ deriving via f ... }}} And hastily concludes that `f` is of kind `*`. Bummer. We (kosmikus, Iceland_jack, and I) discussed this at some length in https://github.com/RyanGlScott/ghc/issues/29, and came to the conclusion that we might be able to fix this issue by introducing fresh unification variables when kind-checking, then unifying, and then generalizing/skolemizing if there are any unfilled unification variables left. This bears a close resemblance to the algorithm described in https://ghc.haskell.org/trac/ghc/ticket/14331#comment:31, so I'm going to claim that this ticket is blocked by #14331. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 14:54:59 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 14:54:59 -0000 Subject: [GHC] #14331: Overzealous free-floating kind check causes deriving clause to be rejected In-Reply-To: <050.cb87f2a10e38fd0ac57d92b074ac5d5b@haskell.org> References: <050.cb87f2a10e38fd0ac57d92b074ac5d5b@haskell.org> Message-ID: <065.14c0f2778b8d633f8405445945d2b1ea@haskell.org> #14331: Overzealous free-floating kind check causes deriving clause to be rejected -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T14331 Blocked By: | Blocking: 15376 Related Tickets: #15376 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15376 Comment: #15376 is a symptom of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 15:02:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 15:02:50 -0000 Subject: [GHC] #15361: Error message displays redundant equality constraint In-Reply-To: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> References: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> Message-ID: <065.2ed2353deb5ca9b3492a66831be88aae@haskell.org> #15361: Error message displays redundant equality constraint -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14394 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): We can fix this issue with the following patch: {{{#!diff diff --git a/compiler/typecheck/TcErrors.hs b/compiler/typecheck/TcErrors.hs index 95dc152..1098b1f 100644 --- a/compiler/typecheck/TcErrors.hs +++ b/compiler/typecheck/TcErrors.hs @@ -1821,7 +1821,7 @@ pp_givens givens where ppr_given herald (Implic { ic_given = gs, ic_info = skol_info , ic_env = env }) - = hang (herald <+> pprEvVarTheta gs) + = hang (herald <+> pprEvVarTheta (mkMinimalBySCs evVarPred gs)) 2 (sep [ text "bound by" <+> ppr skol_info , text "at" <+> ppr (tcl_loc env) ]) }}} (Where `pp_givens` is the function that prints out the stuff after `from the context:`.) Does this sound like a reasonable approach? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 15:08:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 15:08:11 -0000 Subject: [GHC] #12674: GHC doesn't handle ./ prefixed paths correctly In-Reply-To: <047.897ae5e9c5c47ed13f84034ccb7c5729@haskell.org> References: <047.897ae5e9c5c47ed13f84034ccb7c5729@haskell.org> Message-ID: <062.7b5e6a761ff579ea0b9554c0467244f8@haskell.org> #12674: GHC doesn't handle ./ prefixed paths correctly -------------------------------------+------------------------------------- Reporter: dobenour | Owner: RolandSenn Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RolandSenn): @Phyx: Many thanks to your excellent solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 15:32:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 15:32:35 -0000 Subject: [GHC] #15377: Cut an STM release Message-ID: <046.0afa99baf8c4ccfd8f3c8b402046da50@haskell.org> #15377: Cut an STM release -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries/stm | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 15:44:44 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 15:44:44 -0000 Subject: [GHC] #15376: GHC determine illegal kind for standalone deriving with Deriving via In-Reply-To: <053.abe3d7137dc5f177439798cce27772ab@haskell.org> References: <053.abe3d7137dc5f177439798cce27772ab@haskell.org> Message-ID: <068.f82a789070b432e2a3ce580b475fe13d@haskell.org> #15376: GHC determine illegal kind for standalone deriving with Deriving via -------------------------------------+------------------------------------- Reporter: mizunashi_mana | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14331 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mizunashi_mana): Replying to [comment:2 RyanGlScott]: > This is indeed a known limitation of the way `deriving` declarations are typechecked. I understand. Thank you for your comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 16:35:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 16:35:06 -0000 Subject: [GHC] #15142: GHC HEAD regression: tcTyVarDetails In-Reply-To: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> References: <050.e98a1ae073f44bf5c57814edebb43575@haskell.org> Message-ID: <065.15ad71694a0cf967d753bc6955bef1eb@haskell.org> #15142: GHC HEAD regression: tcTyVarDetails -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: fixed | TypeFamilies, CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: indexed- crash or panic | types/should_compile/T15142 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I fully agree with comment:22, including the "Ugh" and not changing it now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 17:21:26 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 17:21:26 -0000 Subject: [GHC] #15361: Error message displays redundant equality constraint In-Reply-To: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> References: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> Message-ID: <065.ddd7783162944f1492710f8684206eff@haskell.org> #15361: Error message displays redundant equality constraint -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14394 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Well, if it's that easy, yes, I'm quite happy with it. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 18:18:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 18:18:32 -0000 Subject: [GHC] #15136: High CPU when asynchronous exception and unblocking retry on TVar raced In-Reply-To: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> References: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> Message-ID: <062.998452b4ee6c54c53ebf45eb7451f28f@haskell.org> #15136: High CPU when asynchronous exception and unblocking retry on TVar raced -------------------------------------+------------------------------------- Reporter: nshimaza | Owner: osa1 Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4956 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Phab:D4961 is a continuation of the commit above and should probably be merged with it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 19:22:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 19:22:28 -0000 Subject: [GHC] #15378: Use TcLevels to decide about floating out of implications Message-ID: <047.0f21c658b64fbda0b5f8ed07d2a51f62@haskell.org> #15378: Use TcLevels to decide about floating out of implications -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If we have an implication constraint `forall[3] sk[3]. [W] alpha[2] ~ Maybe b[2]`, GHC ''floats'' the constraint out of the implication. This is necessary to solve this particular wanted, because the implication is at level 3, while the unification variable `alpha` is at level 2; the variable is thus untouchable in the implication. Right now, computing which constraints can float out is done by looking at the free variables of the constraint and comparing against the set of skolem variables bound in the implication, like `sk[3]`, above (among a few other places). However, there is a much easier way: just use the levels. We can look at the Wanted and determine that it can float out because the maximum level in the wanted is a 2, and the implication is level 3. Thus, this ticket is to track that refactoring: use levels, not free variables, in determining what to float out of an implication. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 19:36:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 19:36:53 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.08adf1f9cb19f64dd3fe213230cfa440@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): OK, I managed to build it, and get some proper test failures: {{{ Unexpected failures: /tmp/ghctest-tmsk6xdn/test spaces/./simplCore/should_compile/T3234.run T3234 [stderr mismatch] (optasm) Unexpected stat failures: /tmp/ghctest-tmsk6xdn/test spaces/./perf/compiler/T5321Fun.run T5321Fun [stat not good enough] (normal) /tmp/ghctest-tmsk6xdn/test spaces/./perf/compiler/T5631.run T5631 [stat not good enough] (normal) }}} So I'll look into those. On a side note, Haddock now fails to compile, which can be worked around by setting `HADDOCK_DOCS=NO` in `mk/validate.mk`, but should, I think, be resolved before we can merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 22:59:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 22:59:48 -0000 Subject: [GHC] #15371: Eventlog framework outputs environment variables which may cause a security issue In-Reply-To: <043.e0598f3eff95a3e71b8c6103a2d86a17@haskell.org> References: <043.e0598f3eff95a3e71b8c6103a2d86a17@haskell.org> Message-ID: <058.9be62b5bfc0f3c13d5e5b2f800bf3902@haskell.org> #15371: Eventlog framework outputs environment variables which may cause a security issue -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I am quite sympathetic to this concern; it seems like this could very easily turn into a security issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 23:03:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 23:03:42 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files Message-ID: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Piyush has graciously volunteered to fix this. Relevant commit c5609577fab8a214c50561bea861c70d4bfd47c7 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 23:03:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 23:03:54 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <060.faf19f686d06c4ca5d31725ed93f57e3@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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 ezyang): * keywords: => backpack -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 23:24:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 23:24:29 -0000 Subject: [GHC] #15138: Unable to instantiate data members of kind Nat in backpack signatures. In-Reply-To: <042.e290873b59fcee0c98fbf371f48d1238@haskell.org> References: <042.e290873b59fcee0c98fbf371f48d1238@haskell.org> Message-ID: <057.a09755e2464abf3ae933d08ccf777020@haskell.org> #15138: Unable to instantiate data members of kind Nat in backpack signatures. -------------------------------------+------------------------------------- Reporter: ppk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 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): Phab:D4951 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * keywords: => backpack -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 23:26:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 23:26:00 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.1e87fcc95dcb1007fc7eec70e00465e2@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): For completeness' sake, here's the Haddock compilation error: {{{ "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O0 -H64m -Wall -Werror -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock /haddock-library/vendor/attoparsec-0.13.1.0 -iutils/haddock/haddock- library/src-iutils/haddock/dist/build -Iutils/haddock/dist/build -iutils/haddock/dist/build/haddock/autogen -Iutils/haddock/dist/build/haddock/autogen -optP-DIN_GHC_TREE -optP- include -optPutils/haddock/dist/build/haddock/autogen/cabal_macros.h -package-id Cabal-2.3.0.0 -package-id array-0.5.2.0 -package-id base-4.12.0.0 -package-id bytestring-0.10.8.2 -package-id containers-0.5.11.0 -package-id deepseq-1.4.4.0 -package-id directory-1.3.2.3 -package-id filepath-1.4.2 -package-id ghc-8.5 -package- id ghc-boot-8.5 -package-id transformers-0.5.5.0 -package-id xhtml-3000.2.2 -funbox-strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no-user-package-db -rtsopts -Wno-unused-imports -Wno- deprecations -Wnoncanonical-monad-instances -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/haddock- api/src/Haddock/InterfaceFile.hs -o utils/haddock/dist/build/Haddock/InterfaceFile.dyn_o utils/haddock/haddock-api/src/Haddock/Convert.hs:486:39: error: • Couldn't match type ‘UniqSet.UniqSet TyVar’ with ‘InterestingVarFun -> VarSet -> ([Var], VarSet) -> ([Var], VarSet)’ Expected type: TyConBinder -> FV Actual type: TyConBinder -> TyVarSet • In the first argument of ‘mapUnionFV’, namely ‘injectiveVarsOfBinder’ In the second argument of ‘($)’, namely ‘mapUnionFV injectiveVarsOfBinder dropped_binders’ In the expression: fvVarSet $ mapUnionFV injectiveVarsOfBinder dropped_binders | 486 | mapUnionFV injectiveVarsOfBinder dropped_binders | ^^^^^^^^^^^^^^^^^^^^^ utils/haddock/ghc.mk:20: recipe for target 'utils/haddock/dist/build/Haddock/Convert.dyn_o' failed make[1]: *** [utils/haddock/dist/build/Haddock/Convert.dyn_o] Error 1 make[1]: *** Waiting for unfinished jobs.... Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 23:27:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 23:27:13 -0000 Subject: [GHC] #14525: Backpack doesn't work with CPP In-Reply-To: <045.32abb777bece6efc430ddbb385cddc79@haskell.org> References: <045.32abb777bece6efc430ddbb385cddc79@haskell.org> Message-ID: <060.c0fe4f8f8c48153f5b8c0ba4e387b908@haskell.org> #14525: Backpack doesn't work with CPP -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.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): Phab:D4234 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 23:35:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 23:35:38 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.5746cd74d4b1ece4354fe49449b7523c@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): You should be able to fix that Haddock compilation error with this patch: {{{#!diff diff --git a/haddock-api/src/Haddock/Convert.hs b/haddock- api/src/Haddock/Convert.hs index bf6fbab..9f7b15d 100644 --- a/haddock-api/src/Haddock/Convert.hs +++ b/haddock-api/src/Haddock/Convert.hs @@ -512,8 +512,7 @@ synifyType _ (TyConApp tc tys) = splitAtList tys binders result_kind = mkTyConKind remaining_binders res_kind result_vars = tyCoVarsOfType result_kind - dropped_vars = fvVarSet $ - mapUnionFV injectiveVarsOfBinder dropped_binders + dropped_vars = mapUnionVarSet injectiveVarsOfBinder dropped_binders in not (subVarSet result_vars dropped_vars) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 14 23:39:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 14 Jul 2018 23:39:08 -0000 Subject: [GHC] #15380: Infinite typechecker loop in GHC 8.6 Message-ID: <050.ceee7eb83a4946e532604b8e627271f4@haskell.org> #15380: Infinite typechecker loop in GHC 8.6 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program loops infinitely during typechecking with GHC 8.6.1 and HEAD: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind class Generic a where type Rep a :: Type class PGeneric a where type To a (x :: Rep a) :: a type family MDefault (x :: a) :: a where MDefault x = To (M x) class C a where type M (x :: a) :: a type M (x :: a) = MDefault x }}} In GHC 8.4.3, however this fails with a proper error: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:15:16: error: • Occurs check: cannot construct the infinite kind: a ~ Rep (M x) -> M x • In the type ‘To (M x)’ In the type family declaration for ‘MDefault’ • Type variable kinds: x :: a | 15 | MDefault x = To (M x) | ^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 00:03:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 00:03:00 -0000 Subject: [GHC] #15136: High CPU when asynchronous exception and unblocking retry on TVar raced In-Reply-To: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> References: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> Message-ID: <062.de98b61c5b22f52843fe4725ca955e58@haskell.org> #15136: High CPU when asynchronous exception and unblocking retry on TVar raced -------------------------------------+------------------------------------- Reporter: nshimaza | Owner: osa1 Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4956 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"502640c90c3d0fbb6c46257be14fdc7e3c694c6c/ghc" 502640c9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="502640c90c3d0fbb6c46257be14fdc7e3c694c6c" Optimise wakeups for STM Avoids repeated wakeup messages being sent when a TVar is written to multiple times. See comments for details. Test Plan: * Test from #15136 (will be added to stm shortly) * existing stm tests Reviewers: bgamari, osa1, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15136 Differential Revision: https://phabricator.haskell.org/D4961 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 00:34:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 00:34:39 -0000 Subject: [GHC] #15380: Infinite typechecker loop in GHC 8.6 In-Reply-To: <050.ceee7eb83a4946e532604b8e627271f4@haskell.org> References: <050.ceee7eb83a4946e532604b8e627271f4@haskell.org> Message-ID: <065.66fd63b0b629a8a6cfc2a2e49cfd5504@haskell.org> #15380: Infinite typechecker loop in GHC 8.6 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies 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 RyanGlScott): * cc: goldfire (added) * version: 8.4.3 => 8.5 Comment: This regression was introduced in commit faec8d358985e5d0bf363bd96f23fe76c9e281f7 (`Track type variable scope more carefully.`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 00:59:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 00:59:25 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.824fb902d141ba9520aa8eb67dfd9e8c@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): vdukhovni, I'm having a bit of trouble applying the patch you attached. Could you either rebase against `master` and upload a new patch or push a branch somewhere? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 01:27:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 01:27:43 -0000 Subject: [GHC] #15372: GHCi leaks in DEBUG mode In-Reply-To: <047.2ac34cbfa4c72468332be193667a285f@haskell.org> References: <047.2ac34cbfa4c72468332be193667a285f@haskell.org> Message-ID: <062.8b30d51974c6183aed33a27e8735fb0f@haskell.org> #15372: GHCi leaks in DEBUG mode -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15246 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"6d55e36f6d4b71402b3a27cd466d237034d3a5b8/ghc" 6d55e36f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6d55e36f6d4b71402b3a27cd466d237034d3a5b8" Disable -fghci-leak-check in DEBUG mode The DEBUG compiler's GHCi still leaks. This commit suppresses testsuite failures due to this leak. See #15372. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 01:27:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 01:27:43 -0000 Subject: [GHC] #15374: Testsuite: compile_timeout_multiplier is fragile In-Reply-To: <047.7876c280adf4842052a04dcffaef0078@haskell.org> References: <047.7876c280adf4842052a04dcffaef0078@haskell.org> Message-ID: <062.6fcaa64ee7f999133e0cf90b15c73b56@haskell.org> #15374: Testsuite: compile_timeout_multiplier is fragile -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"8a70ccbb552191e1972f3c5d7fce839176c4c0e3/ghc" 8a70ccbb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8a70ccbb552191e1972f3c5d7fce839176c4c0e3" Reclassify some performance tests There were some performance tests not classified by compiler_num_stats_field, causing erroneous failures when testing a DEBUG compiler. This fixes that oversight, addressing #15374. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 01:34:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 01:34:35 -0000 Subject: [GHC] #15374: Testsuite: compile_timeout_multiplier is fragile In-Reply-To: <047.7876c280adf4842052a04dcffaef0078@haskell.org> References: <047.7876c280adf4842052a04dcffaef0078@haskell.org> Message-ID: <062.f13a242983a8334aa904e6294d194ce3@haskell.org> #15374: Testsuite: compile_timeout_multiplier is fragile -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: Hearing no objections, I just went ahead and did it. I don't think this is particularly helpful to merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 01:35:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 01:35:15 -0000 Subject: [GHC] #15372: GHCi leaks in DEBUG mode In-Reply-To: <047.2ac34cbfa4c72468332be193667a285f@haskell.org> References: <047.2ac34cbfa4c72468332be193667a285f@haskell.org> Message-ID: <062.b7b9ba09fa0a18f10ce96fd9c20282c3@haskell.org> #15372: GHCi leaks in DEBUG mode -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15246 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): NB: comment:4 does not fix this bug, solving only issue (1) from the OP. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 01:39:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 01:39:45 -0000 Subject: [GHC] #15381: Write documentation for iserv-proxy Message-ID: <046.67d927d07f2686022ddcec4bb1097911@haskell.org> #15381: Write documentation for iserv-proxy -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We merged `iserv-proxy` but it doesn't yet have users guide documentation. We should fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 07:54:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 07:54:40 -0000 Subject: [GHC] #15359: Quantified constraints do not work with equality constraints In-Reply-To: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> References: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> Message-ID: <062.5e50a5dc1cc0ee50d096b43d690e726d@haskell.org> #15359: Quantified constraints do not work with equality constraints -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:11 goldfire]: >> ... I neither know a good pithy way of explaining that I can't see even a convoluted explanation: it seems an arbitrary restriction. (Perhaps Simon is just being conservative with a new feature?) 1. Why is `~` banned, but not `Coercible` (or a user-written coercion class)? 2. In the 'FDs through CHRs' paper all of the improvement rules are in the form of a constraint implying an equality. 3. Richard's suggestion of a Closed Type Family (in a `~` superclass constraint -- which is a standard idiom) just is exactly what seems to be banned: {{{ class (F a b ~ c) -- there's the Eq constraint => D a b c where ... type family F a b where F blah1 blah2 = blah3 -- take '=' from left to right, so it's an implication F a (T a b') = (... b' ...) -- repeated tyvars on lhs is an '~' test -- local-scoped tyvar b' is quantified }}} "just is"? Well, no: I've had to chop up the logic and find a name for it and spread it round the program text. > Previously, Simon was worried that the equality constraints would always be redundant. Hmm. Maybe redundant in the sense if you draw all the bits back together, the type equalities are entailed. But in the general case (such as my `And` example) that needs closed-world reasoning: closed Kinds; closed sets of instances. Which I don't expect GHC to even try. > I think that's still true in your examples, but with a key twist: the equality constraints can be used for improvement during type checking. That may indeed be correct. > There's a risk of non-termination. But GHC entertains that already with `UndecidableInstances` and/or `UndecidableSuperClasses`. I think we could work up [https://github.com/ghc-proposals/ghc-proposals/pull/114 a proposal for that]. In the language of the 'FDs through CHRs' paper, we must make sure all quantification is 'range restricted'. > As a practical matter though, I can't imagine how to implement them. And, given the fact that we have many ways of expressing these ideas already, without quantified equality constraints, (for example, your `ElimElem` could be implemented as a closed type family), I'm not yet motivated to start thinking about how to write a solver than can deal with these. Isn't "many ways" actually a problem here? Too many similar-but-subtly- different ways. And specifically Type Families are out of favour [https://github.com/ghc-proposals/ghc- proposals/pull/114#issuecomment-372124549 for certain purposes] (see re 'lens example' -- chop up the program logic, repeat it around the program, find a name for it; I think that also swayed the decision on records/`HasField` class to use FunDeps rather than TFs). Simon's (quite rightly) always looking for underpinning rationalisations that "allows us to simplify the language by (say) deprecating or removing features". Haskell has had a problem since at least 1997; didn't get fixed in H98; didn't get fixed in H2010; unlikely to get resolved for H2020: that we'd like to 'bless' MPTCs; but then we'd need to bless FunDeps and/or Type Families; but then we'd have to deal with overlaps/Closed TFs. All of them have an underlying type improvement logic, which is a 'local' implication constraint with equalities. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 09:18:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 09:18:32 -0000 Subject: [GHC] #15359: Quantified constraints do not work with equality constraints In-Reply-To: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> References: <047.6c20373526398fd5725ca3ce9d7c3b21@haskell.org> Message-ID: <062.eec02e26b6b66448d745e6a0f9f0c819@haskell.org> #15359: Quantified constraints do not work with equality constraints -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:11 goldfire]: > the last two instance always overlap looking only at the instance heads. So I think you'd still need `{-# OVERLAPPING #-}`. > Yeah kinda; but no. GHC's overlap is a marvel of engineering compromise. So you're not squinting at the right angle. * The two instances are in no substitution order, so `OVERLAPPING`/`OVERLAPPABLE` would be rejected. * "It is fine for there to be a ''potential'' of overlap ...; an error is only reported if a particular constraint matches more than one." [Users guide] So I'm relying on type improvement to apply before instance selection: then GHC should never be looking for a Wanted that matches more than one instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 13:10:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 13:10:00 -0000 Subject: [GHC] #15382: heapprof001 segfaults in prof_hc_hb way on i386 Message-ID: <046.129cecd292baf096415325165f8ceabf@haskell.org> #15382: heapprof001 segfaults in prof_hc_hb way on i386 --------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------- I am seeing the `heapprof001` testcase segmentation fault in the `prof_hc_hb` testsuite way on i386. For instance, https://circleci.com/gh/ghc/ghc/7104. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 13:11:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 13:11:24 -0000 Subject: [GHC] #15382: heapprof001 segfaults in prof_hc_hb way on i386 In-Reply-To: <046.129cecd292baf096415325165f8ceabf@haskell.org> References: <046.129cecd292baf096415325165f8ceabf@haskell.org> Message-ID: <061.f69bd7c4bf35a3e31fb97035b421812e@haskell.org> #15382: heapprof001 segfaults in prof_hc_hb way on i386 -------------------------------------+------------------------------ Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Description changed by bgamari: Old description: > I am seeing the `heapprof001` testcase segmentation fault in the > `prof_hc_hb` testsuite way on i386. For instance, > https://circleci.com/gh/ghc/ghc/7104. New description: I am seeing the `heapprof001` testcase segmentation fault in the `prof_hc_hb` testsuite way on i386. For instance, https://circleci.com/gh/ghc/ghc/7104: {{{ Wrong exit code for heapprof001(prof_hc_hb)(expected 0 , actual 139 ) Stdout ( heapprof001 ): a <= a <= a <= a <= a <= a <= a <= Stderr ( heapprof001 ): Segmentation fault *** unexpected failure for heapprof001(prof_hc_hb) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 13:12:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 13:12:38 -0000 Subject: [GHC] #15383: T3171 doesn't terminate with Interrupted message on Darwin Message-ID: <046.1d648bf17453b21fb35b42043bd02c26@haskell.org> #15383: T3171 doesn't terminate with Interrupted message on Darwin -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I am seeing `T3171` fail with incorrect stderr output on Darwin (e.g. https://circleci.com/gh/ghc/ghc/7106): {{{ Actual stdout output differs from expected: --- ./ghci/should_run/T3171.run/T3171.stdout.normalised 2018-07-14 21:24:25.000000000 -0700 +++ ./ghci/should_run/T3171.run/T3171.run.stdout.normalised 2018-07-14 21:24:25.000000000 -0700 @@ -1 +0,0 @@ -Interrupted. *** unexpected failure for T3171(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 13:18:26 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 13:18:26 -0000 Subject: [GHC] #15383: T3171 doesn't terminate with Interrupted message on Darwin In-Reply-To: <046.1d648bf17453b21fb35b42043bd02c26@haskell.org> References: <046.1d648bf17453b21fb35b42043bd02c26@haskell.org> Message-ID: <061.14028a45831330171d4f1bb0f4a35fdd@haskell.org> #15383: T3171 doesn't terminate with Interrupted message on Darwin ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | 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: | ---------------------------------+-------------------------------------- Changes (by bgamari): * os: Unknown/Multiple => MacOS X * architecture: Unknown/Multiple => x86_64 (amd64) Comment: Unfortunately it looks like this test is just fragile on Darwin; the same commit failed once but passed in another CircleCI build. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 14:17:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 14:17:25 -0000 Subject: [GHC] #15364: Replace the atomicModifyMutVar# primop In-Reply-To: <045.aa8fbba8dcbd166d60f806e361779d6c@haskell.org> References: <045.aa8fbba8dcbd166d60f806e361779d6c@haskell.org> Message-ID: <060.df06bc9b8572e923d4342862721478ea@haskell.org> #15364: Replace the atomicModifyMutVar# primop -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4884 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"af9b744bbf1c39078e561b19edd3c5234b361b27/ghc" af9b744b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="af9b744bbf1c39078e561b19edd3c5234b361b27" Replace atomicModifyMutVar# Reviewers: simonmar, hvr, bgamari, erikd, fryguybob, rrnewton Reviewed By: simonmar Subscribers: fryguybob, rwbarton, thomie, carter GHC Trac Issues: #15364 Differential Revision: https://phabricator.haskell.org/D4884 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 14:37:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 14:37:03 -0000 Subject: [GHC] #15384: Every implication should bump the TcLevel exactly once Message-ID: <047.d56843a5a9456b5500d56ec561e931f3@haskell.org> #15384: Every implication should bump the TcLevel exactly once -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Simon recently added an assertion that every implication bumps the TcLevel exactly once. However, this turns out not to be true, and thus caused quite a few failures in a `DEBUG` compiler. I commented the check out, but we really should investigate and fix any deviations from this plan. Here is the suspect code in TcSimplify: {{{ -- Though sensible, this check causes lots of testsuite failures. It is -- remaining commented out for now. {- check_tc_level = do { cur_lvl <- TcS.getTcLevel ; MASSERT2( tclvl == pushTcLevel cur_lvl , text "Cur lvl =" <+> ppr cur_lvl $$ text "Imp lvl =" <+> ppr tclvl ) } -} }}} The goal is to uncomment this region without introducing failures. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 15:01:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 15:01:19 -0000 Subject: [GHC] #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards Message-ID: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple PatternMatchWarnings | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Bug where import Data.Kind data family Sing :: forall k. k -> Type newtype Id a = MkId a data So :: Bool -> Type where Oh :: So True data instance Sing :: Bool -> Type where SFalse :: Sing False STrue :: Sing True data instance Sing :: Ordering -> Type where SLT :: Sing LT SEQ :: Sing EQ SGT :: Sing GT data instance Sing :: forall a. Id a -> Type where SMkId :: Sing x -> Sing (MkId x) class POrd a where type (x :: a) `Compare` (y :: a) :: Ordering class SOrd a where sCompare :: forall (x :: a) (y :: a). Sing x -> Sing y -> Sing (x `Compare` y) type family (x :: a) <= (y :: a) :: Bool where x <= y = LeqCase (x `Compare` y) type family LeqCase (o :: Ordering) :: Bool where LeqCase LT = True LeqCase EQ = True LeqCase GT = False (%<=) :: forall a (x :: a) (y :: a). SOrd a => Sing x -> Sing y -> Sing (x <= y) sx %<= sy = case sx `sCompare` sy of SLT -> STrue SEQ -> STrue SGT -> SFalse class (POrd a, SOrd a) => VOrd a where leqReflexive :: forall (x :: a). Sing x -> So (x <= x) instance POrd a => POrd (Id a) where type MkId x `Compare` MkId y = x `Compare` y instance SOrd a => SOrd (Id a) where SMkId sx `sCompare` SMkId sy = sx `sCompare` sy ----- instance VOrd a => VOrd (Id a) where leqReflexive (SMkId sa) | Oh <- leqReflexive sa = case sa `sCompare` sa of SLT -> Oh SEQ -> Oh -- SGT -> undefined }}} What exactly this code does isn't terribly important. The important bit is that last instance (`VOrd (Id a)`). That //should// be total, but GHC disagrees: {{{ GHCi, version 8.6.0.20180627: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:63:7: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: SGT | 63 | = case sa `sCompare` sa of | ^^^^^^^^^^^^^^^^^^^^^^^^... }}} As evidence that this warning is bogus, if you uncomment the last line, then GHC correctly observes that that line is inaccessible: {{{ GHCi, version 8.6.0.20180627: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:66:9: warning: [-Winaccessible-code] • Couldn't match type ‘'True’ with ‘'False’ Inaccessible code in a pattern with constructor: SGT :: Sing 'GT, in a case alternative • In the pattern: SGT In a case alternative: SGT -> undefined In the expression: case sa `sCompare` sa of SLT -> Oh SEQ -> Oh SGT -> undefined | 66 | SGT -> undefined | ^^^ }}} Clearly, something is afoot in the coverage checker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 15:11:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 15:11:36 -0000 Subject: [GHC] #13812: deriveConstants: no objdump program given (OpenBSD) In-Reply-To: <045.636d394562a9f1cf977240b7a6005dbd@haskell.org> References: <045.636d394562a9f1cf977240b7a6005dbd@haskell.org> Message-ID: <060.64866a9bf6f005b0b1ac4167ccf30997@haskell.org> #13812: deriveConstants: no objdump program given (OpenBSD) -------------------------------------+------------------------------------- Reporter: roland | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Build System | Version: Resolution: fixed | Keywords: Operating System: OpenBSD | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #9549 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 16:45:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 16:45:49 -0000 Subject: [GHC] #15386: TTG typo: XFieldOcc should be XCFieldOcc Message-ID: <044.ce27d4db3b23b0319278af1be4448a3c@haskell.org> #15386: TTG typo: XFieldOcc should be XCFieldOcc -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the following {{{#!hs data FieldOcc pass = FieldOcc { extFieldOcc :: XFieldOcc pass , rdrNameFieldOcc :: Located RdrName -- ^ See Note [Located RdrNames] in HsExpr } | XFieldOcc (XXFieldOcc pass) }}} we are using `XFieldOcc` for both the `extFieldOcc` type and the extra constructor. The first one should be `XCFieldOcc`/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 16:46:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 16:46:09 -0000 Subject: [GHC] #15386: TTG typo: XFieldOcc should be XCFieldOcc In-Reply-To: <044.ce27d4db3b23b0319278af1be4448a3c@haskell.org> References: <044.ce27d4db3b23b0319278af1be4448a3c@haskell.org> Message-ID: <059.a04ae8715698a6854f37e5f0640ee17e@haskell.org> #15386: TTG typo: XFieldOcc should be XCFieldOcc -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * owner: (none) => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 17:38:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 17:38:00 -0000 Subject: [GHC] #15386: TTG typo: XFieldOcc should be XCFieldOcc In-Reply-To: <044.ce27d4db3b23b0319278af1be4448a3c@haskell.org> References: <044.ce27d4db3b23b0319278af1be4448a3c@haskell.org> Message-ID: <059.2694e673d4b942a2da62d53ac2e88a32@haskell.org> #15386: TTG typo: XFieldOcc should be XCFieldOcc -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"926954196f9ffd7b89cba53061b39ef996e1650c/ghc" 9269541/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="926954196f9ffd7b89cba53061b39ef996e1650c" TTG typo: XFieldOcc should be XCFieldOcc In the following data FieldOcc pass = FieldOcc { extFieldOcc :: XFieldOcc pass , rdrNameFieldOcc :: Located RdrName -- ^ See Note [Located RdrNames] in HsExpr } | XFieldOcc (XXFieldOcc pass) we are using XFieldOcc for both the extFieldOcc type and the extra constructor. The first one should be XCFieldOcc Updates haddock submodule closes #15386 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 17:38:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 17:38:07 -0000 Subject: [GHC] #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards In-Reply-To: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> References: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> Message-ID: <065.b3d46216d5f52d0c7912807253e09da0@haskell.org> #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Actually, this is even simpler than I made it out to be: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Bug where import Data.Type.Equality data T a where TInt :: T Int TBool :: T Bool f :: a :~: Int -> T a -> () f eq t | Refl <- eq = case t of TInt -> () -- TBool -> () }}} {{{ GHCi, version 8.6.0.20180627: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug3.hs, interpreted ) Bug3.hs:15:5: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: TBool | 15 | = case t of | ^^^^^^^^^... }}} Stunning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 17:40:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 17:40:43 -0000 Subject: [GHC] #15386: TTG typo: XFieldOcc should be XCFieldOcc In-Reply-To: <044.ce27d4db3b23b0319278af1be4448a3c@haskell.org> References: <044.ce27d4db3b23b0319278af1be4448a3c@haskell.org> Message-ID: <059.f79106b2d329d6f817a6c51f4ccbad3b@haskell.org> #15386: TTG typo: XFieldOcc should be XCFieldOcc -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => merge Comment: For GHC 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 18:30:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 18:30:47 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.f4e1b782875343511d10f111c6358d8b@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This all looks like it's going swimmingly. Let me know if I need to intervene. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 19:25:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 19:25:40 -0000 Subject: [GHC] #15387: Unable to set testsuite verbosity to zero from command line Message-ID: <045.1ef98c4634b785a6312d5e3fc14d2d67@haskell.org> #15387: Unable to set testsuite verbosity to zero from command line -------------------------------------+------------------------------------- Reporter: lantti | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Test Suite | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Setting testsuite verbosity to zero from commandline using 'make test VERBOSE=0' does not work because runtests.py confuses the value 0 with value None. Solution: check explicitly for None instead of any value considered equal to False. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 19:26:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 19:26:01 -0000 Subject: [GHC] #15387: Unable to set testsuite verbosity to zero from command line In-Reply-To: <045.1ef98c4634b785a6312d5e3fc14d2d67@haskell.org> References: <045.1ef98c4634b785a6312d5e3fc14d2d67@haskell.org> Message-ID: <060.0d9272662e1d8a6e85aac52447f24ea4@haskell.org> #15387: Unable to set testsuite verbosity to zero from command line -------------------------------------+------------------------------------- Reporter: lantti | Owner: lantti Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Test Suite | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lantti): * owner: (none) => lantti -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 19:26:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 19:26:29 -0000 Subject: [GHC] #15388: GHC reports missing INLINABLE pragmas in vector and ghc-prim Message-ID: <047.d222f3350c1cc34659805b35239cc71c@haskell.org> #15388: GHC reports missing INLINABLE pragmas in vector and ghc-prim -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiling a program with GHC 8.4.3, vector 0.12.0.1 (with a dependency on primitive 0.6.4.0) and `-Weverything`, I get several warnings that `INLINABLE` pragmas should be added to the vector and ghc- prim packages. It would be nicer if these warnings didn't happen, even with `-Weverything`. Also, perhaps there are optimization opportunities that are lost. A somewhat reduced example (can be reduced further by removing the function definitions and unused imports that creates): {{{#!hs lineno=1 {-# OPTIONS_GHC -Wall-missed-specialisations #-} {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} module Warnings2 where import GHC.Base (liftM) import qualified Data.Vector.Generic.Base as G (Vector, basicUnsafeFreeze, basicUnsafeThaw, basicLength, basicUnsafeSlice, basicUnsafeIndexM, basicUnsafeCopy, elemseq) import qualified Data.Vector.Generic.Mutable.Base as GM (MVector, basicLength, basicUnsafeSlice, basicOverlaps, basicUnsafeNew, basicInitialize, basicUnsafeReplicate, basicUnsafeRead, basicUnsafeWrite, basicClear, basicSet, basicUnsafeCopy, basicUnsafeMove, basicUnsafeGrow) import qualified Data.Vector.Unboxed as U (Unbox, Vector) import qualified Data.Vector.Unboxed.Mutable as U (MVector) newtype T = T () deriving (Show, Eq, Ord) newtype C = C (T, U.Vector T) deriving (Show, Eq, Ord) instance U.Unbox T newtype instance U.MVector s T = MV_T (U.MVector s ()) instance GM.MVector U.MVector T where basicLength (MV_T mv) = GM.basicLength mv basicUnsafeSlice i l (MV_T mv) = MV_T (GM.basicUnsafeSlice i l mv) basicOverlaps (MV_T mv1) (MV_T mv2) = GM.basicOverlaps mv1 mv2 basicUnsafeNew l = MV_T `liftM` GM.basicUnsafeNew l basicInitialize (MV_T mv) = GM.basicInitialize mv basicUnsafeReplicate l _ = MV_T `liftM` GM.basicUnsafeReplicate l () basicUnsafeRead (MV_T mv) i = const (T ()) `liftM` GM.basicUnsafeRead mv i basicUnsafeWrite (MV_T mv) i _ = GM.basicUnsafeWrite mv i () basicClear (MV_T mv) = GM.basicClear mv basicSet (MV_T mv) x = GM.basicSet mv () basicUnsafeCopy (MV_T mv1) (MV_T mv2) = GM.basicUnsafeCopy mv1 mv2 basicUnsafeMove (MV_T mv1) (MV_T mv2) = GM.basicUnsafeMove mv1 mv2 basicUnsafeGrow (MV_T mv) l = MV_T `liftM` GM.basicUnsafeGrow mv l newtype instance U.Vector T = V_T (U.Vector ()) instance G.Vector U.Vector T where basicUnsafeFreeze (MV_T mv) = V_T `liftM` G.basicUnsafeFreeze mv basicUnsafeThaw (V_T v) = MV_T `liftM` G.basicUnsafeThaw v basicLength (V_T v) = G.basicLength v basicUnsafeSlice i l (V_T v) = V_T (G.basicUnsafeSlice i l v) basicUnsafeIndexM (V_T v) i = const (T ()) `liftM` G.basicUnsafeIndexM v i basicUnsafeCopy (MV_T mv) (V_T v) = G.basicUnsafeCopy mv v elemseq (V_T v) _ = G.elemseq v () }}} The warnings: {{{#!default lineno=1 marks=16,31,46 src/Warnings2.hs: warning: Could not specialise imported function ‘Data.Vector.Unboxed.$w$cshowsPrec’ when specialising ‘Data.Vector.Unboxed.$fShowVector_$cshowsPrec’ when specialising ‘Data.Vector.Unboxed.$fShowVector’ Probable fix: add INLINABLE pragma on ‘Data.Vector.Unboxed.$w$cshowsPrec’ src/Warnings2.hs: warning: Could not specialise imported function ‘Data.Vector.Unboxed.$fShowVector_$cshow’ when specialising ‘Data.Vector.Unboxed.$fShowVector’ Probable fix: add INLINABLE pragma on ‘Data.Vector.Unboxed.$fShowVector_$cshow’ src/Warnings2.hs: warning: Could not specialise imported function ‘Data.Vector.Unboxed.$fShowVector_$cshowList’ when specialising ‘Data.Vector.Unboxed.$fShowVector’ Probable fix: add INLINABLE pragma on ‘Data.Vector.Unboxed.$fShowVector_$cshowList’ src/Warnings2.hs: warning: Could not specialise imported function ‘ghc- prim-0.5.2.0:GHC.Classes.$w$c==’ when specialising ‘ghc-prim-0.5.2.0:GHC.Classes.$fEq(,)_$c==’ Probable fix: add INLINABLE pragma on ‘ghc- prim-0.5.2.0:GHC.Classes.$w$c==’ src/Warnings2.hs: warning: Could not specialise imported function ‘Data.Vector.Unboxed.$fOrdVector_$cmax’ when specialising ‘Data.Vector.Unboxed.$fOrdVector’ Probable fix: add INLINABLE pragma on ‘Data.Vector.Unboxed.$fOrdVector_$cmax’ src/Warnings2.hs: warning: Could not specialise imported function ‘Data.Vector.Unboxed.$fOrdVector_$cmin’ when specialising ‘Data.Vector.Unboxed.$fOrdVector’ Probable fix: add INLINABLE pragma on ‘Data.Vector.Unboxed.$fOrdVector_$cmin’ src/Warnings2.hs: warning: Could not specialise imported function ‘ghc- prim-0.5.2.0:GHC.Classes.$w$c>=’ when specialising ‘ghc-prim-0.5.2.0:GHC.Classes.$fOrd(,)_$c>=’ Probable fix: add INLINABLE pragma on ‘ghc- prim-0.5.2.0:GHC.Classes.$w$c>=’ src/Warnings2.hs: warning: Could not specialise imported function ‘ghc- prim-0.5.2.0:GHC.Classes.$w$c<’ when specialising ‘ghc-prim-0.5.2.0:GHC.Classes.$fOrd(,)_$c<’ Probable fix: add INLINABLE pragma on ‘ghc- prim-0.5.2.0:GHC.Classes.$w$c<’ src/Warnings2.hs: warning: Could not specialise imported function ‘ghc- prim-0.5.2.0:GHC.Classes.$w$c<=’ when specialising ‘ghc-prim-0.5.2.0:GHC.Classes.$fOrd(,)_$c<=’ Probable fix: add INLINABLE pragma on ‘ghc- prim-0.5.2.0:GHC.Classes.$w$c<=’ src/Warnings2.hs: warning: Could not specialise imported function ‘ghc- prim-0.5.2.0:GHC.Classes.$w$ccompare’ when specialising ‘ghc-prim-0.5.2.0:GHC.Classes.$fOrd(,)_$ccompare’ Probable fix: add INLINABLE pragma on ‘ghc- prim-0.5.2.0:GHC.Classes.$w$ccompare’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 19:27:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 19:27:08 -0000 Subject: [GHC] #15388: GHC reports missing INLINABLE pragmas in vector and ghc-prim In-Reply-To: <047.d222f3350c1cc34659805b35239cc71c@haskell.org> References: <047.d222f3350c1cc34659805b35239cc71c@haskell.org> Message-ID: <062.3662ffec105cdfb3d4a84767b6601c9e@haskell.org> #15388: GHC reports missing INLINABLE pragmas in vector and ghc-prim -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by ChaiTRex: Old description: > When compiling a program with GHC 8.4.3, vector 0.12.0.1 (with a > dependency on primitive 0.6.4.0) and `-Weverything`, I get several > warnings that `INLINABLE` pragmas should be added to the vector and ghc- > prim packages. > > It would be nicer if these warnings didn't happen, even with > `-Weverything`. Also, perhaps there are optimization opportunities that > are lost. > > A somewhat reduced example (can be reduced further by removing the > function definitions and unused imports that creates): > > {{{#!hs lineno=1 > {-# OPTIONS_GHC -Wall-missed-specialisations #-} > {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} > > module Warnings2 where > > import GHC.Base (liftM) > import qualified Data.Vector.Generic.Base as G (Vector, > basicUnsafeFreeze, > basicUnsafeThaw, basicLength, basicUnsafeSlice, basicUnsafeIndexM, > basicUnsafeCopy, elemseq) > import qualified Data.Vector.Generic.Mutable.Base as GM (MVector, > basicLength, > basicUnsafeSlice, basicOverlaps, basicUnsafeNew, basicInitialize, > basicUnsafeReplicate, basicUnsafeRead, basicUnsafeWrite, basicClear, > basicSet, > basicUnsafeCopy, basicUnsafeMove, basicUnsafeGrow) > import qualified Data.Vector.Unboxed as U (Unbox, Vector) > import qualified Data.Vector.Unboxed.Mutable as U (MVector) > > newtype T = T () deriving (Show, Eq, Ord) > newtype C = C (T, U.Vector T) deriving (Show, Eq, Ord) > > instance U.Unbox T > > newtype instance U.MVector s T = MV_T (U.MVector s ()) > instance GM.MVector U.MVector T where > basicLength (MV_T mv) = GM.basicLength mv > basicUnsafeSlice i l (MV_T mv) = MV_T (GM.basicUnsafeSlice i l mv) > basicOverlaps (MV_T mv1) (MV_T mv2) = GM.basicOverlaps mv1 mv2 > basicUnsafeNew l = MV_T `liftM` GM.basicUnsafeNew l > basicInitialize (MV_T mv) = GM.basicInitialize mv > basicUnsafeReplicate l _ = MV_T `liftM` GM.basicUnsafeReplicate l () > basicUnsafeRead (MV_T mv) i = const (T ()) `liftM` GM.basicUnsafeRead > mv i > basicUnsafeWrite (MV_T mv) i _ = GM.basicUnsafeWrite mv i () > basicClear (MV_T mv) = GM.basicClear mv > basicSet (MV_T mv) x = GM.basicSet mv () > basicUnsafeCopy (MV_T mv1) (MV_T mv2) = GM.basicUnsafeCopy mv1 mv2 > basicUnsafeMove (MV_T mv1) (MV_T mv2) = GM.basicUnsafeMove mv1 mv2 > basicUnsafeGrow (MV_T mv) l = MV_T `liftM` GM.basicUnsafeGrow mv l > > newtype instance U.Vector T = V_T (U.Vector ()) > instance G.Vector U.Vector T where > basicUnsafeFreeze (MV_T mv) = V_T `liftM` G.basicUnsafeFreeze mv > basicUnsafeThaw (V_T v) = MV_T `liftM` G.basicUnsafeThaw v > basicLength (V_T v) = G.basicLength v > basicUnsafeSlice i l (V_T v) = V_T (G.basicUnsafeSlice i l v) > basicUnsafeIndexM (V_T v) i = const (T ()) `liftM` G.basicUnsafeIndexM > v i > basicUnsafeCopy (MV_T mv) (V_T v) = G.basicUnsafeCopy mv v > elemseq (V_T v) _ = G.elemseq v () > }}} > > The warnings: > > {{{#!default lineno=1 marks=16,31,46 > src/Warnings2.hs: warning: > Could not specialise imported function > ‘Data.Vector.Unboxed.$w$cshowsPrec’ > when specialising ‘Data.Vector.Unboxed.$fShowVector_$cshowsPrec’ > when specialising ‘Data.Vector.Unboxed.$fShowVector’ > Probable fix: add INLINABLE pragma on > ‘Data.Vector.Unboxed.$w$cshowsPrec’ > > src/Warnings2.hs: warning: > Could not specialise imported function > ‘Data.Vector.Unboxed.$fShowVector_$cshow’ > when specialising ‘Data.Vector.Unboxed.$fShowVector’ > Probable fix: add INLINABLE pragma on > ‘Data.Vector.Unboxed.$fShowVector_$cshow’ > > src/Warnings2.hs: warning: > Could not specialise imported function > ‘Data.Vector.Unboxed.$fShowVector_$cshowList’ > when specialising ‘Data.Vector.Unboxed.$fShowVector’ > Probable fix: add INLINABLE pragma on > ‘Data.Vector.Unboxed.$fShowVector_$cshowList’ > > src/Warnings2.hs: warning: > Could not specialise imported function ‘ghc- > prim-0.5.2.0:GHC.Classes.$w$c==’ > when specialising ‘ghc-prim-0.5.2.0:GHC.Classes.$fEq(,)_$c==’ > Probable fix: add INLINABLE pragma on ‘ghc- > prim-0.5.2.0:GHC.Classes.$w$c==’ > > src/Warnings2.hs: warning: > Could not specialise imported function > ‘Data.Vector.Unboxed.$fOrdVector_$cmax’ > when specialising ‘Data.Vector.Unboxed.$fOrdVector’ > Probable fix: add INLINABLE pragma on > ‘Data.Vector.Unboxed.$fOrdVector_$cmax’ > > src/Warnings2.hs: warning: > Could not specialise imported function > ‘Data.Vector.Unboxed.$fOrdVector_$cmin’ > when specialising ‘Data.Vector.Unboxed.$fOrdVector’ > Probable fix: add INLINABLE pragma on > ‘Data.Vector.Unboxed.$fOrdVector_$cmin’ > > src/Warnings2.hs: warning: > Could not specialise imported function ‘ghc- > prim-0.5.2.0:GHC.Classes.$w$c>=’ > when specialising ‘ghc-prim-0.5.2.0:GHC.Classes.$fOrd(,)_$c>=’ > Probable fix: add INLINABLE pragma on ‘ghc- > prim-0.5.2.0:GHC.Classes.$w$c>=’ > > src/Warnings2.hs: warning: > Could not specialise imported function ‘ghc- > prim-0.5.2.0:GHC.Classes.$w$c<’ > when specialising ‘ghc-prim-0.5.2.0:GHC.Classes.$fOrd(,)_$c<’ > Probable fix: add INLINABLE pragma on ‘ghc- > prim-0.5.2.0:GHC.Classes.$w$c<’ > > src/Warnings2.hs: warning: > Could not specialise imported function ‘ghc- > prim-0.5.2.0:GHC.Classes.$w$c<=’ > when specialising ‘ghc-prim-0.5.2.0:GHC.Classes.$fOrd(,)_$c<=’ > Probable fix: add INLINABLE pragma on ‘ghc- > prim-0.5.2.0:GHC.Classes.$w$c<=’ > > src/Warnings2.hs: warning: > Could not specialise imported function ‘ghc- > prim-0.5.2.0:GHC.Classes.$w$ccompare’ > when specialising ‘ghc-prim-0.5.2.0:GHC.Classes.$fOrd(,)_$ccompare’ > Probable fix: add INLINABLE pragma on ‘ghc- > prim-0.5.2.0:GHC.Classes.$w$ccompare’ > }}} New description: When compiling a program with GHC 8.4.3, vector 0.12.0.1 (with a dependency on primitive 0.6.4.0) and `-Weverything`, I get several warnings that `INLINABLE` pragmas should be added to the vector and ghc- prim packages. It would be nicer if these warnings didn't happen, even with `-Weverything`. Also, perhaps there are optimization opportunities that are lost. A somewhat reduced example (can be reduced further by removing the function definitions and unused imports that creates): {{{#!hs {-# OPTIONS_GHC -Wall-missed-specialisations #-} {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} module Warnings2 where import GHC.Base (liftM) import qualified Data.Vector.Generic.Base as G (Vector, basicUnsafeFreeze, basicUnsafeThaw, basicLength, basicUnsafeSlice, basicUnsafeIndexM, basicUnsafeCopy, elemseq) import qualified Data.Vector.Generic.Mutable.Base as GM (MVector, basicLength, basicUnsafeSlice, basicOverlaps, basicUnsafeNew, basicInitialize, basicUnsafeReplicate, basicUnsafeRead, basicUnsafeWrite, basicClear, basicSet, basicUnsafeCopy, basicUnsafeMove, basicUnsafeGrow) import qualified Data.Vector.Unboxed as U (Unbox, Vector) import qualified Data.Vector.Unboxed.Mutable as U (MVector) newtype T = T () deriving (Show, Eq, Ord) newtype C = C (T, U.Vector T) deriving (Show, Eq, Ord) instance U.Unbox T newtype instance U.MVector s T = MV_T (U.MVector s ()) instance GM.MVector U.MVector T where basicLength (MV_T mv) = GM.basicLength mv basicUnsafeSlice i l (MV_T mv) = MV_T (GM.basicUnsafeSlice i l mv) basicOverlaps (MV_T mv1) (MV_T mv2) = GM.basicOverlaps mv1 mv2 basicUnsafeNew l = MV_T `liftM` GM.basicUnsafeNew l basicInitialize (MV_T mv) = GM.basicInitialize mv basicUnsafeReplicate l _ = MV_T `liftM` GM.basicUnsafeReplicate l () basicUnsafeRead (MV_T mv) i = const (T ()) `liftM` GM.basicUnsafeRead mv i basicUnsafeWrite (MV_T mv) i _ = GM.basicUnsafeWrite mv i () basicClear (MV_T mv) = GM.basicClear mv basicSet (MV_T mv) x = GM.basicSet mv () basicUnsafeCopy (MV_T mv1) (MV_T mv2) = GM.basicUnsafeCopy mv1 mv2 basicUnsafeMove (MV_T mv1) (MV_T mv2) = GM.basicUnsafeMove mv1 mv2 basicUnsafeGrow (MV_T mv) l = MV_T `liftM` GM.basicUnsafeGrow mv l newtype instance U.Vector T = V_T (U.Vector ()) instance G.Vector U.Vector T where basicUnsafeFreeze (MV_T mv) = V_T `liftM` G.basicUnsafeFreeze mv basicUnsafeThaw (V_T v) = MV_T `liftM` G.basicUnsafeThaw v basicLength (V_T v) = G.basicLength v basicUnsafeSlice i l (V_T v) = V_T (G.basicUnsafeSlice i l v) basicUnsafeIndexM (V_T v) i = const (T ()) `liftM` G.basicUnsafeIndexM v i basicUnsafeCopy (MV_T mv) (V_T v) = G.basicUnsafeCopy mv v elemseq (V_T v) _ = G.elemseq v () }}} The warnings: {{{#!default lineno=1 marks=16,31,46 src/Warnings2.hs: warning: Could not specialise imported function ‘Data.Vector.Unboxed.$w$cshowsPrec’ when specialising ‘Data.Vector.Unboxed.$fShowVector_$cshowsPrec’ when specialising ‘Data.Vector.Unboxed.$fShowVector’ Probable fix: add INLINABLE pragma on ‘Data.Vector.Unboxed.$w$cshowsPrec’ src/Warnings2.hs: warning: Could not specialise imported function ‘Data.Vector.Unboxed.$fShowVector_$cshow’ when specialising ‘Data.Vector.Unboxed.$fShowVector’ Probable fix: add INLINABLE pragma on ‘Data.Vector.Unboxed.$fShowVector_$cshow’ src/Warnings2.hs: warning: Could not specialise imported function ‘Data.Vector.Unboxed.$fShowVector_$cshowList’ when specialising ‘Data.Vector.Unboxed.$fShowVector’ Probable fix: add INLINABLE pragma on ‘Data.Vector.Unboxed.$fShowVector_$cshowList’ src/Warnings2.hs: warning: Could not specialise imported function ‘ghc- prim-0.5.2.0:GHC.Classes.$w$c==’ when specialising ‘ghc-prim-0.5.2.0:GHC.Classes.$fEq(,)_$c==’ Probable fix: add INLINABLE pragma on ‘ghc- prim-0.5.2.0:GHC.Classes.$w$c==’ src/Warnings2.hs: warning: Could not specialise imported function ‘Data.Vector.Unboxed.$fOrdVector_$cmax’ when specialising ‘Data.Vector.Unboxed.$fOrdVector’ Probable fix: add INLINABLE pragma on ‘Data.Vector.Unboxed.$fOrdVector_$cmax’ src/Warnings2.hs: warning: Could not specialise imported function ‘Data.Vector.Unboxed.$fOrdVector_$cmin’ when specialising ‘Data.Vector.Unboxed.$fOrdVector’ Probable fix: add INLINABLE pragma on ‘Data.Vector.Unboxed.$fOrdVector_$cmin’ src/Warnings2.hs: warning: Could not specialise imported function ‘ghc- prim-0.5.2.0:GHC.Classes.$w$c>=’ when specialising ‘ghc-prim-0.5.2.0:GHC.Classes.$fOrd(,)_$c>=’ Probable fix: add INLINABLE pragma on ‘ghc- prim-0.5.2.0:GHC.Classes.$w$c>=’ src/Warnings2.hs: warning: Could not specialise imported function ‘ghc- prim-0.5.2.0:GHC.Classes.$w$c<’ when specialising ‘ghc-prim-0.5.2.0:GHC.Classes.$fOrd(,)_$c<’ Probable fix: add INLINABLE pragma on ‘ghc- prim-0.5.2.0:GHC.Classes.$w$c<’ src/Warnings2.hs: warning: Could not specialise imported function ‘ghc- prim-0.5.2.0:GHC.Classes.$w$c<=’ when specialising ‘ghc-prim-0.5.2.0:GHC.Classes.$fOrd(,)_$c<=’ Probable fix: add INLINABLE pragma on ‘ghc- prim-0.5.2.0:GHC.Classes.$w$c<=’ src/Warnings2.hs: warning: Could not specialise imported function ‘ghc- prim-0.5.2.0:GHC.Classes.$w$ccompare’ when specialising ‘ghc-prim-0.5.2.0:GHC.Classes.$fOrd(,)_$ccompare’ Probable fix: add INLINABLE pragma on ‘ghc- prim-0.5.2.0:GHC.Classes.$w$ccompare’ }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 19:29:26 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 19:29:26 -0000 Subject: [GHC] #15388: GHC reports missing INLINABLE pragmas in vector and ghc-prim In-Reply-To: <047.d222f3350c1cc34659805b35239cc71c@haskell.org> References: <047.d222f3350c1cc34659805b35239cc71c@haskell.org> Message-ID: <062.4f7a1c2347900f1c26ba630f11b30da0@haskell.org> #15388: GHC reports missing INLINABLE pragmas in vector and ghc-prim -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): All warnings are turned on by `-Weverything`. Can you turn off this warning yourself when using the flag? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 19:32:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 19:32:58 -0000 Subject: [GHC] #15388: GHC reports missing INLINABLE pragmas in vector and ghc-prim In-Reply-To: <047.d222f3350c1cc34659805b35239cc71c@haskell.org> References: <047.d222f3350c1cc34659805b35239cc71c@haskell.org> Message-ID: <062.804a47301b0b27434ae8d2f6d5eb6da8@haskell.org> #15388: GHC reports missing INLINABLE pragmas in vector and ghc-prim -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ChaiTRex): Yes, I've done that with `-Weverything -fno-warn-all-missed- specialisations`, but I was just reporting it in case it could be improved further (for example, missed optimization opportunities). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 20:01:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 20:01:32 -0000 Subject: [GHC] #15363: Do some cleaning up of the testsuite driver In-Reply-To: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> References: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> Message-ID: <060.9e49bfa4423cb3f1beb52b0e7bbdf317@haskell.org> #15363: Do some cleaning up of the testsuite driver -------------------------------------+------------------------------------- Reporter: lantti | Owner: lantti Type: task | Status: new Priority: low | Milestone: 8.6.1 Component: Test Suite | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lantti): Eliminating timeout.py turned out to be straight forward and the current features of the subprocess module cover almost exactly what timeout.py did before, with the minor difference that the tests would be separated from the driver with a call to setsid() (creating a new session) instead of merely setpgrp() (creating a new process group). Some little speed-up was observed as each test case now needs to start one process and one python interpreter less. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 20:20:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 20:20:48 -0000 Subject: [GHC] #15389: -Wall-missed-specialisations warnings not fatal with -Werror Message-ID: <047.4a848908677d999f3174dbe93ce4db9f@haskell.org> #15389: -Wall-missed-specialisations warnings not fatal with -Werror -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiling a program with GHC 8.4.3, vector 0.12.0.1 (with a dependency on primitive 0.6.4.0) and `-Wall-missed-specialisations -Werror`, warnings are produced, but they aren't fatal. `-Werror` should make them fatal but doesn't. A somewhat-minimal example: {{{#!hs {-# OPTIONS_GHC -Wall-missed-specialisations -Werror #-} {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} module Warnings3 where import GHC.Base (liftM) import qualified Data.Vector.Generic.Base as G (Vector, basicUnsafeFreeze, basicUnsafeThaw, basicLength, basicUnsafeSlice, basicUnsafeIndexM, basicUnsafeCopy, elemseq) import qualified Data.Vector.Generic.Mutable.Base as GM (MVector, basicLength, basicUnsafeSlice, basicOverlaps, basicUnsafeNew, basicInitialize, basicUnsafeReplicate, basicUnsafeRead, basicUnsafeWrite, basicClear, basicSet, basicUnsafeCopy, basicUnsafeMove, basicUnsafeGrow) import qualified Data.Vector.Unboxed as U (Unbox, Vector) import qualified Data.Vector.Unboxed.Mutable as U (MVector) newtype T = T () deriving (Show, Eq, Ord) newtype C = C (U.Vector T) deriving (Show, Eq, Ord) instance U.Unbox T newtype instance U.MVector s T = MV_T (U.MVector s ()) instance GM.MVector U.MVector T where basicLength (MV_T mv) = GM.basicLength mv basicUnsafeSlice i l (MV_T mv) = MV_T (GM.basicUnsafeSlice i l mv) basicOverlaps (MV_T mv1) (MV_T mv2) = GM.basicOverlaps mv1 mv2 basicUnsafeNew l = MV_T `liftM` GM.basicUnsafeNew l basicInitialize (MV_T mv) = GM.basicInitialize mv basicUnsafeReplicate l _ = MV_T `liftM` GM.basicUnsafeReplicate l () basicUnsafeRead (MV_T mv) i = const (T ()) `liftM` GM.basicUnsafeRead mv i basicUnsafeWrite (MV_T mv) i _ = GM.basicUnsafeWrite mv i () basicClear (MV_T mv) = GM.basicClear mv basicSet (MV_T mv) x = GM.basicSet mv () basicUnsafeCopy (MV_T mv1) (MV_T mv2) = GM.basicUnsafeCopy mv1 mv2 basicUnsafeMove (MV_T mv1) (MV_T mv2) = GM.basicUnsafeMove mv1 mv2 basicUnsafeGrow (MV_T mv) l = MV_T `liftM` GM.basicUnsafeGrow mv l newtype instance U.Vector T = V_T (U.Vector ()) instance G.Vector U.Vector T where basicUnsafeFreeze (MV_T mv) = V_T `liftM` G.basicUnsafeFreeze mv basicUnsafeThaw (V_T v) = MV_T `liftM` G.basicUnsafeThaw v basicLength (V_T v) = G.basicLength v basicUnsafeSlice i l (V_T v) = V_T (G.basicUnsafeSlice i l v) basicUnsafeIndexM (V_T v) i = const (T ()) `liftM` G.basicUnsafeIndexM v i basicUnsafeCopy (MV_T mv) (V_T v) = G.basicUnsafeCopy mv v elemseq (V_T v) _ = G.elemseq v () }}} The warnings are: {{{ src/Warnings3.hs: warning: Could not specialise imported function ‘Data.Vector.Unboxed.$w$cshowsPrec’ when specialising ‘Data.Vector.Unboxed.$fShowVector_$cshowsPrec’ Probable fix: add INLINABLE pragma on ‘Data.Vector.Unboxed.$w$cshowsPrec’ src/Warnings3.hs: warning: Could not specialise imported function ‘Data.Vector.Unboxed.$fOrdVector_$cmin’ Probable fix: add INLINABLE pragma on ‘Data.Vector.Unboxed.$fOrdVector_$cmin’ src/Warnings3.hs: warning: Could not specialise imported function ‘Data.Vector.Unboxed.$fOrdVector_$cmax’ Probable fix: add INLINABLE pragma on ‘Data.Vector.Unboxed.$fOrdVector_$cmax’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 20:26:59 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 20:26:59 -0000 Subject: [GHC] #15384: Every implication should bump the TcLevel exactly once In-Reply-To: <047.d56843a5a9456b5500d56ec561e931f3@haskell.org> References: <047.d56843a5a9456b5500d56ec561e931f3@haskell.org> Message-ID: <062.537c272b1dae5e3a75e007788a2c275b@haskell.org> #15384: Every implication should bump the TcLevel exactly once -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Which tests fail? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 20:51:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 20:51:51 -0000 Subject: [GHC] #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards In-Reply-To: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> References: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> Message-ID: <065.40c3097b65974e78c0f45521be4a5f3e@haskell.org> #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4968 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4968 Comment: It turns out that when GHC desugars patterns bound by pattern guards, it completely forgets to update the local dictionaries in scope with `addDictsDs`! I have no idea how this oversight went unnoticed for so long... In any case, I have a patch for this at Phab:D4968. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 15 21:03:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 15 Jul 2018 21:03:54 -0000 Subject: [GHC] #15357: Make nofib suitable for runtime measurements. In-Reply-To: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> References: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> Message-ID: <062.c240a00cc5f1dba388b6e64850bbfad9@haskell.org> #15357: Make nofib suitable for runtime measurements. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: NoFib benchmark | Version: 8.4.3 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): > Are you offering to help?! It would be great if so. I'm currently working on the NCG for Summer of Code so not before that is over. I might get around to it after, or I might never so if someone else picks this up I would be more than grateful. > there's already FAST/NORM/SLOW setting that is supposed to choose per- benchmarks configurations that take 1s/5s/20s or something vaguely like that. Makefiles can set different parameters for the different settings. While helpful to main issue is that: * There are a benchmarks which use the same setting for all three variants. * It doesn't help with keeping runtimes of different benchmarks in the same ballpark. Ideally we would try to balance runtime so that for example: * Fast (0.1s-1s) - Enough for allocation/instruction counts or rough runtime measurements. * normal (1s-2s) - Decent runtime measurements * slow (5s-10s) - More precision. Currently runtimes for slow just in shootout vary from 0.5s to 40s. So if we only run these two benchmarks we split benchmark time <2%:>98%. Not exactly a good use of resources. One side effect of adjusting runtimes would be that it would invalidate any long term performance comparison. So I'm also not sure if such a patch would be uncontroversial. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 01:01:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 01:01:19 -0000 Subject: [GHC] #15390: Figure out why CircleCI isn't generating haddocks Message-ID: <046.f1394806f5334f184ba374fa296a287b@haskell.org> #15390: Figure out why CircleCI isn't generating haddocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 01:01:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 01:01:24 -0000 Subject: [GHC] #15390: Figure out why CircleCI isn't generating haddocks In-Reply-To: <046.f1394806f5334f184ba374fa296a287b@haskell.org> References: <046.f1394806f5334f184ba374fa296a287b@haskell.org> Message-ID: <061.57053257b59c4e8d43e8e39a62f02679@haskell.org> #15390: Figure out why CircleCI isn't generating haddocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 01:01:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 01:01:39 -0000 Subject: [GHC] #15390: Figure out why CircleCI isn't generating haddocks In-Reply-To: <046.f1394806f5334f184ba374fa296a287b@haskell.org> References: <046.f1394806f5334f184ba374fa296a287b@haskell.org> Message-ID: <061.0e20e3a558c76dcc832acd434c244b92@haskell.org> #15390: Figure out why CircleCI isn't generating haddocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: highest | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * component: Compiler => Continuous Integration -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 01:52:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 01:52:45 -0000 Subject: [GHC] #15391: Maybe ghc-pkg register should unregister packages with "incompatible" signatures Message-ID: <045.400d8f82cf164d3146bbb207e90574df@haskell.org> #15391: Maybe ghc-pkg register should unregister packages with "incompatible" signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: ghc-pkg | Version: 8.4.3 Keywords: backpack | 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 situation: 1. I register package 'p-0.1-inplace' instantiated with 'P = base:Data.Map' 2. I register package 'p-0.1-inplace' instantiated with 'P = base:Control.Monad' Even though the IPID of these two packages is the same, we clearly want to keep both of them in the database. This thus motivates the following lines in ghc-pkg {{{ removes = [ RemovePackage p | not multi_instance, p <- packages db_to_operate_on, mungedId p == mungedId pkg, -- Only remove things that were instantiated the same way! instantiatedWith p == instantiatedWith pkg ] }}} OK... now consider the following situation 1. I register package 'p-0.1-inplace' instantiated with 'P = base:Data.Map' 2. I register package 'p-0.1-inplace', instantiated with nothing (I have edited 'p' such that it has no more signatures) So... ghc-pkg is going to keep both of these packages (per the logic above). But is that really what we want? Now the package database is in a half-consistent state, where the instances of 'p-0.1-inplace' are not consistent with the number of holes they are supposed to have. So let us suggest an invariant: INVARIANT: All packages which have the same IPID in a package database are self-consistent with each other. OK, so given this invariant, what do we have to do in step 2? It would seem that when we get a prospective package to register, we must *find all packages which are incompatible with it*, and remove them from the package database. So, given a package with a set of holes H, we must remove all packages with holes H' such that H = H' I'm not completely convinced this is a good idea. Usually ghc-pkg only removes a single package in response to a new registration, and this behavior could result in lots of packages getting unregistered, more than you might expect. On the other hand, if you think of the package database in a more hierarchical manner, it makes sense that changing the root registration would invalidate all the children. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 03:23:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 03:23:00 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.150f24a044dc3e2d81981d9a0f85af91@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I just checked test `T3234` locally, and it seems to work. Perhaps something went awry in rebasing... (or perhaps I'm not in the right state locally somehow) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 04:33:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 04:33:17 -0000 Subject: [GHC] #15392: Inconsistency in parsing trailing commas inside import section Message-ID: <047.bf5810ab1ba7cf69560278d4553648c5@haskell.org> #15392: Inconsistency in parsing trailing commas inside import section -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Parser) | Keywords: | Operating System: Unknown/Multiple imports,trailing,commas | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following Haskell code compiles without problems: {{{#!hs import Data.Bool (Bool,) }}} As I understand, trailing commas are allowed at the end of `import` declaration. But if I have trailing comma inside data type import part, I see parse error: {{{#!hs import Data.Bool (Bool (True,)) }}} I don't see why this code is forbidden. But allowing trailing commas inside parts of data type imports will make support for automatic refactoring tools easier since they don't need to care about this special case for removing trailing comma manually. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 05:53:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 05:53:55 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.dd091dfd638cdc0b6795d49624def8b7@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:33 goldfire]: > I just checked test `T3234` locally, and it seems to work. Perhaps something went awry in rebasing... (or perhaps I'm not in the right state locally somehow) I haven't rebased anything yet, I checked out the code directly from Phabricator's staging area, so it should be identical to what we're looking at here. However, T3234 is a stdout deviation, not a stat failure, so I'm not too worried about that one, it's probably just a cosmetic difference in output formatting or some such. The thing I'm looking into right now is the stat failures, T5321Fun and T5631. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 05:55:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 05:55:02 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.8363dd532ce27b64b0d99edadf4a5f55@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:31 RyanGlScott]: > You should be able to fix that Haddock compilation error with this patch: > [...] Thanks, works like a charm (although line numbers differ in my version). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 05:59:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 05:59:19 -0000 Subject: [GHC] #15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1) Message-ID: <050.f9874a3a6f2af319ca747dcd6ecdf690@haskell.org> #15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1) -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHCs detection of unused imports used to be very precise. But apparently this changed with GHC 8.0.1. I already noticed for a while that there is something fishy going on and finally came up with a minimal example. == Steps to reproduce: {{{#!hs -- Bar.hs module Bar (bar, module Control.Monad) where import Control.Monad bar :: Integer bar = 23 }}} {{{#!hs -- Foo.hs module Foo where import Bar import Control.Monad (forM_) foo :: Monad m => [a] -> (a -> m ()) -> m () foo = forM_ baz :: Integer baz = bar }}} {{{ $ ghci -Wall -Werror Foo.hs }}} **Expected result:** The program is reject. **Actual result:** The program was reject by GHC < 8.0.1, however later versions of GHC accept the program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 06:32:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 06:32:35 -0000 Subject: [GHC] #15394: GHC doesn't come with dynamic object files/libraries compiled with profiling Message-ID: <045.6ab8588e5191976ea52f364d1ec1a6db@haskell.org> #15394: GHC doesn't come with dynamic object files/libraries compiled with profiling -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC doesn't come with dynamic object files/libraries compiled with profiling thus it's not possible to compile code with `-dynamic` or `-dynamic-too` and `-prof`. This must be a known issue, but I couldn't find a ticket opened specially for it. I also don't know why these files are not included by default in the bindists. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 07:08:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 07:08:05 -0000 Subject: [GHC] #15394: GHC doesn't come with dynamic object files/libraries compiled with profiling In-Reply-To: <045.6ab8588e5191976ea52f364d1ec1a6db@haskell.org> References: <045.6ab8588e5191976ea52f364d1ec1a6db@haskell.org> Message-ID: <060.288d6dec86490d263f074e5de68d61a3@haskell.org> #15394: GHC doesn't come with dynamic object files/libraries compiled with profiling -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Relevant: https://mail.haskell.org/pipermail/ghc- devs/2018-July/015982.html I think there isn't a ticket about this so thanks for creating one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 07:11:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 07:11:45 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <060.4244ab001d7023c57a72691dbdf5555a@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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 ppk): I have started working on this bug at . Not yet on phab because I am waiting for the fix of #15138 to get merged. Will rebase and send the patches then. But here is a status report of what I have done 1. Added a testcase 2. Made the minimal modification that we discussed over IRC Unfortunately just 2 does not help as there is a overlapping instance error that is being thrown. I will investigate this and let you known. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 07:25:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 07:25:47 -0000 Subject: [GHC] #15372: GHCi leaks in DEBUG mode In-Reply-To: <047.2ac34cbfa4c72468332be193667a285f@haskell.org> References: <047.2ac34cbfa4c72468332be193667a285f@haskell.org> Message-ID: <062.f0ed0ce230759ab18e944134e79e3c4c@haskell.org> #15372: GHCi leaks in DEBUG mode -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15246 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I'm OK with not fixing this. Even if we fixed it once, it would be impractical to keep it fixed in the long run. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 08:20:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 08:20:08 -0000 Subject: [GHC] #15136: High CPU when asynchronous exception and unblocking retry on TVar raced In-Reply-To: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> References: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> Message-ID: <062.7bd54f56935562d70dcced09c44d9d90@haskell.org> #15136: High CPU when asynchronous exception and unblocking retry on TVar raced -------------------------------------+------------------------------------- Reporter: nshimaza | Owner: osa1 Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4956 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nshimaza): Let me report that my repro code no longer reproduces the issue with ghc-8.7.20180715 in my test environment! (Platform is Docker for Mac Version 18.03.1-ce-mac65 (24312).) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 08:38:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 08:38:12 -0000 Subject: [GHC] #15390: Figure out why CircleCI isn't generating haddocks In-Reply-To: <046.f1394806f5334f184ba374fa296a287b@haskell.org> References: <046.f1394806f5334f184ba374fa296a287b@haskell.org> Message-ID: <061.dee508d35f63131d8ac77f3fc2a4295c@haskell.org> #15390: Figure out why CircleCI isn't generating haddocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: highest | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Is it because the build flavour that is used isn't the validate one? I think it's `quick` by default. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 08:50:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 08:50:48 -0000 Subject: [GHC] #15395: Make StaticPtr (more) robust to code changes and recompilation Message-ID: <047.9e50400e8b718a1f8b4742f8da05dcc6@haskell.org> #15395: Make StaticPtr (more) robust to code changes and recompilation -------------------------------------+------------------------------------- Reporter: richardw | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Discussion migrated from [https://www.reddit.com/r/haskell/comments/8z86q6/stability_of_staticptr/ this] thread on Reddit. The [http://hackage.haskell.org/package/base-4.11.1.0/docs/GHC- StaticPtr.html documentation] for GHC.StaticPtr states that "Only processes launched from the same program binary are guaranteed to use the same set of keys." On the other hand, this [https://ghc.haskell.org/trac/ghc/blog/simonpj/StaticPointers blog post] by Simon suggests that the only sensible implementation of StaticPtr would be as (essentially) a package/module/identifier name triple, which sounds right to me. In this case two StaticPtrs should share the same key as long as they are in the same package/module and assigned to the same identifier. My use case is similar to the one described [http://neilmitchell.blogspot.com/2017/09/existential-serialisation.html here], where StaticPtr is used for (de)serialization of an existential. As pointed out in the comments to that post, this approach could break upon any recompilation of the code base. Having static pointers stable only across instances of the same binary also seems like it would be a potential problem for the applications like CloudHaskell that StaticPointers was developed for. Presumably this means means all nodes need to be based on the same architecture and updates need to happen on every node simultaneously. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 08:54:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 08:54:08 -0000 Subject: [GHC] #15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1) In-Reply-To: <050.f9874a3a6f2af319ca747dcd6ecdf690@haskell.org> References: <050.f9874a3a6f2af319ca747dcd6ecdf690@haskell.org> Message-ID: <065.7eb4283c65ce6359164df94cc0ffb29c@haskell.org> #15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1) -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): To be complete, you are suggesting that the import of `Control.Monad` in `Foo.hs` should be warned as redundant? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 10:46:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 10:46:46 -0000 Subject: [GHC] #13883: T5435_dyn_asm fails with ld.gold In-Reply-To: <046.0650089fc873411130b9f2d72ad5ad9e@haskell.org> References: <046.0650089fc873411130b9f2d72ad5ad9e@haskell.org> Message-ID: <061.8a6e5e06d0c9e5c9e61a0f4629dd5e0e@haskell.org> #13883: T5435_dyn_asm fails with ld.gold -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Not sure if relevant, but I'm currently observing `T5435_v_asm_a`, `T5435_v_asm_b` and `T5435_v_gcc` fail with segfault when I compile with these settings: {{{ BuildFlavour = quick ifneq "$(BuildFlavour)" "" include mk/flavours/$(BuildFlavour).mk endif GhcRtsHcOpts += -O0 -DDEBUG -fPIC -g3 GhcDebugged = YES GhcStage2HcOpts += -DDEBUG STRIP_CMD = : }}} Test suite output: {{{ =====> T5435_v_asm_a(normal) 1 of 3 [0, 0, 0] cd "./rts/T5435_v_asm_a.run" && $MAKE -s --no-print-directory T5435_v_asm_a Wrong exit code for T5435_v_asm_a()(expected 0 , actual 2 ) Stdout ( T5435_v_asm_a ): Makefile:85: recipe for target 'T5435_v_asm_a' failed Stderr ( T5435_v_asm_a ): make[2]: *** [T5435_v_asm_a] Segmentation fault (core dumped) *** unexpected failure for T5435_v_asm_a(normal) =====> T5435_v_asm_b(normal) 2 of 3 [0, 1, 0] cd "./rts/T5435_v_asm_b.run" && $MAKE -s --no-print-directory T5435_v_asm_b Wrong exit code for T5435_v_asm_b()(expected 0 , actual 2 ) Stdout ( T5435_v_asm_b ): Makefile:87: recipe for target 'T5435_v_asm_b' failed Stderr ( T5435_v_asm_b ): make[2]: *** [T5435_v_asm_b] Segmentation fault (core dumped) *** unexpected failure for T5435_v_asm_b(normal) =====> T5435_v_gcc(normal) 3 of 3 [0, 2, 0] cd "./rts/T5435_v_gcc.run" && $MAKE -s --no-print-directory T5435_v_gcc Wrong exit code for T5435_v_gcc()(expected 0 , actual 2 ) Stdout ( T5435_v_gcc ): Makefile:81: recipe for target 'T5435_v_gcc' failed Stderr ( T5435_v_gcc ): make[2]: *** [T5435_v_gcc] Segmentation fault (core dumped) *** unexpected failure for T5435_v_gcc(normal) }}} Somehow `./validate` passes, so I'm guessing one of the parameters I'm passing to GHC is making a difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 12:02:44 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 12:02:44 -0000 Subject: [GHC] #15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1) In-Reply-To: <050.f9874a3a6f2af319ca747dcd6ecdf690@haskell.org> References: <050.f9874a3a6f2af319ca747dcd6ecdf690@haskell.org> Message-ID: <065.c43bf2dbadaf448de9d9305a0f987dbf@haskell.org> #15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1) -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by SimonHengel): > To be complete, you are suggesting that the import of Control.Monad in Foo.hs should be warned as redundant? Yes, this is what GHC < 8.0.1 did. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 12:34:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 12:34:22 -0000 Subject: [GHC] #15395: Make StaticPtr (more) robust to code changes and recompilation In-Reply-To: <047.9e50400e8b718a1f8b4742f8da05dcc6@haskell.org> References: <047.9e50400e8b718a1f8b4742f8da05dcc6@haskell.org> Message-ID: <062.e907e2aabe6a2ec82457f8411966cdcc@haskell.org> #15395: Make StaticPtr (more) robust to code changes and recompilation -------------------------------------+------------------------------------- Reporter: richardw | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => StaticPointers -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 12:40:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 12:40:05 -0000 Subject: [GHC] #15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1) In-Reply-To: <050.f9874a3a6f2af319ca747dcd6ecdf690@haskell.org> References: <050.f9874a3a6f2af319ca747dcd6ecdf690@haskell.org> Message-ID: <065.87fc85f83f8ba6e8c7882ad66dc8a068@haskell.org> #15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1) -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #15393 Comment: Thanks for the bug report. This is a duplicate of #13064 (in particular, the `Next2` program in https://ghc.haskell.org/trac/ghc/ticket/13064#comment:12), so I'll close this ticket in favor of that one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 12:40:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 12:40:18 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.4f8229b078c84def9a772a06bf2a16f3@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15393 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 12:56:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 12:56:57 -0000 Subject: [GHC] #15260: Xmobar crashes with segmentation fault In-Reply-To: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> References: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> Message-ID: <061.895b846ae5298ce2542687dfc335eaf0@haskell.org> #15260: Xmobar crashes with segmentation fault ----------------------------------+-------------------------------------- Reporter: Voronwe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by dschrempf): Just wanted to add that the crash can be reliably induced by moving floating windows over the bar. {{{ Jul 16 14:56:18 schwarzbaer systemd-coredump[3993]: Process 3929 (xmobar) of user 1000 dumped core. Stack trace of thread 3929: #0 0x00007f8c410892b8 n/a (libHSrts-ghc8.4.3.so) #1 0x00007f8c410885dd n/a (libHSrts-ghc8.4.3.so) #2 0x00007f8c4109f3a4 n/a (libHSrts-ghc8.4.3.so) #3 0x00007f8c410a5c2b n/a (libHSrts-ghc8.4.3.so) #4 0x00007f8c4108e00d n/a (libHSrts-ghc8.4.3.so) #5 0x00007f8c4108ed0a scheduleWaitThread (libHSrts-ghc8.4.3.so) #6 0x00007f8c4109c8dc hs_main (libHSrts-ghc8.4.3.so) #7 0x000000000058adff n/a (xmobar) #8 0x00007f8c4078106b __libc_start_main (libc.so.6) }}} #9 0x00000000004300ba n/a (xmobar) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 13:01:23 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 13:01:23 -0000 Subject: [GHC] #15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1) In-Reply-To: <050.f9874a3a6f2af319ca747dcd6ecdf690@haskell.org> References: <050.f9874a3a6f2af319ca747dcd6ecdf690@haskell.org> Message-ID: <065.847e58539365ddaaa4167b1cc6a3f823@haskell.org> #15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1) -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by SimonHengel): I'm not too excited about this step for the reason that #13064 is not "very to the point" and was deprioritize. As I see it: - This is a regression - I gave very clear instructions how to reproduce that regression At the very least can somebody with appropriate permissions edit the description of #13064 to make it more to the point? (e.g. the cabal file is not at all necessary for a minimal example + even more importantly it also misses the point that previously rejected programs are accepted now). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 13:05:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 13:05:38 -0000 Subject: [GHC] #15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1) In-Reply-To: <050.f9874a3a6f2af319ca747dcd6ecdf690@haskell.org> References: <050.f9874a3a6f2af319ca747dcd6ecdf690@haskell.org> Message-ID: <065.f82bca38dbd0bd224264bd8333fbbc7c@haskell.org> #15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1) -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): You don't need special permissions to edit the description or priority of a Trac ticket; feel free to edit it yourself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 13:34:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 13:34:53 -0000 Subject: [GHC] #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions Message-ID: <050.6a9e69a1ab3df132884705211545628c@haskell.org> #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Linking) | Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiling this simple program: {{{#!hs main = pure () }}} Using the `-staticlib` flag on GHC 8.4.3 on Linux, it panics if using a certain toolchain: {{{ $ uname -a Linux gearloose 4.2.0-42-generic #49~14.04.1-Ubuntu SMP Wed Jun 29 20:22:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux $ /opt/ghc/8.4.3/bin/ghc -staticlib Bug.hs Linking Bug.a ... ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): Data.Binary.Get.runGet at position 27462987: Invalid archive header end marker CallStack (from HasCallStack): error, called at libraries/binary/src/Data/Binary/Get.hs:351:5 in binary-0.8.5.1:Data.Binary.Get }}} I say "certain toolchain" since I am able to reproduce this issue on Ubuntu 14.04, but not 18.04: {{{ $ uname -a Linux Linux-T450 4.15.0-24-generic #26-Ubuntu SMP Wed Jun 13 08:44:47 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux $ ghc -staticlib Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug.a ... }}} This issue does not occur on GHC 8.2 and earlier: {{{ $ /opt/ghc/8.2.2/bin/ghc -staticlib Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug.a ... Static archive creation only supported on Darwin/OS X/iOS }}} Commit b8f33bc6b738b0378976e42b79369f0e53b680c7 allowed the use of `-staticlib` on all platforms. angerman, do you know what might be happening here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 13:36:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 13:36:35 -0000 Subject: [GHC] #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions In-Reply-To: <050.6a9e69a1ab3df132884705211545628c@haskell.org> References: <050.6a9e69a1ab3df132884705211545628c@haskell.org> Message-ID: <065.55afa6a6e44cc7af7659de6f415faec2@haskell.org> #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > When compiling this simple program: > > {{{#!hs > main = pure () > }}} > > Using the `-staticlib` flag on GHC 8.4.3 on Linux, it panics if using a > certain toolchain: > > {{{ > $ uname -a > Linux gearloose 4.2.0-42-generic #49~14.04.1-Ubuntu SMP Wed Jun 29 > 20:22:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux > $ /opt/ghc/8.4.3/bin/ghc -staticlib Bug.hs > Linking Bug.a ... > ghc: panic! (the 'impossible' happened) > (GHC version 8.4.3 for x86_64-unknown-linux): > Data.Binary.Get.runGet at position 27462987: Invalid archive > header end marker > CallStack (from HasCallStack): > error, called at libraries/binary/src/Data/Binary/Get.hs:351:5 in > binary-0.8.5.1:Data.Binary.Get > }}} > > I say "certain toolchain" since I am able to reproduce this issue on > Ubuntu 14.04, but not 18.04: > > {{{ > $ uname -a > Linux Linux-T450 4.15.0-24-generic #26-Ubuntu SMP Wed Jun 13 08:44:47 UTC > 2018 x86_64 x86_64 x86_64 GNU/Linux > $ ghc -staticlib Bug.hs > [1 of 1] Compiling Main ( Bug.hs, Bug.o ) > Linking Bug.a ... > }}} > > This issue does not occur on GHC 8.2 and earlier: > > {{{ > $ /opt/ghc/8.2.2/bin/ghc -staticlib Bug.hs > [1 of 1] Compiling Main ( Bug.hs, Bug.o ) > Linking Bug.a ... > Static archive creation only supported on Darwin/OS X/iOS > }}} > > Commit b8f33bc6b738b0378976e42b79369f0e53b680c7 allowed the use of > `-staticlib` on all platforms. angerman, do you know what might be > happening here? New description: When compiling this simple program: {{{#!hs main = pure () }}} Using the `-staticlib` flag on GHC 8.4.3 on Linux, it panics if using a certain toolchain: {{{ $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.5 LTS Release: 14.04 Codename: trusty $ /opt/ghc/8.4.3/bin/ghc -staticlib Bug.hs Linking Bug.a ... ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): Data.Binary.Get.runGet at position 27462987: Invalid archive header end marker CallStack (from HasCallStack): error, called at libraries/binary/src/Data/Binary/Get.hs:351:5 in binary-0.8.5.1:Data.Binary.Get }}} I say "certain toolchain" since I am able to reproduce this issue on Ubuntu 14.04, but not 18.04: {{{ $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04 LTS Release: 18.04 Codename: bionic $ ghc -staticlib Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug.a ... }}} This issue does not occur on GHC 8.2 and earlier: {{{ $ /opt/ghc/8.2.2/bin/ghc -staticlib Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug.a ... Static archive creation only supported on Darwin/OS X/iOS }}} Commit b8f33bc6b738b0378976e42b79369f0e53b680c7 allowed the use of `-staticlib` on all platforms. angerman, do you know what might be happening here? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 13:54:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 13:54:22 -0000 Subject: [GHC] #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions In-Reply-To: <050.6a9e69a1ab3df132884705211545628c@haskell.org> References: <050.6a9e69a1ab3df132884705211545628c@haskell.org> Message-ID: <065.9865ce8c5bb1ee0dbc0db0b7afd33192@haskell.org> #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > When compiling this simple program: > > {{{#!hs > main = pure () > }}} > > Using the `-staticlib` flag on GHC 8.4.3 on Linux, it panics if using a > certain toolchain: > > {{{ > $ lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 14.04.5 LTS > Release: 14.04 > Codename: trusty > $ /opt/ghc/8.4.3/bin/ghc -staticlib Bug.hs > Linking Bug.a ... > ghc: panic! (the 'impossible' happened) > (GHC version 8.4.3 for x86_64-unknown-linux): > Data.Binary.Get.runGet at position 27462987: Invalid archive > header end marker > CallStack (from HasCallStack): > error, called at libraries/binary/src/Data/Binary/Get.hs:351:5 in > binary-0.8.5.1:Data.Binary.Get > }}} > > I say "certain toolchain" since I am able to reproduce this issue on > Ubuntu 14.04, but not 18.04: > > {{{ > $ lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 18.04 LTS > Release: 18.04 > Codename: bionic > $ ghc -staticlib Bug.hs > [1 of 1] Compiling Main ( Bug.hs, Bug.o ) > Linking Bug.a ... > }}} > > This issue does not occur on GHC 8.2 and earlier: > > {{{ > $ /opt/ghc/8.2.2/bin/ghc -staticlib Bug.hs > [1 of 1] Compiling Main ( Bug.hs, Bug.o ) > Linking Bug.a ... > Static archive creation only supported on Darwin/OS X/iOS > }}} > > Commit b8f33bc6b738b0378976e42b79369f0e53b680c7 allowed the use of > `-staticlib` on all platforms. angerman, do you know what might be > happening here? New description: When compiling this simple program: {{{#!hs main = pure () }}} Using the `-staticlib` flag on GHC 8.4.3 on Linux, it panics if using a certain toolchain: {{{ $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.5 LTS Release: 14.04 Codename: trusty $ /opt/ghc/8.4.3/bin/ghc -fforce-recomp -staticlib Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug.a ... ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): Data.Binary.Get.runGet at position 27462987: Invalid archive header end marker CallStack (from HasCallStack): error, called at libraries/binary/src/Data/Binary/Get.hs:351:5 in binary-0.8.5.1:Data.Binary.Get }}} I say "certain toolchain" since I am able to reproduce this issue on Ubuntu 14.04, but not 18.04: {{{ $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04 LTS Release: 18.04 Codename: bionic $ /opt/ghc/8.4.3/bin/ghc -fforce-recomp -staticlib Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug.a ... }}} This issue does not occur on GHC 8.2 and earlier: {{{ $ /opt/ghc/8.2.2/bin/ghc -staticlib Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug.a ... Static archive creation only supported on Darwin/OS X/iOS }}} Commit b8f33bc6b738b0378976e42b79369f0e53b680c7 allowed the use of `-staticlib` on all platforms. angerman, do you know what might be happening here? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 13:55:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 13:55:32 -0000 Subject: [GHC] #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions In-Reply-To: <050.6a9e69a1ab3df132884705211545628c@haskell.org> References: <050.6a9e69a1ab3df132884705211545628c@haskell.org> Message-ID: <065.fd789e19bb79f0cc1fa97e63c4617a3c@haskell.org> #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "v3-output.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 14:06:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 14:06:48 -0000 Subject: [GHC] #15372: GHCi leaks in DEBUG mode In-Reply-To: <047.2ac34cbfa4c72468332be193667a285f@haskell.org> References: <047.2ac34cbfa4c72468332be193667a285f@haskell.org> Message-ID: <062.58278f4b7000856e2a190197126cf11a@haskell.org> #15372: GHCi leaks in DEBUG mode -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15246 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => wontfix Comment: comment:6 sounds reasonable to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 14:17:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 14:17:29 -0000 Subject: [GHC] #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions In-Reply-To: <050.6a9e69a1ab3df132884705211545628c@haskell.org> References: <050.6a9e69a1ab3df132884705211545628c@haskell.org> Message-ID: <065.de718568e0ad1744c5daa54d8fcb0894@haskell.org> #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Note that I originally tried this with GHCs obtained https://launchpad.net/~hvr/+archive/ubuntu/ghc , but the same thing happens even if you use the official bindist (albeit with a ever-so- slightly different location in the panic): {{{ $ ~/Software/ghc-8.4.3/bin/ghc -fforce-recomp -staticlib Bug.hs /u/rgscott/Software/ghc-8.4.3/lib/ghc-8.4.3/bin/ghc: /lib/x86_64-linux- gnu/libtinfo.so.5: no version information available (required by /home/rgscott/Software/ghc-8.4.3/lib/ghc-8.4.3/bin/../haskeline-0.7.4.2/libHShaskeline-0.7.4.2-ghc8.4.3.so) /u/rgscott/Software/ghc-8.4.3/lib/ghc-8.4.3/bin/ghc: /lib/x86_64-linux- gnu/libtinfo.so.5: no version information available (required by /home/rgscott/Software/ghc-8.4.3/lib/ghc-8.4.3/bin/../ghc-8.4.3/libHSghc-8.4.3-ghc8.4.3.so) /u/rgscott/Software/ghc-8.4.3/lib/ghc-8.4.3/bin/ghc: /lib/x86_64-linux- gnu/libtinfo.so.5: no version information available (required by /home/rgscott/Software/ghc-8.4.3/lib/ghc-8.4.3/bin/../terminfo-0.4.1.1/libHSterminfo-0.4.1.1-ghc8.4.3.so) [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug.a ... ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): Data.Binary.Get.runGet at position 27462451: Invalid archive header end marker CallStack (from HasCallStack): error, called at libraries/binary/src/Data/Binary/Get.hs:351:5 in binary-0.8.5.1:Data.Binary.Get }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 14:28:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 14:28:58 -0000 Subject: [GHC] #15246: -fghci-leak-cheak causes many testsuite failures with the quick build flavour In-Reply-To: <050.c93ffe426b77b4e3ab4a606d2f8a144f@haskell.org> References: <050.c93ffe426b77b4e3ab4a606d2f8a144f@haskell.org> Message-ID: <065.4156c555ea5a048db6ff4e79eceb7f0f@haskell.org> #15246: -fghci-leak-cheak causes many testsuite failures with the quick build flavour -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15372 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): So #15372 was fixed by simply not turning on `-fghci-leak-check` when `DEBUG` is enabled. Simon, could we do the same for the `quick` build flavor? This is preventing me from running tests in `quick` mode. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 14:29:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 14:29:38 -0000 Subject: [GHC] #15373: core-spec.pdf contains parse errors In-Reply-To: <050.1886863a6e820de56c5048e8275c72f6@haskell.org> References: <050.1886863a6e820de56c5048e8275c72f6@haskell.org> Message-ID: <065.77a1dd333ef05cf26205e6fd3de28e8b@haskell.org> #15373: core-spec.pdf contains parse errors -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4965 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"8b6a9e5575fc848dc03b50b415aa57447654662f/ghc" 8b6a9e5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8b6a9e5575fc848dc03b50b415aa57447654662f" Fix parse errors in core-spec.pdf Summary: `core-spec.pdf` was emitting parse errors due to not specifying role arguments in some uses of `nth`. This patch adds those role arguments. (Credit goes to Richard Eisenberg for actually figuring out what said arguments should be.) Test Plan: Read it Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15373 Differential Revision: https://phabricator.haskell.org/D4965 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 14:30:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 14:30:26 -0000 Subject: [GHC] #15373: core-spec.pdf contains parse errors In-Reply-To: <050.1886863a6e820de56c5048e8275c72f6@haskell.org> References: <050.1886863a6e820de56c5048e8275c72f6@haskell.org> Message-ID: <065.8e42899bf3539b76c22d6afd593b4a9f@haskell.org> #15373: core-spec.pdf contains parse errors -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4965 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 14:31:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 14:31:08 -0000 Subject: [GHC] #15246: -fghci-leak-cheak causes many testsuite failures with the quick build flavour In-Reply-To: <050.c93ffe426b77b4e3ab4a606d2f8a144f@haskell.org> References: <050.c93ffe426b77b4e3ab4a606d2f8a144f@haskell.org> Message-ID: <065.d5f5ba3367704aff84e2beb0a07e9a62@haskell.org> #15246: -fghci-leak-cheak causes many testsuite failures with the quick build flavour -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15372 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): There isn't a good way to do that, or at least I couldn't find one. We don't currently have the information about whether the compiler was built without optimisation in the test driver. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 14:33:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 14:33:37 -0000 Subject: [GHC] #15246: -fghci-leak-cheak causes many testsuite failures with the quick build flavour In-Reply-To: <050.c93ffe426b77b4e3ab4a606d2f8a144f@haskell.org> References: <050.c93ffe426b77b4e3ab4a606d2f8a144f@haskell.org> Message-ID: <065.1ce95a31f32028eb226ee0fe779c76eb@haskell.org> #15246: -fghci-leak-cheak causes many testsuite failures with the quick build flavour -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15372 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"71f6b18ba365da9ee4795f6cbce6ec9f1bfe95e8/ghc" 71f6b18/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="71f6b18ba365da9ee4795f6cbce6ec9f1bfe95e8" Fix space leaks Summary: All these were detected by -fghci-leak-check when GHC was compiled *without* optimisation (e.g. using the "quick" build flavour). Unfortunately I don't know of a good way to keep this working. I'd like to just disable the -fghci-leak-check flag when the compiler is built without optimisation, but it doesn't look like we have an easy way to do that. And even if we could, it would be fragile anyway, Test Plan: `cd testsuite/tests/ghci; make` Reviewers: bgamari, hvr, erikd, tdammers Subscribers: tdammers, rwbarton, thomie, carter GHC Trac Issues: #15246 Differential Revision: https://phabricator.haskell.org/D4872 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 14:34:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 14:34:41 -0000 Subject: [GHC] #15246: -fghci-leak-cheak causes many testsuite failures with the quick build flavour In-Reply-To: <050.c93ffe426b77b4e3ab4a606d2f8a144f@haskell.org> References: <050.c93ffe426b77b4e3ab4a606d2f8a144f@haskell.org> Message-ID: <065.eaf399fe1ba6399c5cd33e503c18c9ac@haskell.org> #15246: -fghci-leak-cheak causes many testsuite failures with the quick build flavour -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15372 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I pushed my fix, hopefully that will help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 14:40:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 14:40:33 -0000 Subject: [GHC] #15397: Linking Issue on Ubuntu and Fedora with Provided Bindists (GHC-8.4.2) Message-ID: <049.57dba7948199062b3482838c76f8132a@haskell.org> #15397: Linking Issue on Ubuntu and Fedora with Provided Bindists (GHC-8.4.2) -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.4 Component: Compiler | Version: 8.4.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It appears that the bindists being given to both ubuntu and fedora users are subtly broken. When attempting to link a binary depending on libffi, the linker picks up the copy of `libffi.so.7` found in the rts folder of the distribution. This means that at runtime, despite the systems in question having a copy of `libffi.so.6`, the binary can't find the correct shared library to link against. This does not happen on Arch Linux or Gentoo, as `/usr/lib` or `/usr/lib64` are included in their linker invocations respectively, allowing the linker to pick up the correct version of the dependency. You can reproduce the issue quickly by cloning [https://github.com/luna /luna-core Luna Core] and executing the following commands. I suggest doing this on an Ubuntu or Fedora system as I know it fails on those two distros. {{{ stack build luna-shell --fast stack exec luna }}} You should see something along the lines of the following. {{{ error while loading shared libraries: libffi.so.7: cannot open shared object file: No such file or directory }}} In essence, the reproduction steps are as follows: 1. Create a project depending on libffi using ghc-8.4.2 2. Build the project 3. Execute it The ''expected'' result is that the binary links against the system copy of `libffi.so.6`, rather than the `libffi.so.7` provided in the ghc distribution. I can't guarantee that Ubuntu and Fedora are the only affected systems, but I know that Arch Linux and Gentoo were both fine with the provided bindists. All tested systems were x64, so I cannot confirm if the issue affects x86 bindists. The actual symptom appears to be a result of the linker never being given the path to the system library directory (e.g. `/usr/lib` or `/usr/lib64`), whereas on Arch and Gentoo, the linkline does contain that directory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 14:43:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 14:43:12 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.06c7b07bc6f43d84ae401e1837fc614d@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): `-ddump-simpl` suggests the problem is not increased Core size; the output is practically identical. So I did a run with `+RTS -p`, and got this: {{{ Mon Jul 16 16:37 2018 Time and Allocation Profiling Report (Final) ghc-stage2 +RTS -p -RTS -B/home/tobias/well-typed/devel/ghc- phab/inplace/lib -c T5631.hs -fforce-recomp total time = 1.38 secs (1383 ticks @ 1000 us, 1 processor) total alloc = 1,208,527,080 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc tc_rn_src_decls TcRnDriver compiler/typecheck/TcRnDriver.hs:(491,4)-(553,7) 38.7 55.9 withCleanupSession.cleanup GHC compiler/main/GHC.hs:(468,4)-(475,37) 23.1 0.0 zonkTopDecls TcRnDriver compiler/typecheck/TcRnDriver.hs:(442,16)-(443,43) 7.0 8.7 CorePrep HscMain compiler/main/HscMain.hs:(1317,24)-(1318,57) 3.0 4.9 deSugar HscMain compiler/main/HscMain.hs:512:7-44 2.6 2.5 pprNativeCode AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(529,37)-(530,65) 2.4 1.8 CoreTidy HscMain compiler/main/HscMain.hs:1257:27-67 1.8 2.3 simplIdF Simplify compiler/simplCore/Simplify.hs:859:61-79 1.6 1.3 simplifyTop TcRnDriver compiler/typecheck/TcRnDriver.hs:409:25-39 1.4 2.2 Parser HscMain compiler/main/HscMain.hs:(317,5)-(385,20) 1.4 2.6 StgCmm HscMain compiler/main/HscMain.hs:(1432,13)-(1433,62) 1.3 1.0 }}} And then digging into the call graph analysis, this surprising bit: {{{ hscTypecheck HscMain compiler/main/HscMain.hs:(425,1)-(428,20) 1564 1 0.0 0.0 51.9 73.1 extract_renamed_stuff HscMain compiler/main/HscMain.hs:(397,1)-(410,31) 1640 1 0.0 0.0 0.0 0.0 hscTypecheck' HscMain compiler/main/HscMain.hs:(434,1)-(456,38) 1565 1 0.0 0.0 51.9 73.1 [...] tcRnModule' HscMain compiler/main/HscMain.hs:(461,1)-(500,72) 1570 1 0.0 0.0 50.5 70.5 Typecheck-Rename HscMain compiler/main/HscMain.hs:(464,16)-(465,73) 1571 1 0.0 0.0 50.5 70.5 ioMsgMaybe HscMain compiler/main/HscMain.hs:(251,1)-(256,122) 1572 1 0.4 0.8 50.5 70.5 }}} In other words, we spend 70% of our allocations on "dealing with errors and warnings returned by a compilation step". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 14:45:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 14:45:47 -0000 Subject: [GHC] #15366: GHC.Conc.Windows has a surprising queue In-Reply-To: <045.4d027c14d6779c15e2428ddd193b98f5@haskell.org> References: <045.4d027c14d6779c15e2428ddd193b98f5@haskell.org> Message-ID: <060.7447bd8a7bcf0b058a9db0fe0f17e63e@haskell.org> #15366: GHC.Conc.Windows has a surprising queue -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4967 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D4967 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 15:11:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 15:11:13 -0000 Subject: [GHC] #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. Message-ID: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. --------------------------------------+--------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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 added a second type parameter `k` to a GADT `Zone` and found that when deriving Ord with standalone deriving, the generated code has errors in ghc-8.2.2. There's a reproduction repo for this; https://github.com/BlockScope/zone-inaccessible-code-deriving-ord. I found I needed at least three constructors in `Zone` to get this error. #8128 seemed relevant for being about standalone deriving of a GADT. That being fixed, I tried with ghc-head that I built from source. With this version I found that the same code faults exist in the generated code but are treated as warnings by ghc-8.7.2 {{{ > inplace/bin/ghc-stage2 --version The Glorious Glasgow Haskell Compilation System, version 8.7.20180715 }}} {{{#!hs {-# LANGUAGE DeriveAnyClass #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE StandaloneDeriving #-} module Flight.Zone where newtype Radius a = Radius a deriving (Eq, Ord) data CourseLine data OpenDistance data EndOfSpeedSection -- TODO: Remove standalone deriving Eq & Ord for empty data after GHC 8.4.1 -- SEE: https://ghc.haskell.org/trac/ghc/ticket/7401 deriving instance Eq CourseLine deriving instance Eq OpenDistance deriving instance Eq EndOfSpeedSection deriving instance Ord CourseLine deriving instance Ord OpenDistance deriving instance Ord EndOfSpeedSection data Zone k a where Point :: (Eq a, Ord a) => Zone CourseLine a Vector :: (Eq a, Ord a) => Zone OpenDistance a Conical :: (Eq a, Ord a) => Radius a -> Zone EndOfSpeedSection a deriving instance Eq a => Eq (Zone k a) deriving instance (Eq a, Ord a) => Ord (Zone k a) }}} The error; {{{ /.../Zone.hs:25:1: error: • Couldn't match type ‘OpenDistance’ with ‘CourseLine’ Inaccessible code in a pattern with constructor: Point :: forall a. (Eq a, Ord a) => Zone CourseLine a, in a case alternative • In the pattern: Point {} In a case alternative: Point {} -> GT In the expression: case b of Point {} -> GT Vector -> EQ _ -> LT When typechecking the code for ‘compare’ in a derived instance for ‘Ord (Zone k a)’: To see the code I am typechecking, use -ddump-deriv | 25 | deriving instance (Eq a, Ord a) => Ord (Zone k a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ /.../Zone.hs:25:1: error: • Couldn't match type ‘OpenDistance’ with ‘CourseLine’ Inaccessible code in a pattern with constructor: Point :: forall a. (Eq a, Ord a) => Zone CourseLine a, in a case alternative • In the pattern: Point {} In a case alternative: Point {} -> False In the expression: case b of Point {} -> False Vector -> False _ -> True When typechecking the code for ‘<’ in a derived instance for ‘Ord (Zone k a)’: To see the code I am typechecking, use -ddump-deriv | 25 | deriving instance (Eq a, Ord a) => Ord (Zone k a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} The generated code with these replacements; {{{ :%s/GHC\.Classes\.// :%s/GHC\.Types\.// :%s/Flight\.Zone\.// }}} {{{#!hs instance (Eq a, Ord a) => Ord (Zone k a) where compare a_a2hw b_a2hx = case a_a2hw of Point -> case b_a2hx of Point -> EQ _ -> LT Vector -> case b_a2hx of Point {} -> GT Vector -> EQ _ -> LT Conical a1_a2hy -> case b_a2hx of Conical b1_a2hz -> (a1_a2hy `compare` b1_a2hz) _ -> GT (<) a_a2hA b_a2hB = case a_a2hA of Point -> case b_a2hB of Point -> False _ -> True Vector -> case b_a2hB of Point {} -> False Vector -> False _ -> True Conical a1_a2hC -> case b_a2hB of Conical b1_a2hD -> (a1_a2hC < b1_a2hD) _ -> False (<=) a_a2hE b_a2hF = not ((<) b_a2hF a_a2hE) (>) a_a2hG b_a2hH = (<) b_a2hH a_a2hG (>=) a_a2hI b_a2hJ = not ((<) a_a2hI b_a2hJ) instance Eq a => Eq (Zone k a) where (==) (Point) (Point) = True (==) (Vector) (Vector) = True (==) (Conical a1_a2hK) (Conical b1_a2hL) = ((a1_a2hK == b1_a2hL)) (==) _ _ = False (/=) a_a2hM b_a2hN = not ((==) a_a2hM b_a2hN) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 15:24:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 15:24:41 -0000 Subject: [GHC] #15246: -fghci-leak-cheak causes many testsuite failures with the quick build flavour In-Reply-To: <050.c93ffe426b77b4e3ab4a606d2f8a144f@haskell.org> References: <050.c93ffe426b77b4e3ab4a606d2f8a144f@haskell.org> Message-ID: <065.49b42570ae1064b7ecfa1a1ae4b5c500@haskell.org> #15246: -fghci-leak-cheak causes many testsuite failures with the quick build flavour -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15372 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: Awesome, the tests now pass for me with `quick` (excluding perf tests, of course). Thanks, Simon! It sounds like this is all we can do here, so closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 15:39:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 15:39:05 -0000 Subject: [GHC] #15364: Replace the atomicModifyMutVar# primop In-Reply-To: <045.aa8fbba8dcbd166d60f806e361779d6c@haskell.org> References: <045.aa8fbba8dcbd166d60f806e361779d6c@haskell.org> Message-ID: <060.9973e57d2da0970d6c5fc486faab9a5d@haskell.org> #15364: Replace the atomicModifyMutVar# primop -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4884 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): We now have the first two primops. We'll need to add `atomicSwapMutVar#` in a separate commit. We don't yet support `xchg` in CMM, so we'll have to add it. I noticed, however, that we do have at least some support for it in the LLVM backend, at least (it's a case of read-modify-write). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 16:16:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 16:16:53 -0000 Subject: [GHC] #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. In-Reply-To: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> References: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> Message-ID: <066.cabbf272d3f6bdcf5bbb3954609dbc0b@haskell.org> #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. ---------------------------------+-------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | 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: | ---------------------------------+-------------------------------------- Comment (by RyanGlScott): I'm not sure what exactly the bug is here. The generated code genuinely has inaccessible cases, and since GHC 8.6+, this is a warning instead of an error, so you can now actually use this code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 16:27:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 16:27:36 -0000 Subject: [GHC] #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. In-Reply-To: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> References: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> Message-ID: <066.338f45a5e49751723563a2fb94feade6@haskell.org> #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. ---------------------------------+-------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | 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: | ---------------------------------+-------------------------------------- Comment (by philderbeast): Do those warnings serve an intended purpose and is there no way for GHC to do the derivation without the generated code having warnings and still be correct? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 16:40:23 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 16:40:23 -0000 Subject: [GHC] #15399: Build failure on PowerPC 64-bit big endian Message-ID: <047.59eacae05c8ce75e039f0bbb218e3836@haskell.org> #15399: Build failure on PowerPC 64-bit big endian ---------------------------------+---------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+---------------------------------------- Building GHC 8.6.1 alpha 2 fails with these errors on Powerpc 64-bit big endian Linux: {{{ [ 5076s] utils/check-ppr/Main.hs:44:18: error: [ 5076s] * GHC internal error: `astFile' is not in scope during type checking, but it passed the renamer [ 5076s] tcl_env of environment: [agVj :-> Identifier[libdir::FilePath, NotLetBound], [ 5076s] agVk :-> Identifier[fileName::String, NotLetBound], [ 5076s] agVl :-> Identifier[p::a, NotLetBound], [ 5076s] agVo :-> Identifier[anns::ApiAnns, TopLevelLet [agVl :-> p] False], [ 5076s] agVp :-> Identifier[pragmas::String, TopLevelLet [agVo :-> anns] False], [ 5076s] agVq :-> Identifier[newFile::FilePath, TopLevelLet [agVk :-> fileName] False], [ 5076s] rfRp :-> Identifier[usage::String, TopLevelLet [] True], [ 5076s] rfU1 :-> Identifier[main::IO (), TopLevelLet [] True], [ 5076s] rfU2 :-> Identifier[testOneFile::FilePath [ 5076s] -> String [ 5076s] -> IO (), TopLevelLet [] True], [ 5076s] rfU3 :-> Identifier[parseOneFile::FilePath [ 5076s] -> FilePath [ 5076s] -> IO [ 5076s] ParsedModule, TopLevelLet [] True], [ 5076s] rfU4 :-> Identifier[getPragmas::ApiAnns -> String, TopLevelLet], [ 5076s] rfU5 :-> Identifier[pp::forall a. [ 5076s] Outputable a => [ 5076s] a -> String, TopLevelLet [] True]] [ 5076s] * In the first argument of `writeFile', namely `astFile' [ 5076s] In a stmt of a 'do' block: writeFile astFile origAst [ 5076s] In the expression: [ 5076s] do p <- parseOneFile libdir fileName [ 5076s] let pped = pragmas ++ "\n" ++ pp (pm_parsed_source p) [ 5076s] anns = pm_annotations p [ 5076s] .... [ 5076s] writeFile astFile origAst [ 5076s] writeFile newFile pped [ 5076s] .... [ 5076s] | [ 5076s] 44 | writeFile astFile origAst [ 5076s] | ^^^^^^^ [ 5076s] utils/check-ppr/ghc.mk:18: recipe for target 'utils/check-ppr /dist-install/build/Main.o' failed [ 5076s] make[1]: *** [utils/check-ppr/dist-install/build/Main.o] Error 1 [ 5076s] make[1]: *** Waiting for unfinished jobs.... [ 5077s] [ 5077s] utils/check-api-annotations/Main.hs:116:32: error: [ 5077s] * GHC internal error: `GenericQ' is not in scope during type checking, but it passed the renamer [ 5077s] tcl_env of environment: [agZx :-> Type variable `r' = r :: k0] [ 5077s] * In the type signature: [ 5077s] everything :: (r -> r -> r) -> GenericQ r -> GenericQ r [ 5077s] | [ 5077s] 116 | everything :: (r -> r -> r) -> GenericQ r -> GenericQ r [ 5077s] | ^^^^^^^^ [ 5077s] utils/check-api-annotations/ghc.mk:18: recipe for target 'utils /check-api-annotations/dist-install/build/Main.o' failed [ 5077s] make[1]: *** [utils/check-api-annotations/dist- install/build/Main.o] Error 1 [ 5077s] [ 5077s] utils/ghctags/Main.hs:61:36: error: [ 5077s] * GHC internal error: `FoundThing' is not in scope during type checking, but it passed the renamer [ 5077s] tcl_env of environment: [rCTr :-> ATcTyCon FileData :: *, [ 5077s] rCTs :-> APromotionErr RecDataConPE, [ 5077s] rCTw :-> ATcTyCon FileName :: *] [ 5077s] * In the type `[FoundThing]' [ 5077s] In the definition of data constructor `FileData' [ 5077s] In the data declaration for `FileData' [ 5077s] | [ 5077s] 61 | data FileData = FileData FileName [FoundThing] (Map Int String) [ 5077s] | ^^^^^^^^^^ [ 5077s] utils/ghctags/ghc.mk:18: recipe for target 'utils/ghctags/dist- install/build/Main.o' failed }}} Alpha 2 builds fine on PowerPC 64-bit little endian Linux. I am setting version to 8.5 as there is no tag for 8.6.1 alpha 2 yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 16:42:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 16:42:52 -0000 Subject: [GHC] #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. In-Reply-To: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> References: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> Message-ID: <066.9c969e19cd0945e7515864d73d80fe7e@haskell.org> #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. ---------------------------------+-------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | 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: | ---------------------------------+-------------------------------------- Comment (by RyanGlScott): Replying to [comment:2 philderbeast]: > Is there no way for GHC to do the derivation without the generated code having warnings? In theory this would be possible, but it would significantly complicate the algorithm that `deriving Ord` uses to generate code. Currently, the algorithm is implemented as a pure function over the abstract syntax tree, but changing it to not generate inaccessible cases would require it to propagate typing information in a non-trivial way. I'm skeptical that such a large change would pay its weight, especially since the workaround (just use `-Wno-inaccesible-code`) is so simple. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 18:16:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 18:16:45 -0000 Subject: [GHC] #15387: Unable to set testsuite verbosity to zero from command line In-Reply-To: <045.1ef98c4634b785a6312d5e3fc14d2d67@haskell.org> References: <045.1ef98c4634b785a6312d5e3fc14d2d67@haskell.org> Message-ID: <060.d46f5eb1334c049ed575573c6a3de9c8@haskell.org> #15387: Unable to set testsuite verbosity to zero from command line -------------------------------------+------------------------------------- Reporter: lantti | Owner: lantti Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Test Suite | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lantti): * status: new => patch Comment: https://github.com/ghc/ghc/pull/166 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 19:19:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 19:19:38 -0000 Subject: =?utf-8?b?W0dIQ10gIzE1NDAwOiBQYXJzZSBlcnJvciBvbiBpbnB1dCDigJgq?= =?utf-8?b?4oCZ?= Message-ID: <047.27dc675d8cf48febd86a585d90deec39@haskell.org> #15400: Parse error on input ‘*’ -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Both GHC 8.6.1-alpha1 and 8.6.1-alpha2 fail to build `numtype-dk` package, while GHC 8.4.3 and HEAD work fine. {{{ Configuring numtype-dk-0.5.0.1... Preprocessing library for numtype-dk-0.5.0.1.. Building library for numtype-dk-0.5.0.1.. Numeric/NumType/DK/Integers.hs:38:29: error: parse error on input ‘*’ | 38 | type (+), type (-), type (*), type (/), type (^), | }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 19:21:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 19:21:54 -0000 Subject: [GHC] #15387: Unable to set testsuite verbosity to zero from command line In-Reply-To: <045.1ef98c4634b785a6312d5e3fc14d2d67@haskell.org> References: <045.1ef98c4634b785a6312d5e3fc14d2d67@haskell.org> Message-ID: <060.e81cb960e934eea63cd36957b81f9f5f@haskell.org> #15387: Unable to set testsuite verbosity to zero from command line -------------------------------------+------------------------------------- Reporter: lantti | Owner: lantti Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Test Suite | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"0d6ef6d71e5077eb217456fdd8a515a8cab724ad/ghc" 0d6ef6d7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0d6ef6d71e5077eb217456fdd8a515a8cab724ad" #15387 Fix setting testsuite verbose to zero }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 19:25:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 19:25:03 -0000 Subject: [GHC] #15387: Unable to set testsuite verbosity to zero from command line In-Reply-To: <045.1ef98c4634b785a6312d5e3fc14d2d67@haskell.org> References: <045.1ef98c4634b785a6312d5e3fc14d2d67@haskell.org> Message-ID: <060.4f919b79ac6358bf8aae07f29a23737e@haskell.org> #15387: Unable to set testsuite verbosity to zero from command line -------------------------------------+------------------------------------- Reporter: lantti | Owner: lantti Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Test Suite | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => merge Comment: Good catch, thanks for the patch. This can be merged to ghc-8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 20:08:30 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 20:08:30 -0000 Subject: [GHC] #13775: Type family expansion is too lazy, allows accepting of ill-typed terms In-Reply-To: <045.09c124a40b32f046227808df7e0aa665@haskell.org> References: <045.09c124a40b32f046227808df7e0aa665@haskell.org> Message-ID: <060.c08704f82a5837c447a5fda4c4d81902@haskell.org> #13775: Type family expansion is too lazy, allows accepting of ill-typed terms -------------------------------------+------------------------------------- Reporter: fizruk | Owner: diatchki Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Keywords: Resolution: | CustomTypeErrors 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 tom-bop): Are we sure this has to do with `TypeError`s? I see the same problem without them: {{{#!haskell {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} import GHC.TypeLits import Data.Proxy type family Head xs where -- As written, this compiles, and it also compiles if you uncomment either -- of these lines: -- Head '[] = 'True ~ 'False -- Head '[] = TypeError ('Text "empty list") Head (x ': xs) = x main = print $ show (Proxy::Proxy (Head '[])) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 20:41:10 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 20:41:10 -0000 Subject: [GHC] #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 In-Reply-To: <047.0e132514379b72c39d1662f2412d5748@haskell.org> References: <047.0e132514379b72c39d1662f2412d5748@haskell.org> Message-ID: <062.4829044e28667cb8663b2f4582110c3e@haskell.org> #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 -------------------------------------+------------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4959 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"8ec48990fee9e245bb2fe40dc6f65b61b8612157/ghc" 8ec48990/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8ec48990fee9e245bb2fe40dc6f65b61b8612157" driver: skip -Bsymbolic on unregisterised targets (Trac #15338) Trac #15338 is yet another example where -Bsymbolic breaks semantics of a C program: global variable duplication happens and unsafePerformIO creates two stdout copies. When -Bsymbolic is not used both C compiler and linker agree on how global variables are handled. In case of sh4 it consists on a few assertions: 1. global variable is exported from shared library 2. code is referred to this variable via GOT-like mechanism to allow interposition 3. global variable is present .bss section on an executable (as an R_*_COPY relocation: symbol contents is copied at executable startup time) 4. and symbol in executable interposes symbol in shared library. This way both code in shared library and code in executable refer to a copy of global variable in .bss section of an executable. Unfortunately -Bsymbolic option breaks assumption [2.] and generates direct references to the symbol. This causes mismatch between values seen from executable and values seen from shared library code. This change disables '-Bsymbolic' for unregisterised targets. Signed-off-by: Sergei Trofimovich Test Plan: test 'ghc-pkg --version | cat' to emit data Reviewers: simonmar, bgamari, jrtc27 Reviewed By: jrtc27 Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15338 Differential Revision: https://phabricator.haskell.org/D4959 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 21:35:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 21:35:11 -0000 Subject: [GHC] #15401: Weird GHCi bug Message-ID: <048.13928e6dfd41fd90b1ec3c900765ca88@haskell.org> #15401: Weird GHCi bug -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Take a look at this GHCi session: {{{#!hs $ ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help }}} type `do {_}` {{{#!hs Prelude> do {_} :1:5: error: * Found hole: _ :: t Where: `t' is a rigid type variable bound by the inferred type of it :: t at :1:1-6 * In a stmt of a 'do' block: _ In the expression: do _ In an equation for `it': it = do _ * Relevant bindings include it :: t (bound at :1:1) Valid substitutions include undefined :: forall (a :: TYPE r). GHC.Stack.Types.HasCallStack => a (imported from `Prelude' (and originally defined in `GHC.Err')) }}} looks ok type `()` {{{#!hs Prelude> () () }}} ok type `do {_}` again {{{#!hs Prelude> do {_} :3:5: error: * Found hole: _ :: t Where: `t' is a rigid type variable bound by the inferred type of it :: t at :3:1-6 * In a stmt of a 'do' block: _ In the expression: do _ In an equation for `it': it = do _ * Relevant bindings include it :: t (bound at :3:1) Valid substitutions include undefined :: forall (a :: TYPE r). GHC.Stack.Types.HasCallStack => a (imported from `Prelude' (and originally defined in `GHC.Err')) }}} ok, same message type `()` second type {{{#!hs Prelude> () () }}} ok, type `do {_}` third time: {{{#!hs Prelude> do {_} :1:1: error: GHC internal error: `Ghci1.it' is not in scope during type checking, but it passed the renamer tcl_env of environment: [] Prelude> }}} what's happening? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 21:57:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 21:57:38 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.b0b4e7a41fe8a3497d1ded7a02eac9ab@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Can we compare the numbers with and without the patch? That should show differences. Also I suggest compiling the compiler with `-ticky` and comparing output with and without the patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 22:00:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 22:00:57 -0000 Subject: [GHC] #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. In-Reply-To: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> References: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> Message-ID: <066.6c8bff8e66433c0623df9135303aafbc@haskell.org> #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. ---------------------------------+-------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | 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: | ---------------------------------+-------------------------------------- Comment (by simonpj): Maybe the `deriving` mechanism should somehow add that flag itself. It already switches off a number of warnings -- why not this one too? (With a Note, along the lines of comment:3, to explain.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 22:08:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 22:08:22 -0000 Subject: [GHC] #15401: Weird GHCi bug In-Reply-To: <048.13928e6dfd41fd90b1ec3c900765ca88@haskell.org> References: <048.13928e6dfd41fd90b1ec3c900765ca88@haskell.org> Message-ID: <063.674504ac7c72e0a862646f71a4975bbf@haskell.org> #15401: Weird GHCi bug -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: duplicate | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * keywords: => TypedHoles * resolution: => duplicate * related: => #15007 Comment: Thanks for the bug report. This is a duplicate of #15007, so I'll close this ticket in favor of that one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 22:22:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 22:22:52 -0000 Subject: [GHC] #15402: The settings and behaviour of idle GC are very confusing Message-ID: <042.e4c8b197ac5022919ee692ffbed96a1d@haskell.org> #15402: The settings and behaviour of idle GC are very confusing -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime | Version: 8.4.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This extracting the issue between comments * https://ghc.haskell.org/trac/ghc/ticket/13497#comment:3 and * https://ghc.haskell.org/trac/ghc/ticket/13497#comment:14 into their own issue. There are a few problems problems (as of GHC 8.4.3): **1) You can't disable idle GC.** * This is contrary to the [https://downloads.haskell.org/~ghc/8.4.3/docs/html/users_guide/runtime_control.html #rts-flag--I%20%E2%9F%A8seconds%E2%9F%A9 manual], which says `Specifying -I0 disables the idle GC.`. * Passing `+RTS -I0` will run the idle GC a few times and then it will stop. [https://ghc.haskell.org/trac/ghc/ticket/13497#comment:10 Detailed here]. * It will run in intervals of `0.3` seconds (which is claimed to be the default for `-I` in the manual). **2) Giving the default for `+RTS -I` explicitly, namely `+RTS -I0.3`, changes the behaviour.** * With it given, idle GC will run every 0.3 seconds. * With it not given, it will run for a few times at 0.3 second and then stop. * This is exactly the behaviour of `-I0`. So if the manual said "the default for `-I` is `-I0`, that would be (perversely) more accurate. **3) The docs suggest idle GC is only in effect with `-threaded`.** * [https://downloads.haskell.org/~ghc/8.4.3/docs/html/users_guide/runtime_control.html #rts-flag--I%20%E2%9F%A8seconds%E2%9F%A9 manual "In the threaded and SMP versions of the RTS (see -threaded ...)."] * But idle GC settings like `+RTS -I` clearly also affect the nonthreaded RTS. **4) The concept of running the idle GC "for a little while" is a bit dubious in my opinion.** * Its [https://ghc.haskell.org/trac/ghc/ticket/13497#comment:13 origin as a power-saving mechanism] is sensible. * But it makes things "weird": When you look at `strace`, then first there's `SIGVTALRM` going on (because the idle GC timer of 0.3 seconds is checked against in each timer signal tick of 0.02 seconds by default), then after some time they suddenly stop. Of course `SIGVTALRM` occurring can also have effects on underlying library calls (syscalls return with `EINTR`), so (at least in non`-threaded`) a simple idling Haskell program creates some time-dependent behaviour on C libraries being used. * This makes debugging signal issues and behaviour extra hard, if you constantly have to keep in mind "oh but in the next 0.3 seconds the program will behave like this, and then behaviour will change. When you're debugging with `strace`, you have to be constantly aware whether or not the current output you read is inside or outside that time window. * But I don't have an idea of how this could be improved without sacrificing something else, so I guess this point just remains as "weird" for now. ---- I think points 1-3 are fixable, we should perhaps * make `-I` behave the same as not giving `-I` * change the "default value" to something that reflects what the current default behaviour actually is * the actual possibilities for this option expressed in Haskell would be `data IdleGcMode = NoneAtAll | StoppingAfterSeconds Double | IntervalSeconds Double` * so perhaps we should change `-I` to allow passing the following values to it: * `-I`, e.g. `-I0.3` to mean `IntervalSeconds 0.3` * `-Istopping`, e.g. `-I0.3stopping` to mean `StoppingAfterSeconds 0.3` * `-I0` to mean `NoneAtAll` * and the default would be `-I0.3stopping` to reflect the current default. * fix the documentation to reflect all this -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 22:22:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 22:22:58 -0000 Subject: [GHC] #15390: Figure out why CircleCI isn't generating haddocks In-Reply-To: <046.f1394806f5334f184ba374fa296a287b@haskell.org> References: <046.f1394806f5334f184ba374fa296a287b@haskell.org> Message-ID: <061.2881a954337063e71fe17db5004a4d47@haskell.org> #15390: Figure out why CircleCI isn't generating haddocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: highest | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I actually don't think it is `quick` by default. By default it's essentially `perf` AFAIK. Moreover, `build.mk` explicitly contains, {{{#!make V=1 HADDOCK_DOCS=YES LATEX_DOCS=YES HSCOLOUR_SRCS=YES BUILD_DOCBOOK_HTML=YES BeConservative=YES }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 22:25:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 22:25:49 -0000 Subject: [GHC] #13883: T5435_dyn_asm fails with ld.gold In-Reply-To: <046.0650089fc873411130b9f2d72ad5ad9e@haskell.org> References: <046.0650089fc873411130b9f2d72ad5ad9e@haskell.org> Message-ID: <061.bdc7361175f01bc48f385e686e29cc85@haskell.org> #13883: T5435_dyn_asm fails with ld.gold -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Omer, which linker are you using? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 22:27:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 22:27:48 -0000 Subject: [GHC] #15402: The settings and behaviour of idle GC are very confusing In-Reply-To: <042.e4c8b197ac5022919ee692ffbed96a1d@haskell.org> References: <042.e4c8b197ac5022919ee692ffbed96a1d@haskell.org> Message-ID: <057.c8012db9747dd39db46ee530ff45e520@haskell.org> #15402: The settings and behaviour of idle GC are very confusing -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * keywords: => newcomer * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 22:28:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 22:28:11 -0000 Subject: [GHC] #15136: High CPU when asynchronous exception and unblocking retry on TVar raced In-Reply-To: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> References: <047.29d934aee302d96a63fcdabcdc59c0f2@haskell.org> Message-ID: <062.b8ecb0aa663d6d005534bc01319470d7@haskell.org> #15136: High CPU when asynchronous exception and unblocking retry on TVar raced -------------------------------------+------------------------------------- Reporter: nshimaza | Owner: osa1 Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4956 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Thanks for the confirmation! comment:15 merged with c15ba1fb83575081bb6a1d4955f9e13626ef8d51. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 22:30:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 22:30:11 -0000 Subject: [GHC] #15363: Do some cleaning up of the testsuite driver In-Reply-To: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> References: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> Message-ID: <060.5862475d9d6f9eb57f4f74db5f95d986@haskell.org> #15363: Do some cleaning up of the testsuite driver -------------------------------------+------------------------------------- Reporter: lantti | Owner: lantti Type: task | Status: new Priority: low | Milestone: 8.6.1 Component: Test Suite | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Great news. Do you have a patch to share? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 22:31:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 22:31:04 -0000 Subject: [GHC] #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. In-Reply-To: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> References: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> Message-ID: <066.3eb3be8a2e13825909f599857b3a2790@haskell.org> #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. ---------------------------------+-------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | 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: | ---------------------------------+-------------------------------------- Comment (by RyanGlScott): I have no objection to the proposal in comment:4. That being said, it's far from clear to me how to implement it. Unlike other flags that `deriving` toggles, which primarily live in the renamer, `-Winaccessible- code` warnings are emitted during error reporting, which happens after typechecking. What's more, when `-Winaccessible-code` warnings are created, GHC only has access to an `Implication`, which gives no indication about whether it was created from derived code or not... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 22:31:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 22:31:58 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2315400=3A_Parse_error_on_input_?= =?utf-8?b?4oCYKuKAmQ==?= In-Reply-To: <047.27dc675d8cf48febd86a585d90deec39@haskell.org> References: <047.27dc675d8cf48febd86a585d90deec39@haskell.org> Message-ID: <062.3c6f480a2e5e122d0828f468620118a9@haskell.org> #15400: Parse error on input ‘*’ -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I've lost track of things: does 8.6.1-alpha2 have the `TypeOperators`-implies-`NoStarIsType` implication? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 22:32:44 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 22:32:44 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2315400=3A_Parse_error_on_input_?= =?utf-8?b?4oCYKuKAmQ==?= In-Reply-To: <047.27dc675d8cf48febd86a585d90deec39@haskell.org> References: <047.27dc675d8cf48febd86a585d90deec39@haskell.org> Message-ID: <062.1abbcbe08bc250f1366ef3e3e94cdfb3@haskell.org> #15400: Parse error on input ‘*’ -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): (Note to @Bodigrim: this may already be fixed -- it just may not have made it into any released alphas yet.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 22:40:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 22:40:54 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2315400=3A_Parse_error_on_input_?= =?utf-8?b?4oCYKuKAmQ==?= In-Reply-To: <047.27dc675d8cf48febd86a585d90deec39@haskell.org> References: <047.27dc675d8cf48febd86a585d90deec39@haskell.org> Message-ID: <062.2f79679cc4f61d7a1dda040fcf8d03f4@haskell.org> #15400: Parse error on input ‘*’ -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4865 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => highest * status: new => patch * differential: => Phab:D4865 Comment: Indeed the patch disabling the `TypeOperators`-implies-`NoStarIsType` implication didn't quite make it for alpha 2. It will be in the next pre- release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 22:51:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 22:51:59 -0000 Subject: [GHC] #15363: Do some cleaning up of the testsuite driver In-Reply-To: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> References: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> Message-ID: <060.8eaf07b35b279c4c28f362f7194b1262@haskell.org> #15363: Do some cleaning up of the testsuite driver -------------------------------------+------------------------------------- Reporter: lantti | Owner: lantti Type: task | Status: new Priority: low | Milestone: 8.6.1 Component: Test Suite | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lantti): Not yet, as the timeout.hs needs to be replaced as well to make this work on Windows. I could of course copy-paste the old code back in for Windows and share an intermediate patch, but I don't think we are in such a hurry with this particular ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 23:34:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 23:34:55 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2315400=3A_Parse_error_on_input_?= =?utf-8?b?4oCYKuKAmQ==?= In-Reply-To: <047.27dc675d8cf48febd86a585d90deec39@haskell.org> References: <047.27dc675d8cf48febd86a585d90deec39@haskell.org> Message-ID: <062.847dbfd941bbae6d43c835621aebc653@haskell.org> #15400: Parse error on input ‘*’ -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4865 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => new Comment: Actually, apparently I am confused as well. I did indeed merge an early version of the patch (65c186f0fdde95fd7c63ab9bd9b33a0213dba7d1) way back, even before alpha 1. It's rather concerning that this is still failing. I suspect there is a bug here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 23:39:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 23:39:15 -0000 Subject: [GHC] #15388: GHC reports missing INLINABLE pragmas in vector and ghc-prim In-Reply-To: <047.d222f3350c1cc34659805b35239cc71c@haskell.org> References: <047.d222f3350c1cc34659805b35239cc71c@haskell.org> Message-ID: <062.6ce6741e03723c32a2d88db7e5251f7b@haskell.org> #15388: GHC reports missing INLINABLE pragmas in vector and ghc-prim -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Well, it is indeed not clear to me that we should be throwing warnings for pragmas on bindings that the user didn't even write (e.g. `GHC.Classes.$w$c<=`). On one hand, the warning may help guide the user to the cause of a specialisation failure (even if the warning's suggestion isn't actionable); on the other hand, I can see this being confusing for users. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 23:55:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 23:55:24 -0000 Subject: [GHC] #14627: qAddTopDecls: can't convert top-level declarations In-Reply-To: <049.485d47f57c339e482133548d02dc333a@haskell.org> References: <049.485d47f57c339e482133548d02dc333a@haskell.org> Message-ID: <064.f5d34a77213e5a6af3d0ba69f481a541@haskell.org> #14627: qAddTopDecls: can't convert top-level declarations -------------------------------------+------------------------------------- Reporter: tianxiaogu | Owner: mgsloan Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: th/T14627 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4914 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 16 23:55:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 16 Jul 2018 23:55:33 -0000 Subject: [GHC] #14627: qAddTopDecls: can't convert top-level declarations In-Reply-To: <049.485d47f57c339e482133548d02dc333a@haskell.org> References: <049.485d47f57c339e482133548d02dc333a@haskell.org> Message-ID: <064.a915a4de732826c2407822a65effb39b@haskell.org> #14627: qAddTopDecls: can't convert top-level declarations -------------------------------------+------------------------------------- Reporter: tianxiaogu | Owner: mgsloan Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: th/T14627 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4914 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 00:09:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 00:09:18 -0000 Subject: [GHC] #15262: GHC and iserv cannot agree on what an Integer is; insanity ensues In-Reply-To: <050.8f7705015e16ef64b51a5dbaaaac982c@haskell.org> References: <050.8f7705015e16ef64b51a5dbaaaac982c@haskell.org> Message-ID: <065.8e7ae8dd4ab014eb9e2e25f8c48c23d5@haskell.org> #15262: GHC and iserv cannot agree on what an Integer is; insanity ensues -------------------------------------+------------------------------------- Reporter: howtonotwin | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high Comment: Hmmm, indeed this looks pretty terrible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 00:43:04 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 00:43:04 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2315400=3A_Parse_error_on_input_?= =?utf-8?b?4oCYKuKAmQ==?= In-Reply-To: <047.27dc675d8cf48febd86a585d90deec39@haskell.org> References: <047.27dc675d8cf48febd86a585d90deec39@haskell.org> Message-ID: <062.ca36101914226631078df89a8fbb3222@haskell.org> #15400: Parse error on input ‘*’ -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #15284 | Differential Rev(s): Phab:D4865 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15284 Comment: If I understand #15284 correctly, the fact that this doesn't parse is expected behavior when `StarIsType` is enabled, so I don't think this is a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 00:47:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 00:47:34 -0000 Subject: [GHC] #13184: :show bindings broken under -fexternal-interpreter In-Reply-To: <046.1d0d4d608cb951c5dc098dd3122d78ee@haskell.org> References: <046.1d0d4d608cb951c5dc098dd3122d78ee@haskell.org> Message-ID: <061.0c5dca687d103dbeafde7d91c96f2fae@haskell.org> #13184: :show bindings broken under -fexternal-interpreter -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: RemoteGHCi Operating System: 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:"3bdf0d01ff47977830ada30ce85f174098486e23/ghc" 3bdf0d0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3bdf0d01ff47977830ada30ce85f174098486e23" Support the GHCi debugger with -fexternal-interpreter * All the tests in tests/ghci.debugger now pass with -fexternal-interpreter. These tests are now run with the ghci-ext way in addition to the normal way so we won't break it in the future. * I removed all the unsafeCoerce# calls from RtClosureInspect. Yay! The main changes are: * New messages: GetClosure and Seq. GetClosure is a remote interface to GHC.Exts.Heap.getClosureData, which required Binary instances for various datatypes. Fortunately this wasn't too painful thanks to DeriveGeneric. * No cheating by unsafeCoercing values when printing them. Now we have to turn the Closure representation back into the native representation when printing Int, Float, Double, Integer and Char. Of these, Integer was the most painful - we now have a dependency on integer-gmp due to needing access to the representation. * Fixed a bug in rts/Heap.c - it was bogusly returning stack content as pointers for an AP_STACK closure. Test Plan: * `cd testsuite/tests/ghci.debugger && make` * validate Reviewers: bgamari, patrickdoc, nomeata, angerman, hvr, erikd, goldfire Subscribers: alpmestan, snowleopard, rwbarton, thomie, carter GHC Trac Issues: #13184 Differential Revision: https://phabricator.haskell.org/D4955 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 00:47:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 00:47:49 -0000 Subject: [GHC] #15051: -split-objs generates excessively many files on Windows In-Reply-To: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> References: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> Message-ID: <060.fdc8640597fe2e2d1d68fd67ed178d83@haskell.org> #15051: -split-objs generates excessively many files on Windows -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Phyx- Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (CodeGen) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4915 Wiki Page: | Phab:D4916 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"53649947223f197cf93e26393486f578d56c46c6/ghc" 53649947/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="53649947223f197cf93e26393486f578d56c46c6" split-obj: disable split-objects on Windows. A change has caused GHC to generate excessive specializations. This is making GHC generate 1800 splits for a simple GHC.Prim module, which means 1800 fork/exec calls. Due to this compilation times on Windows with split-objs on take over 24 hours to complete depending on your disk speed. Also the end compiler compiling medium to large project is also much slower. So I think we need to just disable split-objects. As there's nothing that can be done about this. Test Plan: ./validate Reviewers: bgamari Subscribers: tdammers, rwbarton, thomie, erikd, carter GHC Trac Issues: #15051 Differential Revision: https://phabricator.haskell.org/D4915 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 01:17:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 01:17:43 -0000 Subject: [GHC] #14057: Upstream Alpine Linux distribution patches In-Reply-To: <046.942a17c3b70d9863c708d25f4b0f2dde@haskell.org> References: <046.942a17c3b70d9863c708d25f4b0f2dde@haskell.org> Message-ID: <061.f77c75f9c4e2db427ce3b125501b52d8@haskell.org> #14057: Upstream Alpine Linux distribution patches ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14502 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by mitchty): 0000-bootstrap.patch can be ignored entirely, its specific to how alpine linux cross compilation works. The rest were mostly pulled from debian patches for their packages, if that buildpath abi patch isn't needed I can yank it. I think its the last patch to survive with 8.4.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 01:30:05 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 01:30:05 -0000 Subject: [GHC] #15141: decideKindGeneralisationPlan is too complicated In-Reply-To: <046.4f6050513c6b4233d9cf0aed569bb12a@haskell.org> References: <046.4f6050513c6b4233d9cf0aed569bb12a@haskell.org> Message-ID: <061.c8390e3c9456c646acd65e52cc48b777@haskell.org> #15141: decideKindGeneralisationPlan is too complicated -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4971 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab:D4971 Comment: My solution to this is now on Phab. Awaiting review before committing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 01:50:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 01:50:56 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2315400=3A_Parse_error_on_input_?= =?utf-8?b?4oCYKuKAmQ==?= In-Reply-To: <047.27dc675d8cf48febd86a585d90deec39@haskell.org> References: <047.27dc675d8cf48febd86a585d90deec39@haskell.org> Message-ID: <062.01c69ee58d3f891314f03231d596dcfb@haskell.org> #15400: Parse error on input ‘*’ -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #15284 | Differential Rev(s): Phab:D4865 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Oh dear. I've gotten confused about this again! And then I went ahead and confused Ben. I really should know better. This is expected behavior. In GHC 8.6, you have to specify `-XNoStarIsType` in order to use `*` as a type operator. We recognize that this makes for an awkward migration for some users, but, as discussed in [https://github.com/ghc-proposals/ghc-proposals/pull/83 these] [https://github.com/ghc-proposals/ghc-proposals/pull/146 proposals] (more the second one), it seemed better to do it this way than any other we could think of. Just put on `-XNoStarIsType` and you'll be off. However, do we have any migration guide? This should absolutely be in it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 02:36:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 02:36:22 -0000 Subject: [GHC] #15384: Every implication should bump the TcLevel exactly once In-Reply-To: <047.d56843a5a9456b5500d56ec561e931f3@haskell.org> References: <047.d56843a5a9456b5500d56ec561e931f3@haskell.org> Message-ID: <062.b438d2495011354ca88f3ab3e807efa5@haskell.org> #15384: Every implication should bump the TcLevel exactly once -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): These do: {{{ gadt/T12468.run T12468 [stderr mismatch] (normal) ghci/scripts/T8353.run T8353 [bad stderr] (ghci) ghci/scripts/T10248.run T10248 [bad stderr] (ghci) ghci/scripts/T10249.run T10249 [bad stderr] (ghci) ghci/should_run/T15007.run T15007 [bad stderr] (ghci) module/mod71.run mod71 [stderr mismatch] (normal) partial-sigs/should_compile/T12531.run T12531 [exit code non-0] (normal) partial-sigs/should_fail/T14040a.run T14040a [stderr mismatch] (normal) quotes/T10384.run T10384 [stderr mismatch] (normal) th/T10267.run T10267 [stderr mismatch] (normal) th/T10267.run T10267 [stderr mismatch] (ext-interp) typecheck/should_compile/holes2.run holes2 [exit code non-0] (normal) typecheck/should_compile/subsumption_sort_hole_fits.run subsumption_sort_hole_fits [exit code non-0] (normal) typecheck/should_compile/valid_hole_fits_interactions.run valid_hole_fits_interactions [exit code non-0] (normal) typecheck/should_compile/hole_constraints.run hole_constraints [exit code non-0] (normal) typecheck/should_compile/abstract_refinement_hole_fits.run abstract_refinement_hole_fits [exit code non-0] (normal) typecheck/should_compile/holes.run holes [exit code non-0] (normal) typecheck/should_compile/valid_hole_fits.run valid_hole_fits [exit code non-0] (normal) typecheck/should_compile/free_monad_hole_fits.run free_monad_hole_fits [exit code non-0] (normal) typecheck/should_compile/refinement_hole_fits.run refinement_hole_fits [exit code non-0] (normal) typecheck/should_compile/hole_constraints_nested.run hole_constraints_nested [exit code non-0] (normal) typecheck/should_compile/local_hole_fits.run local_hole_fits [exit code non-0] (normal) typecheck/should_compile/constraint_hole_fits.run constraint_hole_fits [exit code non-0] (normal) typecheck/should_compile/type_in_type_hole_fits.run type_in_type_hole_fits [exit code non-0] (normal) typecheck/should_compile/holes3.run holes3 [stderr mismatch] (normal) typecheck/should_compile/T9497b.run T9497b [exit code non-0] (normal) typecheck/should_compile/T9497c.run T9497c [exit code non-0] (normal) typecheck/should_compile/T9497a.run T9497a [exit code non-0] (normal) typecheck/should_compile/T13050.run T13050 [exit code non-0] (normal) typecheck/should_compile/T14590.run T14590 [exit code non-0] (normal) typecheck/should_compile/T14273.run T14273 [exit code non-0] (normal) typecheck/should_fail/TcStaticPointersFail02.run TcStaticPointersFail02 [stderr mismatch] (normal) typecheck/should_fail/T9497d.run T9497d [stderr mismatch] (normal) typecheck/should_fail/T11274.run T11274 [stderr mismatch] (normal) typecheck/should_fail/T12177.run T12177 [stderr mismatch] (normal) }}} Without the ASSERT in !TcSimplify, no test cases fail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 02:40:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 02:40:23 -0000 Subject: [GHC] #15403: Compact Regions with Lazy Evaluation Message-ID: <049.a03a0df83abf66a1a7a65b60f1df1e47@haskell.org> #15403: Compact Regions with Lazy Evaluation -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, adding a value to a compact region evaluates it to normal form. I'm wondering if it's possible to have another compacting primitive that can add unevaluated thunks to a compact region. These thunks would be evaluated as they were demanded, and the resulting values would be added to the compact region. I actually have a use case for this in mind involving very large map-like data structures whose size exceeds system memory when in normal form but that are largely unevaluated, giving them a memory footprint that is a fraction of what it would be. One problem would be that a compaction failure (from someone trying to stick a function or a `MutableArray#` into a compact region) would happen after the call to `compactLazy`, so you end up with all the usual lazy IO problems. Another problem would be that the thunks wouldn't get GCed, since they would live in a compact region (and also because you could not update the references to the thunk, since compact regions are not scanned during GC). Neither of these are absolute deal-breakers though. Are there other problems that make this fundamentally impossible to do? Or is this something that could conceivably be added? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 03:18:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 03:18:28 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2315400=3A_Parse_error_on_input_?= =?utf-8?b?4oCYKuKAmQ==?= In-Reply-To: <047.27dc675d8cf48febd86a585d90deec39@haskell.org> References: <047.27dc675d8cf48febd86a585d90deec39@haskell.org> Message-ID: <062.b56519ae4e81f218b0dd614bf830eeab@haskell.org> #15400: Parse error on input ‘*’ -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #15284 | Differential Rev(s): Phab:D4865 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid Comment: > If I understand #15284 correctly, the fact that this doesn't parse is expected behavior when `StarIsType` is enabled, so I don't think this is a bug. Thanks for setting us right, Ryan! > Oh dear. I've gotten confused about this again! And then I went ahead and confused Ben. To be fair, the latter isn't hard to do :) The migration guide [[https://ghc.haskell.org/trac/ghc/wiki/Migration/8.6#StarIsType indeed]] mentions this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 05:27:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 05:27:29 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <060.7d0feb955ff93324ca4aa4e6f44c4b1c@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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 ppk): Just reporting the things that I learned here (thanks to discussions with @mpickering on IRC) 1. With the minor change, the overlapping instance error is thrown only for inbuilt type classes like `KnownNat` and `KnownSymbol` but ''not for'' Show 2. Overlapping instance is ''not a problem'' for `Typeable`, the other builtin type class that is affected by this change. This means that there is something in the witnessing of `KnownNat` and `KnownSymbol` that is making it see multiple instances. I have updated the test case with all these special classes so that we keep track of these differences. In addition @ezyang just mentioned that it is not clear whether the uniform code will work with both hsboot and hsig files. Since we are not confident about the hsboot part, I will only handle the hsig files in the patches to come. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 05:35:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 05:35:26 -0000 Subject: [GHC] #15380: Infinite typechecker loop in GHC 8.6 In-Reply-To: <050.ceee7eb83a4946e532604b8e627271f4@haskell.org> References: <050.ceee7eb83a4946e532604b8e627271f4@haskell.org> Message-ID: <065.324bc8cdfae87e26c703cafdceb23aab@haskell.org> #15380: Infinite typechecker loop in GHC 8.6 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4974 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab:D4974 Comment: I really nailed this one. See the patch. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 06:08:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 06:08:34 -0000 Subject: [GHC] #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory Message-ID: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: None | Version: Keywords: | Operating System: MacOS X Architecture: | Type of failure: Installing GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It is very difficult to install the ghc-8.6.1 release candidates (both RC1 and RC2) on MacOS because several components attempt to link directly to `/usr/local/opt/gmp/lib/libgmp.10.dylib`. This is not a standard path. See the offending `LC_LOAD_DYLIB` command here: {{{ $ jtool -l libraries/base/dist- install/build/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib LC 00: LC_SEGMENT_64 Mem: 0x000000000-0x4e1000 __TEXT Mem: 0x0000010b0-0x0004d12ba __TEXT.__text (Normal) Mem: 0x0004d12ba-0x0004d1686 __TEXT.__stubs (Symbol Stubs) Mem: 0x0004d1688-0x0004d1cee __TEXT.__stub_helper (Normal) Mem: 0x0004d1cee-0x0004df75b __TEXT.__cstring (C-String Literals) Mem: 0x0004df760-0x0004e0f40 __TEXT.__const Mem: 0x0004e0f40-0x0004e1000 __TEXT.__unwind_info LC 01: LC_SEGMENT_64 Mem: 0x0004e1000-0x5a7000 __DATA Mem: 0x0004e1000-0x0004e30f0 __DATA.__got (Non-Lazy Symbol Ptrs) Mem: 0x0004e30f0-0x0004e3100 __DATA.__nl_symbol_ptr (Non-Lazy Symbol Ptrs) Mem: 0x0004e3100-0x0004e3610 __DATA.__la_symbol_ptr (Lazy Symbol Ptrs) Mem: 0x0004e3610-0x0004e3618 __DATA.__mod_init_func (Module Init Function Ptrs) Mem: 0x0004e3620-0x0004f4bc0 __DATA.__const Mem: 0x0004f4bc0-0x0005a6920 __DATA.__data Mem: 0x0005a6920-0x0005a6928 __DATA.__bss (Zero Fill) LC 02: LC_SEGMENT_64 Mem: 0x0005a7000-0xb8c000 __LINKEDIT LC 03: LC_ID_DYLIB @rpath/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib LC 04: LC_DYLD_INFO LC 05: LC_SYMTAB Symbol table is at offset 0x6a5348 (6968136), 118090 entries String table is at offset 0x873d78 (8863096), 3241616 bytes LC 06: LC_DYSYMTAB 81438 local symbols at index 0 35948 external symbols at index 81438 704 undefined symbols at index 117386 No TOC No modtab 1380 Indirect symbols at offset 0x8727e8 LC 07: LC_UUID UUID: B4C0C347-131F-317B-BA52-EE23F5C5CABA LC 08: LC_VERSION_MIN_MACOSX Minimum OS X version: 10.12.0 LC 09: LC_SOURCE_VERSION Source Version: 0.0.0.0.0 LC 10: LC_LOAD_DYLIB /usr/lib/libiconv.2.dylib LC 11: LC_LOAD_DYLIB @rpath/libHSinteger- gmp-1.0.2.0-ghc8.6.0.20180714.dylib LC 12: LC_LOAD_DYLIB @rpath/libHSghc- prim-0.5.3-ghc8.6.0.20180714.dylib LC 13: LC_LOAD_DYLIB /usr/local/opt/gmp/lib/libgmp.10.dylib LC 14: LC_LOAD_DYLIB /usr/lib/libSystem.B.dylib LC 15: LC_RPATH @loader_path/../integer-gmp-1.0.2.0 LC 16: LC_RPATH @loader_path/../ghc-prim-0.5.3 LC 17: LC_RPATH @loader_path/../rts LC 18: LC_FUNCTION_STARTS Offset: 6876632, Size: 91504 (0x68edd8-0x6a5348) with 83924 functions LC 19: LC_DATA_IN_CODE Offset: 6968136, Size: 0 (0x6a5348-0x6a5348) }}} The other offenders are `libHSbinary` and `libHSinteger-gmp`. Without changing these load commands, you'll get the following error: {{{ $ ./configure --prefix=... $ make install dyld: Library not loaded: /usr/local/opt/gmp/lib/libgmp.10.dylib Referenced from: ./libraries/base/dist- install/build/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib Reason: image not found make[1]: *** [install_packages] Abort trap: 6 make: *** [install] Error 2 }}} I tried passing the `--with-gmp-libraries` option to `configure`, but that did not help. I guess this is just a packaging problem, but figured you should be aware before the official release... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 06:48:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 06:48:24 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <060.a7c71b8c5b27e9ad6138ba8109a6532f@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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 ppk): Resolving the overlapping instance problem is more tricky than I thought. I am adding additional notes here so that some one can better guide the process. This is my current understanding on the issues The `KnownNat` and `KnownSymbol` instance witness and dictionary generating is done by ghc itself in the file `compiler/typecheck/ClsInst.hs`. However this is problematic in the backpack setting because of the following Let us consider the following signature fragment {{{#!haskell signature Abstract where data Foo :: Nat instance KnownNat Foo }}} Suppose this abstract signature is included in a module `Util` {{{#!haskell module Util where import Abstract printFoo :: IO () printFoo = do print $ natVal (Proxy :: Proxy Foo) }}} Notice that the `natVal` function will need a dictionary of `KnownNat Foo` at this point and will need to get it from a concrete implementation of the kind {{{#!haskell module Concrete where type Foo = 42 }}} It is not clear to me how this can be generated "inside the compiler" like what happens in `ClsInst.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 07:30:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 07:30:19 -0000 Subject: [GHC] #13883: T5435_dyn_asm fails with ld.gold In-Reply-To: <046.0650089fc873411130b9f2d72ad5ad9e@haskell.org> References: <046.0650089fc873411130b9f2d72ad5ad9e@haskell.org> Message-ID: <061.452e105e7253ff3360a57e9a5d2fe324@haskell.org> #13883: T5435_dyn_asm fails with ld.gold -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): ld.gold. This is on Xubuntu 18.04. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 07:38:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 07:38:17 -0000 Subject: [GHC] #15403: Compact Regions with Lazy Evaluation In-Reply-To: <049.a03a0df83abf66a1a7a65b60f1df1e47@haskell.org> References: <049.a03a0df83abf66a1a7a65b60f1df1e47@haskell.org> Message-ID: <064.4efeb53e198dbf98683a7ea1bcbbc0fc@haskell.org> #15403: Compact Regions with Lazy Evaluation -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Another problem is that we'd need to teach mutators to allocate in a compact region. Currently mutators only allocate in nurseries (with the exception that some primops can allocate large or pinned blocks etc.) and code generator generates code accordingly. I think a simple trick like "update Hp to point to the compact region, revert it back afterwards" would not work as because of lazy evaluation we'd have to update Hp when evaluating objects referenced by the thunk in the compact region and update again for any other object (not sure if this is possible to do). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 07:43:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 07:43:56 -0000 Subject: [GHC] #15405: Typo in trac ticket number Message-ID: <045.7f153ce611e38056c2aa98480edd4769@haskell.org> #15405: Typo in trac ticket number -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This line should refer to trac issue #14873 not #114873 https://github.com/ghc/ghc/blob/53649947223f197cf93e26393486f578d56c46c6/compiler/typecheck/TcHsType.hs#L1153 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 08:10:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 08:10:53 -0000 Subject: [GHC] #15405: Typo in trac ticket number In-Reply-To: <045.7f153ce611e38056c2aa98480edd4769@haskell.org> References: <045.7f153ce611e38056c2aa98480edd4769@haskell.org> Message-ID: <060.982cfb98406dec5b84632e6a29657225@haskell.org> #15405: Typo in trac ticket number -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by v0d1ch): * owner: (none) => v0d1ch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 08:45:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 08:45:45 -0000 Subject: [GHC] #15405: Typo in trac ticket number In-Reply-To: <045.7f153ce611e38056c2aa98480edd4769@haskell.org> References: <045.7f153ce611e38056c2aa98480edd4769@haskell.org> Message-ID: <060.e3ab9fd73b455dce1a57564cb1a0740f@haskell.org> #15405: Typo in trac ticket number -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4975 Wiki Page: | -------------------------------------+------------------------------------- Changes (by v0d1ch): * status: new => patch * differential: => Phab:D4975 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 09:08:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 09:08:16 -0000 Subject: [GHC] #15405: Typo in trac ticket number In-Reply-To: <045.7f153ce611e38056c2aa98480edd4769@haskell.org> References: <045.7f153ce611e38056c2aa98480edd4769@haskell.org> Message-ID: <060.3516a6f5a431e041db451818435f8412@haskell.org> #15405: Typo in trac ticket number -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4975 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"973ff4a142e77e247caebf828aa51f9810394938/ghc" 973ff4a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="973ff4a142e77e247caebf828aa51f9810394938" Fix a typo in related trac ticket number Reviewers: goldfire, bgamari, mpickering Reviewed By: mpickering Subscribers: mpickering, goldfire, rwbarton, thomie, carter GHC Trac Issues: #15405 Differential Revision: https://phabricator.haskell.org/D4975 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 09:09:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 09:09:26 -0000 Subject: [GHC] #15405: Typo in trac ticket number In-Reply-To: <045.7f153ce611e38056c2aa98480edd4769@haskell.org> References: <045.7f153ce611e38056c2aa98480edd4769@haskell.org> Message-ID: <060.b1a44a4658e5a5c73b619af16bb881fc@haskell.org> #15405: Typo in trac ticket number -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4975 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 09:19:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 09:19:50 -0000 Subject: [GHC] #14231: Core lint error "in result of Static argument" In-Reply-To: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> References: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> Message-ID: <064.139bc1842aabea09228b52b64d44e7fc@haskell.org> #14231: Core lint error "in result of Static argument" -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4945 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 09:31:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 09:31:34 -0000 Subject: [GHC] #15406: Fix a small typo in TcType.hs Message-ID: <045.63481044cbc6f499130eaad746284cc6@haskell.org> #15406: Fix a small typo in TcType.hs -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- >> not substTy, bucause the latter uses smart constructors that do s/bucause/because -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 09:34:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 09:34:06 -0000 Subject: [GHC] #15406: Fix a small typo in TcType.hs In-Reply-To: <045.63481044cbc6f499130eaad746284cc6@haskell.org> References: <045.63481044cbc6f499130eaad746284cc6@haskell.org> Message-ID: <060.6f7317ef36685abb742dc6b574b5d5ba@haskell.org> #15406: Fix a small typo in TcType.hs -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by v0d1ch): * owner: (none) => v0d1ch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 09:34:48 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 09:34:48 -0000 Subject: [GHC] #15406: Fix a small typo in TcType.hs In-Reply-To: <045.63481044cbc6f499130eaad746284cc6@haskell.org> References: <045.63481044cbc6f499130eaad746284cc6@haskell.org> Message-ID: <060.4db2825d88299ec9848b58f47a438eec@haskell.org> #15406: Fix a small typo in TcType.hs -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4976 Wiki Page: | -------------------------------------+------------------------------------- Changes (by v0d1ch): * status: new => patch * differential: => Phab:D4976 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 09:39:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 09:39:12 -0000 Subject: [GHC] #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 In-Reply-To: <047.0e132514379b72c39d1662f2412d5748@haskell.org> References: <047.0e132514379b72c39d1662f2412d5748@haskell.org> Message-ID: <062.bf163159f2e9ba21fc27ec39559b7089@haskell.org> #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 -------------------------------------+------------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4959 Wiki Page: | -------------------------------------+------------------------------------- Comment (by glaubitz): Some packages like haskell-ansi-wl-pprint still seem to have issues though: {{{ Running debian/hlibrary.setup configure --ghc -v2 --package- db=/var/lib/ghc/package.conf.d --prefix=/usr --libdir=/usr/lib/haskell- packages/ghc/lib --libexecdir=/usr/lib --builddir=dist-ghc --ghc-option =-optl-Wl\,-z\,relro --haddockdir=/usr/lib/ghc-doc/haddock/ansi-wl- pprint-0.6.8.2/ --datasubdir=ansi-wl-pprint --htmldir=/usr/share/doc /libghc-ansi-wl-pprint-doc/html/ --enable-library-profiling Configuring ansi-wl-pprint-0.6.8.2... hlibrary.setup: failed to parse output of 'ghc-pkg dump' make: *** [/usr/share/cdbs/1/class/hlibrary.mk:142: configure-ghc-stamp] Error 1 dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2 }}} This is with the patch tested on GHC 8.2.2 with the patch and with optimization set to -O0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 09:51:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 09:51:06 -0000 Subject: [GHC] #15407: Spellcheck TcType file Message-ID: <045.b033aab1652c355a03b005657e72b664@haskell.org> #15407: Spellcheck TcType file -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Minor comment fixes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 09:51:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 09:51:27 -0000 Subject: [GHC] #15407: Spellcheck TcType file In-Reply-To: <045.b033aab1652c355a03b005657e72b664@haskell.org> References: <045.b033aab1652c355a03b005657e72b664@haskell.org> Message-ID: <060.a6649a1540b6b6d8c5f9a59f22f24d8b@haskell.org> #15407: Spellcheck TcType file -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by v0d1ch): * owner: (none) => v0d1ch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 09:53:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 09:53:14 -0000 Subject: [GHC] #15407: Spellcheck TcType file In-Reply-To: <045.b033aab1652c355a03b005657e72b664@haskell.org> References: <045.b033aab1652c355a03b005657e72b664@haskell.org> Message-ID: <060.18fef93fb94c473cc605cc45185f9d04@haskell.org> #15407: Spellcheck TcType file -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4977 Wiki Page: | -------------------------------------+------------------------------------- Changes (by v0d1ch): * differential: => Phab:D4977 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 10:11:40 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 10:11:40 -0000 Subject: [GHC] #15408: Spellcheck TcUnify file Message-ID: <045.dc1869aeb6397e11b70faf676bf86339@haskell.org> #15408: Spellcheck TcUnify file -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Correct spelling errors -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 10:12:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 10:12:03 -0000 Subject: [GHC] #15408: Spellcheck TcUnify file In-Reply-To: <045.dc1869aeb6397e11b70faf676bf86339@haskell.org> References: <045.dc1869aeb6397e11b70faf676bf86339@haskell.org> Message-ID: <060.978bf7a69702e251a57885b57bd34a31@haskell.org> #15408: Spellcheck TcUnify file -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by v0d1ch): * owner: (none) => v0d1ch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 10:13:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 10:13:50 -0000 Subject: [GHC] #15408: Spellcheck TcUnify file In-Reply-To: <045.dc1869aeb6397e11b70faf676bf86339@haskell.org> References: <045.dc1869aeb6397e11b70faf676bf86339@haskell.org> Message-ID: <060.32cccc36a0273dfabf8df199c6fa424a@haskell.org> #15408: Spellcheck TcUnify file -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4978 Wiki Page: | -------------------------------------+------------------------------------- Changes (by v0d1ch): * status: new => patch * differential: => Phab:D4978 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 10:21:32 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 10:21:32 -0000 Subject: [GHC] #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions In-Reply-To: <050.6a9e69a1ab3df132884705211545628c@haskell.org> References: <050.6a9e69a1ab3df132884705211545628c@haskell.org> Message-ID: <065.4d7ba4ccc3c10ec6f05eaf7a1777f637@haskell.org> #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): > Each data section is 2 byte aligned. If it would end on an odd offset, a newline ('\n', 0x0A) is used as filler. (from [https://en.wikipedia.org/wiki/Ar_%28Unix%29 wikipedia:ar (Unix)]) That's pretty much what the `Ar` module fails to account for. For some reason `libHSbase-4.11.1.0.a` ends up having odd byte long object files. As such parsing the archive falls apart. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 10:30:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 10:30:57 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.75d6b14166caf6ef45e37cfd466633e5@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:37 simonpj]: > Can we compare the numbers with and without the patch? That should show differences. And it does. Before patch: {{{ Tue Jul 17 12:17 2018 Time and Allocation Profiling Report (Final) ghc-stage2 +RTS -p -RTS -B/home/tobias/well-typed/devel/ghc- phab/inplace/lib -c T5631.hs -fforce-recomp total time = 1.28 secs (1278 ticks @ 1000 us, 1 processor) total alloc = 1,146,867,328 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc tc_rn_src_decls TcRnDriver compiler/typecheck/TcRnDriver.hs:(491,4)-(553,7) 40.7 55.4 setSessionDynFlags GHC compiler/main/GHC.hs:(578,1)-(584,16) 8.7 0.7 zonkTopDecls TcRnDriver compiler/typecheck/TcRnDriver.hs:(442,16)-(443,43) 7.0 9.2 tcRnSrcDecls TcRnDriver compiler/typecheck/TcRnDriver.hs:255:25-65 4.5 0.4 writeIface HscMain compiler/main/HscMain.hs:1283:9-45 3.4 0.2 withCleanupSession GHC compiler/main/GHC.hs:(466,1)-(475,37) 2.9 0.1 CorePrep HscMain compiler/main/HscMain.hs:(1317,24)-(1318,57) 2.8 4.1 deSugar HscMain compiler/main/HscMain.hs:512:7-44 2.5 2.7 pprNativeCode AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(529,37)-(530,65) 2.3 1.9 simplifyTop TcRnDriver compiler/typecheck/TcRnDriver.hs:409:25-39 1.6 2.3 CoreTidy HscMain compiler/main/HscMain.hs:1257:27-67 1.6 1.8 [...] tc_rn_src_decls TcRnDriver compiler/typecheck/TcRnDriver.hs:(491,4)-(553,7) 1575 1 40.7 55.4 42.8 57.3 Digraph.topSort Digraph compiler/utils/Digraph.hs:350:48-75 1586 341 0.0 0.0 0.0 0.0 solveSimples TcInteract compiler/typecheck/TcInteract.hs:(241,5)-(242,21) 1587 266 0.0 0.0 1.9 1.6 solve_loop TcInteract compiler/typecheck/TcInteract.hs:(246,9)-(250,44) 1589 0 1.5 1.1 1.9 1.6 canNC TcCanonical compiler/typecheck/TcCanonical.hs:(84,5)-(90,45) 1590 1206 0.4 0.5 0.4 0.5 canClass TcCanonical compiler/typecheck/TcCanonical.hs:98:5-31 1591 15 0.0 0.0 0.0 0.0 canEqLeafTyVarEq TcCanonical compiler/typecheck/TcCanonical.hs:105:5-39 1592 3 0.0 0.0 0.0 0.0 Digraph.scc Digraph compiler/utils/Digraph.hs:285:44-67 1576 25 0.0 0.0 0.0 0.0 bin_anns HscTypes compiler/main/HscTypes.hs:1093:47-56 1581 12 0.0 0.0 0.0 0.0 bin_exports HscTypes compiler/main/HscTypes.hs:1088:50-55 1578 12 0.0 0.0 0.0 0.0 bin_fam_insts HscTypes compiler/main/HscTypes.hs:1096:52-57 1584 12 0.0 0.0 0.0 0.0 bin_fixities HscTypes compiler/main/HscTypes.hs:1091:51-56 1579 12 0.0 0.0 0.0 0.0 bin_insts HscTypes compiler/main/HscTypes.hs:1095:48-53 1583 12 0.0 0.0 0.0 0.0 bin_rules HscTypes compiler/main/HscTypes.hs:1097:48-57 1585 12 0.0 0.0 0.0 0.0 bin_tycldecls HscTypes compiler/main/HscTypes.hs:1094:52-57 1582 12 0.2 0.2 0.2 0.2 bin_usages HscTypes compiler/main/HscTypes.hs:1087:49-58 1577 12 0.0 0.0 0.0 0.0 bin_warns HscTypes compiler/main/HscTypes.hs:1092:48-57 1580 12 0.0 0.0 0.0 0.0 substTyWith TyCoRep compiler/types/TyCoRep.hs:(2191,23)-(2192,50) 1616 4 0.0 0.0 0.0 0.0 }}} After: {{{ tc_rn_src_decls TcRnDriver compiler/typecheck/TcRnDriver.hs:(491,4)-(553,7) 49.3 55.9 zonkTopDecls TcRnDriver compiler/typecheck/TcRnDriver.hs:(442,16)-(443,43) 7.6 8.7 CorePrep HscMain compiler/main/HscMain.hs:(1317,24)-(1318,57) 3.9 4.9 deSugar HscMain compiler/main/HscMain.hs:512:7-44 3.3 2.5 setSessionDynFlags GHC compiler/main/GHC.hs:(578,1)-(584,16) 2.9 0.7 CoreTidy HscMain compiler/main/HscMain.hs:1257:27-67 2.2 2.3 simplifyTop TcRnDriver compiler/typecheck/TcRnDriver.hs:409:25-39 2.1 2.2 withCleanupSession GHC compiler/main/GHC.hs:(466,1)-(475,37) 2.1 0.1 pprNativeCode AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(529,37)-(530,65) 2.0 1.8 Parser HscMain compiler/main/HscMain.hs:(317,5)-(385,20) 1.7 2.6 solve_loop TcInteract compiler/typecheck/TcInteract.hs:(246,9)-(250,44) 1.6 1.1 [...] tc_rn_src_decls TcRnDriver compiler/typecheck/TcRnDriver.hs:(491,4)-(553,7) 1584 1 49.3 55.9 52.2 57.7 Digraph.topSort Digraph compiler/utils/Digraph.hs:350:48-75 1595 341 0.1 0.0 0.1 0.0 solveSimples TcInteract compiler/typecheck/TcInteract.hs:(241,5)-(242,21) 1596 266 0.2 0.0 2.5 1.5 solve_loop TcInteract compiler/typecheck/TcInteract.hs:(246,9)-(250,44) 1598 0 1.6 1.0 2.3 1.5 canNC TcCanonical compiler/typecheck/TcCanonical.hs:(84,5)-(90,45) 1599 1206 0.7 0.5 0.7 0.5 canClass TcCanonical compiler/typecheck/TcCanonical.hs:98:5-31 1600 15 0.0 0.0 0.0 0.0 canEqLeafTyVarEq TcCanonical compiler/typecheck/TcCanonical.hs:105:5-39 1601 3 0.0 0.0 0.0 0.0 Digraph.scc Digraph compiler/utils/Digraph.hs:285:44-67 1585 25 0.0 0.0 0.0 0.0 bin_anns HscTypes compiler/main/HscTypes.hs:1093:47-56 1590 12 0.0 0.0 0.0 0.0 bin_exports HscTypes compiler/main/HscTypes.hs:1088:50-55 1587 12 0.0 0.0 0.0 0.0 bin_fam_insts HscTypes compiler/main/HscTypes.hs:1096:52-57 1593 12 0.0 0.0 0.0 0.0 bin_fixities HscTypes compiler/main/HscTypes.hs:1091:51-56 1588 12 0.0 0.0 0.0 0.0 bin_insts HscTypes compiler/main/HscTypes.hs:1095:48-53 1592 12 0.0 0.0 0.0 0.0 bin_rules HscTypes compiler/main/HscTypes.hs:1097:48-57 1594 12 0.0 0.0 0.0 0.0 bin_tycldecls HscTypes compiler/main/HscTypes.hs:1094:52-57 1591 12 0.3 0.2 0.3 0.2 bin_usages HscTypes compiler/main/HscTypes.hs:1087:49-58 1586 12 0.1 0.0 0.1 0.0 bin_warns HscTypes compiler/main/HscTypes.hs:1092:48-57 1589 12 0.0 0.0 0.0 0.0 substTyWith TyCoRep compiler/types/TyCoRep.hs:(2274,23)-(2275,50) 1625 4 0.0 0.0 0.0 0.0 }}} So apparently `tc_rn_src_decls` is responsible for the entire performance hit here, however the calls it makes that we track seem to be identical, and none of its children contributes significantly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 10:36:51 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 10:36:51 -0000 Subject: [GHC] #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions In-Reply-To: <050.6a9e69a1ab3df132884705211545628c@haskell.org> References: <050.6a9e69a1ab3df132884705211545628c@haskell.org> Message-ID: <065.084fd5465b5d6dac976747b3486228f9@haskell.org> #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * Attachment "0001-Fix-Ar-to-respect-two-byte-aligned-sections.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 10:38:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 10:38:24 -0000 Subject: [GHC] #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions In-Reply-To: <050.6a9e69a1ab3df132884705211545628c@haskell.org> References: <050.6a9e69a1ab3df132884705211545628c@haskell.org> Message-ID: <065.a5f12173f9e4107e29d652d9fab633f8@haskell.org> #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * status: new => patch Comment: @bgamari, @RyanGlScott, I've attached a patch. Let me know if this helps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 10:55:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 10:55:01 -0000 Subject: [GHC] #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions In-Reply-To: <050.6a9e69a1ab3df132884705211545628c@haskell.org> References: <050.6a9e69a1ab3df132884705211545628c@haskell.org> Message-ID: <065.97e460993962a5be884a29fbad80946f@haskell.org> #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thanks for the quick work, angerman! I just tried this patch out on my Ubuntu 14.04 machine, and it appears to work quite beautifully. The original program in this ticket no longer panics, and it seems to scale up to building a larger package (in my case, `th-absraction`, where I first noticed this bug) as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 11:33:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 11:33:10 -0000 Subject: [GHC] #15403: Compact Regions with Lazy Evaluation In-Reply-To: <049.a03a0df83abf66a1a7a65b60f1df1e47@haskell.org> References: <049.a03a0df83abf66a1a7a65b60f1df1e47@haskell.org> Message-ID: <064.8d198b7c385a14badc85cf458ef60134@haskell.org> #15403: Compact Regions with Lazy Evaluation -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): That's a good point. It may not be possible to teach mutators to allocate in a compact region. Even if it is, the extra branch need to do this might slow down all programs (even ones that don't need this feature). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 11:37:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 11:37:27 -0000 Subject: [GHC] #13184: :show bindings broken under -fexternal-interpreter In-Reply-To: <046.1d0d4d608cb951c5dc098dd3122d78ee@haskell.org> References: <046.1d0d4d608cb951c5dc098dd3122d78ee@haskell.org> Message-ID: <061.a5fd513c3da7b63a6ce461a5c51d31b8@haskell.org> #13184: :show bindings broken under -fexternal-interpreter -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: Component: GHCi | Version: 8.0.1 Resolution: fixed | Keywords: RemoteGHCi 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: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 11:50:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 11:50:07 -0000 Subject: [GHC] #15409: Quantified constraints half-work with equality constraints Message-ID: <043.7fe1c010678d8ef67ceed7a0b99678e5@haskell.org> #15409: Quantified constraints half-work with equality constraints -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Windows QuantifiedConstraints | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 15359 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Experimenting from the comments in ticket:15359 ... This is using 8.6.0.alpha2 20180714 {{{ {-# LANGUAGE QuantifiedConstraints #-} -- plus the usual suspects -- And over type-level Booleans class ((c ~ 'True) => (a ~ 'True), -- Surprise 1 (c ~ 'True) => (b ~ 'True)) => And' (a :: Bool) (b :: Bool) (c :: Bool) | a b -> c instance () -- Surprise 2 => And' 'True b b instance (('False ~ 'True) => (b ~ 'True)) -- Surprise 3 => And' 'False b 'False y :: (And' a b 'True) => () -- Surprise 4 y = () }}} 1. Those superclass constraints are accepted, with equalities in the implications. 2. The `And 'True b b` instance is accepted without needing further constraints. ?So GHC can figure the implications hold from looking at the instance head. 3. For the `And' 'False b 'False` instance, GHC can't figure the `(c ~ 'True) => (b ~ 'True)` superclass constraint holds. Just substituting into the implication from the instance head seems to satisfy it. So now we have a never-satisfiable antecedent. Rejection message if instance constraints omitted is {{{ * Could not deduce: b ~ 'True arising from the superclasses of an instance declaration from the context: 'False ~ 'True bound by a quantified context at ... }}} 4. The signature for `y` is rejected `Could not deduce (And' a0 b0 'True)`. (The message suggests `AllowAmbiguousTypes`, but that just postpones the error.) I was hoping the superclass constraints would spot that `c ~ 'True` and improve `a, b` from the implications. 5. No surprise that replacing all the `(~)` with `Coercible` produces the same rejections. 6. I did try putting the whole `And` logic in a class without FunDeps. This was accepted: {{{ class (( a ~ 'True) => (b ~ c), ( a ~ 'False) => (c ~ 'False), ( c ~ 'True) => (a ~ 'True), ( c ~ 'True) => (b ~ 'True) ) => And3 (a :: Bool) (b :: Bool) (c :: Bool) -- no FunDep }}} But attempts to write instances and or/use the class evinced only a torrent of obscure messages, including {{{ * Overlapping instances for b ~ 'True arising from the superclasses of an instance declaration Matching givens (or their superclasses): c ~ 'True bound by a quantified context at ... Matching instances: instance [incoherent] forall k (a :: k) (b :: k). (a ~ b) => a ~ b -- Defined in `Data.Type.Equality' }}} So GHC is creating instances for `(~)` on the fly? (I can supply more details if that would help.) Chiefly I'm thinking that if allowing `(~)` in `QuantifiedConstraints` is only teasing and never effective, there should be a clear rejection message. ''pace'' Simon's comments, I don't see any of those `(~)` implications for `And` as "useless" or "redundant". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 12:15:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 12:15:41 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <060.a49789968f573cd5b4423c705d69889e@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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): I'm not sure I'm following all the details here, but can you take inspiration from the way that instances in `hs-boot` files work? If you have {{{ Foo.hs-boot data T instance Eq T }}} then in the `hi-boot` file (which we get from compiling `Foo.hs-boot`) we will have something like {{{ $d77 : Eq T }}} That is, the arbtrarily named `$d77` is a witness for `Eq T`. Modules importing `Foo.hi-boot` use `$d77` when they need `Eq T`. Then when compiling `Foo.hs` we generate the real instance {{{ $d98 = :: Eq T }}} and (having read the `Foo.hi-boot` file, we also generate a compatibility stub {{{ $d77= $d98 }}} so that references to `$d77` will end up in `$d98`. Maybe the same approach will work for `hsig` files. Edward will know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 12:16:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 12:16:55 -0000 Subject: [GHC] #15410: Fix typos in docs Message-ID: <045.0fcd2cfd7b85663c1dca6ec71cc18e55@haskell.org> #15410: Fix typos in docs -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Fix some typos in documenatation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 12:17:05 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 12:17:05 -0000 Subject: [GHC] #15410: Fix typos in docs In-Reply-To: <045.0fcd2cfd7b85663c1dca6ec71cc18e55@haskell.org> References: <045.0fcd2cfd7b85663c1dca6ec71cc18e55@haskell.org> Message-ID: <060.1a256ae29231875ab9b1bc74d7ba92ab@haskell.org> #15410: Fix typos in docs -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by v0d1ch): * owner: (none) => v0d1ch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 12:19:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 12:19:03 -0000 Subject: [GHC] #15410: Fix typos in docs In-Reply-To: <045.0fcd2cfd7b85663c1dca6ec71cc18e55@haskell.org> References: <045.0fcd2cfd7b85663c1dca6ec71cc18e55@haskell.org> Message-ID: <060.8bc74343162729df2bd23ff0fc5e9263@haskell.org> #15410: Fix typos in docs -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4979 Wiki Page: | -------------------------------------+------------------------------------- Changes (by v0d1ch): * status: new => patch * differential: => Phab:D4979 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 12:24:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 12:24:19 -0000 Subject: [GHC] #13775: Type family expansion is too lazy, allows accepting of ill-typed terms In-Reply-To: <045.09c124a40b32f046227808df7e0aa665@haskell.org> References: <045.09c124a40b32f046227808df7e0aa665@haskell.org> Message-ID: <060.59d3adbf651f41604db543a8ecbef780@haskell.org> #13775: Type family expansion is too lazy, allows accepting of ill-typed terms -------------------------------------+------------------------------------- Reporter: fizruk | Owner: diatchki Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Keywords: Resolution: | CustomTypeErrors 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): Well we hvae {{{ instance Show (Proxy s) where ... }}} Notice that `s` is not used. So the instance will work just fine if `s` = `Head '[]`. I don't regard this as a bug (yet, anyway). It accepts more programs than at least some people expect; but well typed programs (ones that are accepted) don't go wrong at runtime, which is what we ask from our type system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 13:14:32 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 13:14:32 -0000 Subject: [GHC] #15403: Compact Regions with Lazy Evaluation In-Reply-To: <049.a03a0df83abf66a1a7a65b60f1df1e47@haskell.org> References: <049.a03a0df83abf66a1a7a65b60f1df1e47@haskell.org> Message-ID: <064.dcf2a99d6ca9392f83033c333e0ed209@haskell.org> #15403: Compact Regions with Lazy Evaluation -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Right, I've thought a fair bit about how you might be able to use compact regions as an arena-style allocator for subcomputations. Of course, this involves teaching mutators to allocate directly into the compact. It turns out this is quite tricky to do for the reasons that Omer mentions. Our implementation of laziness is such that it's very hard to regain control over allocation behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 13:41:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 13:41:08 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.f4f0cd83a682385b5a1c04482409823d@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Another interesting observation is that it eats up more CPU time, but doesn't allocate more. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 14:26:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 14:26:36 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <060.d3d806f6e0bebbd535ef084d1759a7c3@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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 ppk): I think I have fixed it. It turned out that the patch is simpler than I though. Essentially I just made the matchGlobalInstance function to first actually search for an instance and failing which try out the KnownNat and KnownSymbol cases. The commit is https://github.com/piyush- kurur/ghc/commit/364de810f315faba50a4fbe4a68fba3876eb0555 I have also written up an explanation. See if it makes sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 14:46:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 14:46:15 -0000 Subject: [GHC] #15007: Don't keep shadowed variables in ghci, both renamer and type checker In-Reply-To: <049.2656489ff85910f6a80bbfa971643315@haskell.org> References: <049.2656489ff85910f6a80bbfa971643315@haskell.org> Message-ID: <064.bc17c0666376a870e6df889d14ed91ac@haskell.org> #15007: Don't keep shadowed variables in ghci, both renamer and type checker -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: fixed | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11547 #14052 | Differential Rev(s): Phab:D4909 #15202 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => closed * resolution: => fixed Comment: We have a ticket for the panic this caused: #15384. Closing this one as fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 14:48:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 14:48:06 -0000 Subject: [GHC] #15410: Fix typos in docs In-Reply-To: <045.0fcd2cfd7b85663c1dca6ec71cc18e55@haskell.org> References: <045.0fcd2cfd7b85663c1dca6ec71cc18e55@haskell.org> Message-ID: <060.120b4b00669cc30eb5eab0f9fb878c72@haskell.org> #15410: Fix typos in docs -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4979 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): @v0d1ch thanks for your contributions, and thanks for cleaning up the source this way :-) But to make your life easier: I don’t think you necessarily have to create a trac ticket first to fix typos; just create the DR. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 14:58:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 14:58:01 -0000 Subject: [GHC] #15402: The settings and behaviour of idle GC are very confusing In-Reply-To: <042.e4c8b197ac5022919ee692ffbed96a1d@haskell.org> References: <042.e4c8b197ac5022919ee692ffbed96a1d@haskell.org> Message-ID: <057.e638e00ec0ad79b8645fda007fab601e@haskell.org> #15402: The settings and behaviour of idle GC are very confusing -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Re (1), can you demonstrate it? I just tried `ghci +RTS -S -I0` and it definitely disabled the idle GC. (this was with current master) I do see it doing two idle GCs when I would expect just one. I'm not sure why that is. Re (2) I think you might be talking about the non-threaded RTS. With the threaded RTS, -I0.3 is the default, with the non-threaded RTS -I0 is the default. This probably needs to be documented. It probably never occurred to me that someone might use `-I` with the non-threaded RTS. For (3) yes I think the docs need to be updated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 15:08:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 15:08:15 -0000 Subject: [GHC] #15410: Fix typos in docs In-Reply-To: <045.0fcd2cfd7b85663c1dca6ec71cc18e55@haskell.org> References: <045.0fcd2cfd7b85663c1dca6ec71cc18e55@haskell.org> Message-ID: <060.f0752b55552dcf50d5b0236d58c144fd@haskell.org> #15410: Fix typos in docs -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4979 Wiki Page: | -------------------------------------+------------------------------------- Comment (by v0d1ch): DR. being Differential ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 15:56:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 15:56:24 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.777e98e7efb71b60e22673c37924ac6d@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4980 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D4980 Comment: I put the current code up for review, but there isn’t really anything to see; I am just changing one function call :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 16:45:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 16:45:49 -0000 Subject: [GHC] #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions In-Reply-To: <050.6a9e69a1ab3df132884705211545628c@haskell.org> References: <050.6a9e69a1ab3df132884705211545628c@haskell.org> Message-ID: <065.5a3b54e6c158c340c0733384a6645771@haskell.org> #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): Is it possible to add a test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 16:46:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 16:46:49 -0000 Subject: [GHC] #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions In-Reply-To: <050.6a9e69a1ab3df132884705211545628c@haskell.org> References: <050.6a9e69a1ab3df132884705211545628c@haskell.org> Message-ID: <065.9bcb8a41bed38ad48a94d130546d2aac@haskell.org> #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Sure, I think compiling `main = pure ()` with `-staticlib` would be sufficient (as that's broken without this patch). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 17:02:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 17:02:11 -0000 Subject: [GHC] #15384: Every implication should bump the TcLevel exactly once In-Reply-To: <047.d56843a5a9456b5500d56ec561e931f3@haskell.org> References: <047.d56843a5a9456b5500d56ec561e931f3@haskell.org> Message-ID: <062.2211d10d545e505967a245d844a70b1f@haskell.org> #15384: Every implication should bump the TcLevel exactly once -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Tritlo): * cc: Tritlo (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 17:21:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 17:21:47 -0000 Subject: [GHC] #14185: Non-local bug reporting around levity polymorphism In-Reply-To: <047.b7b54b9f6935b8234dc0884836db560a@haskell.org> References: <047.b7b54b9f6935b8234dc0884836db560a@haskell.org> Message-ID: <062.d6db4885912eb8e7d1ea11a8c2537df4@haskell.org> #14185: Non-local bug reporting around levity polymorphism -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: | LevityPolymorphism, | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): expect_broken test added in Phab:14185. This captures the program not compiling, but there's also the issue of non-local bug reporting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 17:37:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 17:37:07 -0000 Subject: [GHC] #15296: Sentence is about Complex type but mentions Simple constructor In-Reply-To: <045.24ba50a15c7175c666a272d89aa697bd@haskell.org> References: <045.24ba50a15c7175c666a272d89aa697bd@haskell.org> Message-ID: <060.543524b67140da05cddbcf05056fa0bb@haskell.org> #15296: Sentence is about Complex type but mentions Simple constructor -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Documentation | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 19:35:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 19:35:38 -0000 Subject: [GHC] #15407: Spellcheck TcType file In-Reply-To: <045.b033aab1652c355a03b005657e72b664@haskell.org> References: <045.b033aab1652c355a03b005657e72b664@haskell.org> Message-ID: <060.d0d967efd775a9d977d501400fd9fea0@haskell.org> #15407: Spellcheck TcType file -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4977 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"2c38a6ee0e24509820d20d6aa450f3c341121423/ghc" 2c38a6ee/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2c38a6ee0e24509820d20d6aa450f3c341121423" Fix spelling errors Reviewers: goldfire, bgamari, osa1 Reviewed By: osa1 Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15407 Differential Revision: https://phabricator.haskell.org/D4977 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 19:35:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 19:35:38 -0000 Subject: [GHC] #15406: Fix a small typo in TcType.hs In-Reply-To: <045.63481044cbc6f499130eaad746284cc6@haskell.org> References: <045.63481044cbc6f499130eaad746284cc6@haskell.org> Message-ID: <060.5721b1b1ebed8b0b5574d050f9230aca@haskell.org> #15406: Fix a small typo in TcType.hs -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4976 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"ab0c2388428c6192ad81f3b93cda58e78c7d218d/ghc" ab0c238/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ab0c2388428c6192ad81f3b93cda58e78c7d218d" Fix a typo Reviewers: goldfire, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15406 Differential Revision: https://phabricator.haskell.org/D4976 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 19:35:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 19:35:38 -0000 Subject: [GHC] #15408: Spellcheck TcUnify file In-Reply-To: <045.dc1869aeb6397e11b70faf676bf86339@haskell.org> References: <045.dc1869aeb6397e11b70faf676bf86339@haskell.org> Message-ID: <060.44556fefd636b2d6516a08b917c2ab0f@haskell.org> #15408: Spellcheck TcUnify file -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4978 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"1f924cb399ea0638356c8e28d8d3593fa63b653f/ghc" 1f924cb3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1f924cb399ea0638356c8e28d8d3593fa63b653f" Correct spelling errors Reviewers: bgamari, osa1 Reviewed By: osa1 Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15408 Differential Revision: https://phabricator.haskell.org/D4978 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 19:35:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 19:35:38 -0000 Subject: [GHC] #15410: Fix typos in docs In-Reply-To: <045.0fcd2cfd7b85663c1dca6ec71cc18e55@haskell.org> References: <045.0fcd2cfd7b85663c1dca6ec71cc18e55@haskell.org> Message-ID: <060.4f312e7b7ed8c53dfa9d1d31e3f7ede2@haskell.org> #15410: Fix typos in docs -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4979 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"932300bb55c8745aea7f29dc36b6d5021e6855c8/ghc" 932300b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="932300bb55c8745aea7f29dc36b6d5021e6855c8" Fix some typos in docs Reviewers: bgamari, osa1 Reviewed By: osa1 Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15410 Differential Revision: https://phabricator.haskell.org/D4979 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 19:36:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 19:36:29 -0000 Subject: [GHC] #15406: Fix a small typo in TcType.hs In-Reply-To: <045.63481044cbc6f499130eaad746284cc6@haskell.org> References: <045.63481044cbc6f499130eaad746284cc6@haskell.org> Message-ID: <060.18c39e91b3ababd45059312dc0b61435@haskell.org> #15406: Fix a small typo in TcType.hs -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4976 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 19:36:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 19:36:46 -0000 Subject: [GHC] #15407: Spellcheck TcType file In-Reply-To: <045.b033aab1652c355a03b005657e72b664@haskell.org> References: <045.b033aab1652c355a03b005657e72b664@haskell.org> Message-ID: <060.f1724b4a0e146bef50d7209df3412552@haskell.org> #15407: Spellcheck TcType file -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4977 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 19:37:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 19:37:16 -0000 Subject: [GHC] #15408: Spellcheck TcUnify file In-Reply-To: <045.dc1869aeb6397e11b70faf676bf86339@haskell.org> References: <045.dc1869aeb6397e11b70faf676bf86339@haskell.org> Message-ID: <060.58ddbfec919450ac01842606cd324595@haskell.org> #15408: Spellcheck TcUnify file -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4978 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 19:39:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 19:39:14 -0000 Subject: [GHC] #15410: Fix typos in docs In-Reply-To: <045.0fcd2cfd7b85663c1dca6ec71cc18e55@haskell.org> References: <045.0fcd2cfd7b85663c1dca6ec71cc18e55@haskell.org> Message-ID: <060.bd89e34bbe586bc892f3092e16f3402b@haskell.org> #15410: Fix typos in docs -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: v0d1ch Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4979 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed Comment: Yes, you use Phabricator only for typos. Thanks for the patches, I've pushed everything. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 22:24:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 22:24:16 -0000 Subject: [GHC] #15363: Do some cleaning up of the testsuite driver In-Reply-To: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> References: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> Message-ID: <060.107dcb5891635788f9680bbf3e7e535d@haskell.org> #15363: Do some cleaning up of the testsuite driver -------------------------------------+------------------------------------- Reporter: lantti | Owner: lantti Type: task | Status: new Priority: low | Milestone: 8.6.1 Component: Test Suite | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): timeout.hs goes through great lengths to be able to reliably detect when all child processes exit using job groups. replacing this with the standard python process api will re-introduce threading issues we spent a great deal of time debugging so be careful with that. It also deals with quite a few corner cases with regards to how msys implements pipes. You would essentially have to rewrite it using ctypes because python's `os` package only provides process grouping for posix OSes. Before such a patch is accepted I'd like to see some evidence that it works correctly when the system is under heavy load. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 22:59:25 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 22:59:25 -0000 Subject: [GHC] #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented In-Reply-To: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> References: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> Message-ID: <061.d501fdd4ddb645c48aad65ad618bc985@haskell.org> #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.4.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4736 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: merge => new * owner: Azel => (none) Comment: Commit 793902e is in ghc-8.6 branch, so I understand there's nothing to merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 17 22:59:48 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 17 Jul 2018 22:59:48 -0000 Subject: [GHC] #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented In-Reply-To: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> References: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> Message-ID: <061.56540373532c18df795efb06a730fa67@haskell.org> #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Azel Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.4.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4736 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * owner: (none) => Azel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 01:12:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 01:12:10 -0000 Subject: [GHC] #15411: urk! lookup local fingerprint Message-ID: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> #15411: urk! lookup local fingerprint -------------------------------------+------------------------------------- Reporter: admock | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When building GHC 8.6.0-alpha2 the build fails with the following error. {{{ [ghc-8.6.0.20180714] alan% make ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for 'phase_1_builds'. ===--- building final phase make --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock-library/src -iutils/haddock/dist/build -Iutils/haddock/dist/build -iutils/haddock/dist/build/haddock/autogen -Iutils/haddock/dist/build/haddock/autogen -optP-DIN_GHC_TREE -optP- include -optPutils/haddock/dist/build/haddock/autogen/cabal_macros.h -package-id Cabal-2.3.0.0 -package-id array-0.5.2.0 -package-id base-4.12.0.0 -package-id bytestring-0.10.8.2 -package-id containers-0.6.0.1 -package-id deepseq-1.4.4.0 -package-id directory-1.3.3.0 -package-id filepath-1.4.2 -package-id ghc-8.6.0.20180714 -package-id ghc-boot-8.6.0.20180714 -package-id parsec-3.1.13.0.0.0.0.0 -package-id text-1.2.3.0 -package-id transformers-0.5.5.0 -package-id xhtml-3000.2.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no-user-package-db -rtsopts -Wno-unused-imports -Wno-deprecations -Wnoncanonical-monad- instances -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/haddock- api/src/Haddock/Backends/Hyperlinker/Types.hs -o utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.6.0.20180714 for powerpc64-unknown-linux): urk! lookup local fingerprint $fEqTokenDetails [cESf79 :-> (Span, 3bafa1c9fb27c5bcc8d6a0fca267f340)] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/iface/MkIface.hs:523:37 in ghc:MkIface Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [utils/haddock/ghc.mk:20: utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o] Error 1 make: *** [Makefile:127: all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 07:23:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 07:23:27 -0000 Subject: [GHC] #15412: "Instance head is not headed by a class" when `Constraint` replaced with `type C = Constraint` Message-ID: <051.c4281f14deae6a8271fa4ba5fd050a12@haskell.org> #15412: "Instance head is not headed by a class" when `Constraint` replaced with `type C = Constraint` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language DataKinds, TypeInType, TypeFamilies #-} import Data.Kind newtype I a = I a type C = Constraint type family UnitC :: Constraint where UnitC = () instance UnitC => Functor I where fmap = undefined }}} this works fine, but if I try to use the constraint synonym `C` (`UnitC :: C where`) fails with "Instance head is not headed by a class" which has '''no''' Google hits outside of the [https://hackage.haskell.org/package/ghc-8.4.1/docs/src/TcValidity.html#checkValidInstance compiler] {{{ $ ghci -ignore-dot-ghci hs/249.hs GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( hs/249.hs, interpreted ) hs/249.hs:13:10: error: • Instance head is not headed by a class • In the instance declaration for ‘Functor I’ | 13 | instance UnitC => Functor I where | ^^^^^^^^^^^^^^^^^^ Failed, no modules loaded. Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 08:42:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 08:42:06 -0000 Subject: [GHC] #15412: "Instance head is not headed by a class" when `Constraint` replaced with `type C = Constraint` In-Reply-To: <051.c4281f14deae6a8271fa4ba5fd050a12@haskell.org> References: <051.c4281f14deae6a8271fa4ba5fd050a12@haskell.org> Message-ID: <066.4267fd9c8f9d3c68478eff30abff5326@haskell.org> #15412: "Instance head is not headed by a class" when `Constraint` replaced with `type C = Constraint` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Can you give the code that fails? In general, in an instance {{{ instance ... => C t1 t2 where ... }}} `C` must be a class; at least that's what the error message is complaining about. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 08:53:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 08:53:00 -0000 Subject: [GHC] #15412: "Instance head is not headed by a class" when `Constraint` replaced with `type C = Constraint` In-Reply-To: <051.c4281f14deae6a8271fa4ba5fd050a12@haskell.org> References: <051.c4281f14deae6a8271fa4ba5fd050a12@haskell.org> Message-ID: <066.0af3d8f522fbf31016da02cea95c6a1f@haskell.org> #15412: "Instance head is not headed by a class" when `Constraint` replaced with `type C = Constraint` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): The failing code is obtained by replacing `Constraint` by `C`: {{{ {-# Language DataKinds, TypeInType, TypeFamilies #-} import Data.Kind newtype I a = I a type C = Constraint type family UnitC :: C where UnitC = () instance UnitC => Functor I where fmap = undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 09:02:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 09:02:25 -0000 Subject: [GHC] #15411: urk! lookup local fingerprint In-Reply-To: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> References: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> Message-ID: <060.e930b5de53fa5a601f97574f74b6e206@haskell.org> #15411: urk! lookup local fingerprint -------------------------------------+------------------------------------- Reporter: admock | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15399 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * version: 8.4.3 => 8.5 * related: => #15399 Comment: Could this be related to #15399? You are on PowerPC 64-bit big endian, aren't you. I also built on a little endian machine and everything is fine there. Could this be an endianness issue. The code generated does not differ much in fact when I wrote both 64-bit backends endianness did not matter at all, only the C calling convention was different. I am setting the version number to 8.5 which is technically still incorrect but 8.6.1 alpha-2 is not on offer and this is as close as we get. I have started to look into #15399 and did some bisecting. I will add my findings there soon. BTW: Good to know that I am not the only one here running GHC on a big endian PowerPC 64-bit :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 09:05:41 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 09:05:41 -0000 Subject: [GHC] #15411: urk! lookup local fingerprint In-Reply-To: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> References: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> Message-ID: <060.5e33a1f5d7bf90ff1cab5be4c93b1caf@haskell.org> #15411: urk! lookup local fingerprint -------------------------------------+------------------------------------- Reporter: admock | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15399 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * cc: trommler, bgamari, hvr (added) Comment: CCing @bgamari as this is a regression, @hvr for the AIX port and myself (for the PowerPC backend) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 10:30:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 10:30:57 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <060.b070ad957f8b7d95c64176ca6e582566@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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): The current implementation only ever has instances for `KnownNat 1`, `KnownNat 2` etc. This is described in `Note [KnownNat & KnownSymbol and EvLit]` in `TcInteract`. But now you want to allow `instance KnownNat T` for some abstract type `T`; you explain this well in comment:4. Very well; but I really dislike messing with `matchInstEnv`. Better: make `mathKnownNat` have an `otherwise` case that, instead of returning `NoInstance` uses `matchInstEnv`. With a careful `Note` to explain. Interestingly, `matchHasField` already does this, but without explanation :-(. I also worry about the other classes treated specially in `matchGlobalInst`. For some (`matchCTuple` , `matchLiftedEquality`, `matchLiftedCoercible`) they can't fail, so that's fine. But `Typeable` can fail; I wonder if you might end up wanting a `Typeable` instance in a `hsig` file. I think that's all... but the big point is that GHC's treatment of built-in classes may need attention because of Backpack; KnownNat is just an example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 11:05:21 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 11:05:21 -0000 Subject: [GHC] #14185: Non-local bug reporting around levity polymorphism In-Reply-To: <047.b7b54b9f6935b8234dc0884836db560a@haskell.org> References: <047.b7b54b9f6935b8234dc0884836db560a@haskell.org> Message-ID: <062.cdee612b4258dc5b71a552e47f7b2ab8@haskell.org> #14185: Non-local bug reporting around levity polymorphism -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: | LevityPolymorphism, | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I looked at this in an odd moment. This instance {{{ instance (Unbox a a', Unbox b b') => Unbox (a,b) (# a', b' #) where unbox (a,b) = (# unbox a, unbox b #) box (# a, b #) = (box a, box b) }}} is quantified over four type variables, ''all of which get kind `Type`''. But in `testTup` we will need to solve {{{ [W] Unbox (Int, Char) (# Int#, Char# ) }}} That is well-kinded but it doesn't match the instance (which has only lifted type variables). What ''actually'' happens is that we try to solve {{{ [W] Unbox (Int,Char) alpha }}} and the fundep says `alpha := (# beta, gamma #)`, but since the fundep comes from the tuple instance, it insists that `beta::*` and `gamma::*`. If you try to make the instance levity-polymorphic: {{{ instance forall a b ar br (a' :: TYPE r1) (b' :: TYPE br). (Unbox a a', Unbox b b') => Unbox (a,b) (# a', b' #) where }}} it rightly fails with {{{ T14185a.hs:23:10: error: A levity-polymorphic type is not allowed here: Type: a' Kind: TYPE r1 In the type of binder ‘a’ | 23 | box (# a, b #) = (box a, box b) | ^ }}} This does not explain why we get bogus errors in `testInt` but I claim there is no bug in rejecting `testTup`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 12:22:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 12:22:34 -0000 Subject: [GHC] #15363: Do some cleaning up of the testsuite driver In-Reply-To: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> References: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> Message-ID: <060.5caf6ac52e771e26bea13e00d448a814@haskell.org> #15363: Do some cleaning up of the testsuite driver -------------------------------------+------------------------------------- Reporter: lantti | Owner: lantti Type: task | Status: new Priority: low | Milestone: 8.6.1 Component: Test Suite | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lantti): As I mentioned earlier, Windows seems tricky. I had already come to the conclusion that python subprocess module is not going to be able to cleanly cut this, but, like you said, the next option would be a rewrite accessing winapi over ctypes and I don't see that as prohibitive in any way. I think I have reasonably good understanding of what timeout.hs is doing, but like I mentioned earlier, it doesn't seem to be fully functional in the current msys environment. I will slowly keep on investigating this when I find free moments. After I come with a patch we can discuss how to best test it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 12:34:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 12:34:15 -0000 Subject: [GHC] #15064: T8089 mysteriously fails when GHC is built with LLVM In-Reply-To: <046.7f8c4e91c0adf39423142484582ab39d@haskell.org> References: <046.7f8c4e91c0adf39423142484582ab39d@haskell.org> Message-ID: <061.7edb15d8f13980d257eac9e83ed10a1f@haskell.org> #15064: T8089 mysteriously fails when GHC is built with LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (LLVM) | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * owner: bgamari => osa1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 12:48:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 12:48:03 -0000 Subject: [GHC] #15399: Build failure on PowerPC 64-bit big endian In-Reply-To: <047.59eacae05c8ce75e039f0bbb218e3836@haskell.org> References: <047.59eacae05c8ce75e039f0bbb218e3836@haskell.org> Message-ID: <062.51165a3b7ff63af40951af08c84323b8@haskell.org> #15399: Build failure on PowerPC 64-bit big endian ----------------------------------------+--------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+--------------------------------- Changes (by trommler): * cc: hvr, bgamari (added) Comment: Currently my last known good commit is commit:d78dde9. At changeset:bdfc85b I see the following tests failures during validate: {{{ Unexpected results from: TEST="ManyAlternatives ManyConstructors T10520 T10858 T12007 T12425 T12545 T12707 T13035 T13379 T13615 T13825-ghci T14894 T1969 T2182ghci T3064 T3294 T4801 T5321FD T5321Fun T5435_v_asm_b T5631 T6048 T7253 T7386 T783 T8557 T9233 duplicaterecfldsghci01 ghc-e006 ghci.prog007 ghci006 ghci039 ghci045 ghci049 ghci052 ghci053 ghcirun001 ghcirun002 heap_all print002 print003 print006 print007 print008 print010 print012 print013 print014 print018 print019 print021 print025 print031 print034" SUMMARY for test run started at Wed Jul 18 12:35:24 2018 CEST 1:18:37 spent to go through 6386 total tests, which gave rise to 19686 test cases, of which 13227 were skipped 38 had missing libraries 6190 expected passes 176 expected failures 2 caused framework failures 1 caused framework warnings }}} Note the large number of GHCi tests failing. I will now bisect in that range above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 14:05:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 14:05:05 -0000 Subject: [GHC] #15412: "Instance head is not headed by a class" when `Constraint` replaced with `type C = Constraint` In-Reply-To: <051.c4281f14deae6a8271fa4ba5fd050a12@haskell.org> References: <051.c4281f14deae6a8271fa4ba5fd050a12@haskell.org> Message-ID: <066.0f9bd18c146aec6e8088e610e5fbbb64@haskell.org> #15412: "Instance head is not headed by a class" when `Constraint` replaced with `type C = Constraint` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Yes sorry, I should have included the failing code. Here is a version without type families {{{#!hs {-# Language DataKinds, TypeInType, ConstraintKinds #-} import Data.Kind data A :: Type type C = Constraint type UnitC = (() :: C) instance UnitC => Eq A where (==) = undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 14:06:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 14:06:42 -0000 Subject: [GHC] #15411: urk! lookup local fingerprint In-Reply-To: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> References: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> Message-ID: <060.e2bf07163b1dd5865cd1ab0f4c6620d2@haskell.org> #15411: urk! lookup local fingerprint -------------------------------------+------------------------------------- Reporter: admock | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15399 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by admock): I am building on a big endian OS, which seems to be a cause of many problems. I also saw the issue in #15399 so it's possible that they're related. I have also started bisecting looking for the breaking commit and I'll post my results when I have it. I haven't really done any work on GHC but I'm happy to help if I can. It is good to see someone else cares about the PPC64 backend. I thought I'd have to figure this out on my own since it's big endian :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 17:24:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 17:24:05 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF In-Reply-To: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> References: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> Message-ID: <060.d0da481b1faa6c64681324c918c577fe@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | perf/should_run/T15226, 15226a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4796 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:16 simonpj]: > > seq# is intentionally lazy in its argument, to allow explicit ordering in an IO context > > Hmnm. Can you give an example? Nothing in `seq#`'s documentation says that. It jolly well should! Considering `seq#` strict can be rather bad, I believe. If we turn `.... seq# x s` into `case x of x' {DEFAULT__ -> .... seq# x' s}` then we'll see that `x'` is evaluated and erase the `seq#`. That sort of thing is the very sort of trouble `seq#` was intended to avoid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 17:54:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 17:54:14 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <060.d449831c9a56c93b8b3e9c9ef5fa5f0c@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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 ppk): Replying to [comment:7 simonpj]: > The current implementation only ever has instances for `KnownNat 1`, `KnownNat 2` etc. This is described in `Note [KnownNat & KnownSymbol and EvLit]` in `TcInteract`. > Yes that note was quite useful in fact. > But now you want to allow `instance KnownNat T` for some abstract type `T`; you explain this well in comment:4. > > Very well; but I really dislike messing with `matchInstEnv`. Better: make `mathKnownNat` have an `otherwise` case that, instead of returning `NoInstance` uses `matchInstEnv`. With a careful `Note` to explain. > Okey I will think about it and try it out. The only thing puzzling for me is that the old code is returning Overlapping instances, which to me appears to be finding too many instances rather than finding too few. So there is some problem with my comment:4 which I cannot really pin-point. > [snip] > > But `Typeable` can fail; I wonder if you might end up wanting a `Typeable` instance in a `hsig` file. I think that's all... but the big point is that GHC's treatment of built-in classes may need attention because of Backpack; KnownNat is just an example. Again the `Typeable` instances in backpack works fine //even with the old version// of the code (unlike `KnownNat` or `KnownSymbol`). In fact, I realised and has tweaked the test case to have all the three problematic classes (KnownNat, KnownSymbol and Typeable) but only the first two was giving the overlapping instance error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 18:14:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 18:14:06 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <060.60257637e2aa16c27aef5fb8190c2303@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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 ppk): Okey I think I see where the Overlapping instances come from in the case of KnownNat and KnownSymbol. Let me take the following code sample {{{#!haskell signature Abstract where data Foo :: Nat instance KnownNat Foo module Util where import Abstract foo = natVal (Proxy :: Proxy Foo) module Concrete where type Foo = Int module Main where {- mixin Concrete and get the ConcreteUtil -} }}} In the main module there are two dictionaries for `KnownNat Foo`, one which comes via Util (which incidently is actually coming from Concrete and the other directly coming from Concrete. But these two are "different" in the sense that the old code generates KnownNat on the fly and these two generations manifest as two different instances. Is there some way this hypothesis can be tested out say be tracing the compilation for the example ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 18:28:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 18:28:44 -0000 Subject: [GHC] #15413: Poor error message when trying to import non-existent class methods Message-ID: <057.fe732ba2a4ee42f10d59fc52f46c8bd8@haskell.org> #15413: Poor error message when trying to import non-existent class methods -------------------------------------+------------------------------------- Reporter: | Owner: (none) quasicomputational | Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- {{{ $ cat A.hs module A where class C a where foo :: a -> Int bar :: a -> Int $ cat B.hs module B where import A (C (foo, bar, baz)) instance C Int where foo = id bar = id $ ghci B.hs GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling A ( A.hs, interpreted ) [2 of 2] Compiling B ( B.hs, interpreted ) B.hs:3:11: error: Module ‘A’ does not export ‘C(foo, bar, baz)’ | 3 | import A (C (foo, bar, baz)) | ^^^^^^^^^^^^^^^^^ Failed, one module loaded. }}} If you're importing a dozen or so methods, not mentioning the specific method that couldn't be imported gets quite annoying. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 18:38:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 18:38:26 -0000 Subject: [GHC] #15414: Why both gen and gen_no in bdescr? Message-ID: <046.3e22919acbe44581425bc44a28f802be@haskell.org> #15414: Why both gen and gen_no in bdescr? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime | Version: 8.4.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Block descriptors currently contain both `gen` (a `generation *`) and `gen_no` (a `uint16_t, which is `gen->no` cached). I wonder whether it would be worthwhile to drop the former and always use `generations[bd->gen_no]`. Afterall, this would save an entire word per descriptor which may improve our caches' coverage of the bdescr region appreciably. Presumably the `generations` array would be hot enough to stay in cache in such a scheme, so I would guess that the cost would be small-ish. Simon, have you measured this in the past? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 18:38:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 18:38:44 -0000 Subject: [GHC] #15414: Why both gen and gen_no in bdescr? In-Reply-To: <046.3e22919acbe44581425bc44a28f802be@haskell.org> References: <046.3e22919acbe44581425bc44a28f802be@haskell.org> Message-ID: <061.0cbf76b9e558b3be6184fa93128c61f5@haskell.org> #15414: Why both gen and gen_no in bdescr? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Block descriptors currently contain both `gen` (a `generation *`) and > `gen_no` (a `uint16_t, which is `gen->no` cached). I wonder whether it > would be worthwhile to drop the former and always use > `generations[bd->gen_no]`. Afterall, this would save an entire word per > descriptor which may improve our caches' coverage of the bdescr region > appreciably. Presumably the `generations` array would be hot enough to > stay in cache in such a scheme, so I would guess that the cost would be > small-ish. > > Simon, have you measured this in the past? New description: Block descriptors currently contain both `gen` (a `generation *`) and `gen_no` (a `uint16_t`, which is `gen->no` cached). I wonder whether it would be worthwhile to drop the former and always use `generations[bd->gen_no]`. Afterall, this would save an entire word per descriptor which may improve our caches' coverage of the bdescr region appreciably. Presumably the `generations` array would be hot enough to stay in cache in such a scheme, so I would guess that the cost would be small-ish. Simon, have you measured this in the past? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 20:26:39 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 20:26:39 -0000 Subject: [GHC] #15313: Framework failures on windows with plugins In-Reply-To: <046.f52c74aebbb7c1bfb16082509fa8f952@haskell.org> References: <046.f52c74aebbb7c1bfb16082509fa8f952@haskell.org> Message-ID: <061.719cc64c68573dc81968bfcb12e55f05@haskell.org> #15313: Framework failures on windows with plugins -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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:D4918 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"b290f15c4d01d45c41c02ae5c5333a1fab022a32/ghc" b290f15c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b290f15c4d01d45c41c02ae5c5333a1fab022a32" testsuite: force plugin tests sequentially on Windows. Summary: Package registration does not seem to be thread-safe on Windows. Placing the system under heavily load seems to trigger registration failures even though they are all different package-dbs. This makes the plugin tests a bit flaky. I think this is because on Windows we use pessimistic locks while on Linux we use atomic file replacement. On Windows ReplaceFile is atomic, just the metadata write may not be. Since the metadata is not of importance we should either switch over to ReplaceFile or fix the locking code to not error out but wait. For now however I have to force these 25 tests to run serially in order to guarantee their correctness. Test Plan: ./validate Reviewers: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15313, #13194 Differential Revision: https://phabricator.haskell.org/D4918 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 20:26:39 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 20:26:39 -0000 Subject: [GHC] #15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7 In-Reply-To: <048.2e4683ede5797175b196c3bdda927d9f@haskell.org> References: <048.2e4683ede5797175b196c3bdda927d9f@haskell.org> Message-ID: <063.7e1ecb205a97c45e256cfd0dbcd8e858@haskell.org> #15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7 -------------------------------------+------------------------------------- Reporter: ki11men0w | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: Component: ghc-pkg | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4917 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"d0bbe1bf351c8b85c310afb0dd1fb1f12f9474bf/ghc" d0bbe1bf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d0bbe1bf351c8b85c310afb0dd1fb1f12f9474bf" stack: fix stack allocations on Windows Summary: On Windows one is not allowed to drop the stack by more than a page size. The reason for this is that the OS only allocates enough stack till what the TEB specifies. After that a guard page is placed and the rest of the virtual address space is unmapped. The intention is that doing stack allocations will cause you to hit the guard which will then map the next page in and move the guard. This is done to prevent what in the Linux world is known as stack clash vulnerabilities https://access.redhat.com/security/cve/cve-2017-1000364. There are modules in GHC for which the liveliness analysis thinks the reserved 8KB of spill slots isn't enough. One being DynFlags and the other being Cabal. Though I think the Cabal one is likely a bug: ``` 4d6544: 81 ec 00 46 00 00 sub $0x4600,%esp 4d654a: 8d 85 94 fe ff ff lea -0x16c(%ebp),%eax 4d6550: 3b 83 1c 03 00 00 cmp 0x31c(%ebx),%eax 4d6556: 0f 82 de 8d 02 00 jb 4ff33a <_cLpg_info+0x7a> 4d655c: c7 45 fc 14 3d 50 00 movl $0x503d14,-0x4(%ebp) 4d6563: 8b 75 0c mov 0xc(%ebp),%esi 4d6566: 83 c5 fc add $0xfffffffc,%ebp 4d6569: 66 f7 c6 03 00 test $0x3,%si 4d656e: 0f 85 a6 d7 02 00 jne 503d1a <_cLpb_info+0x6> 4d6574: 81 c4 00 46 00 00 add $0x4600,%esp ``` It allocates nearly 18KB of spill slots for a simple 4 line function and doesn't even use it. Note that this doesn't happen on x64 or when making a validate build. Only when making a build without a validate and build.mk. This and the allocation in DynFlags means the stack allocation will jump over the guard page into unmapped memory areas and GHC or an end program segfaults. The pagesize on x86 Windows is 4KB which means we hit it very easily for these two modules, which explains the total DOA of GHC 32bit for the past 3 releases and the "random" segfaults on Windows. ``` 0:000> bp 00503d29 0:000> gn Breakpoint 0 hit WARNING: Stack overflow detected. The unwound frames are extracted from outside normal stack bounds. eax=03b6b9c9 ebx=00dc90f0 ecx=03cac48c edx=03cac43d esi=03b6b9c9 edi=03abef40 eip=00503d29 esp=013e96fc ebp=03cf8f70 iopl=0 nv up ei pl nz na po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202 setup+0x103d29: 00503d29 89442440 mov dword ptr [esp+40h],eax ss:002b:013e973c=???????? WARNING: Stack overflow detected. The unwound frames are extracted from outside normal stack bounds. WARNING: Stack overflow detected. The unwound frames are extracted from outside normal stack bounds. 0:000> !teb TEB at 00384000 ExceptionList: 013effcc StackBase: 013f0000 StackLimit: 013eb000 ``` This doesn't fix the liveliness analysis but does fix the allocations, by emitting a function call to `__chkstk_ms` when doing allocations of larger than a page, this will make sure the stack is probed every page so the kernel maps in the next page. `__chkstk_ms` is provided by `libGCC`, which is under the `GNU runtime exclusion license`, so it's safe to link against it, even for proprietary code. (Technically we already do since we link compiled C code in.) For allocations smaller than a page we drop the stack and probe the new address. This avoids the function call and still makes sure we hit the guard if needed. PS: In case anyone is Wondering why we didn't notice this before, it's because we only test x86_64 and on Windows 10. On x86_64 the page size is 8KB and also the kernel is a bit more lenient on Windows 10 in that it seems to catch the segfault and resize the stack if it was unmapped: ``` 0:000> t eax=03b6b9c9 ebx=00dc90f0 ecx=03cac48c edx=03cac43d esi=03b6b9c9 edi=03abef40 eip=00503d2d esp=013e96fc ebp=03cf8f70 iopl=0 nv up ei pl nz na po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202 setup+0x103d2d: 00503d2d 8b461b mov eax,dword ptr [esi+1Bh] ds:002b:03b6b9e4=03cac431 0:000> !teb TEB at 00384000 ExceptionList: 013effcc StackBase: 013f0000 StackLimit: 013e9000 ``` Likely Windows 10 has a guard page larger than previous versions. This fixes the stack allocations, and as soon as I get the time I will look at the liveliness analysis. I find it highly unlikely that simple Cabal function requires ~2200 spill slots. Test Plan: ./validate Reviewers: simonmar, bgamari Reviewed By: bgamari Subscribers: AndreasK, rwbarton, thomie, carter GHC Trac Issues: #15154 Differential Revision: https://phabricator.haskell.org/D4917 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 20:26:39 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 20:26:39 -0000 Subject: [GHC] #13194: Concurrent modifications of package.cache are not safe In-Reply-To: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> References: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> Message-ID: <062.bb992797ddce50e1c572481cdda26f47@haskell.org> #13194: Concurrent modifications of package.cache are not safe -------------------------------------+------------------------------------- Reporter: arybczak | Owner: arybczak Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13354, #13375, | Differential Rev(s): Phab:D3090 #14017 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"b290f15c4d01d45c41c02ae5c5333a1fab022a32/ghc" b290f15c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b290f15c4d01d45c41c02ae5c5333a1fab022a32" testsuite: force plugin tests sequentially on Windows. Summary: Package registration does not seem to be thread-safe on Windows. Placing the system under heavily load seems to trigger registration failures even though they are all different package-dbs. This makes the plugin tests a bit flaky. I think this is because on Windows we use pessimistic locks while on Linux we use atomic file replacement. On Windows ReplaceFile is atomic, just the metadata write may not be. Since the metadata is not of importance we should either switch over to ReplaceFile or fix the locking code to not error out but wait. For now however I have to force these 25 tests to run serially in order to guarantee their correctness. Test Plan: ./validate Reviewers: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15313, #13194 Differential Revision: https://phabricator.haskell.org/D4918 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 20:28:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 20:28:33 -0000 Subject: [GHC] #13194: Concurrent modifications of package.cache are not safe In-Reply-To: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> References: <047.10ce9b12130c429e6fb9d0ffa5a41d0f@haskell.org> Message-ID: <062.aa2221da8a573e058c0b395d6f778222@haskell.org> #13194: Concurrent modifications of package.cache are not safe -------------------------------------+------------------------------------- Reporter: arybczak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13354, #13375, | Differential Rev(s): Phab:D3090 #14017 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: arybczak => (none) * status: closed => new * resolution: fixed => Comment: This seems to still have some issues on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 20:29:53 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 20:29:53 -0000 Subject: [GHC] #15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7 In-Reply-To: <048.2e4683ede5797175b196c3bdda927d9f@haskell.org> References: <048.2e4683ede5797175b196c3bdda927d9f@haskell.org> Message-ID: <063.42b347d364929272684f83ef3286ac43@haskell.org> #15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7 -------------------------------------+------------------------------------- Reporter: ki11men0w | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: ghc-pkg | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4917 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => merge * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 20:34:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 20:34:06 -0000 Subject: [GHC] #15357: Make nofib suitable for runtime measurements. In-Reply-To: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> References: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> Message-ID: <062.1aed30c61714a1978c3dddc25e20ad49@haskell.org> #15357: Make nofib suitable for runtime measurements. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: NoFib benchmark | Version: 8.4.3 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): So I also remembered today that nofib-analysis by default ignores results faster than 0.2s for the summary. Which is 91 out of 113 Benchmarks in the above run. I will write up a patch that at least updates speeds for normal mode on the benchmarks where it seems easy/useful to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 20:54:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 20:54:28 -0000 Subject: [GHC] #15384: Every implication should bump the TcLevel exactly once In-Reply-To: <047.d56843a5a9456b5500d56ec561e931f3@haskell.org> References: <047.d56843a5a9456b5500d56ec561e931f3@haskell.org> Message-ID: <062.bb4cd7454b7c3c66f482225d427aa8eb@haskell.org> #15384: Every implication should bump the TcLevel exactly once -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Tritlo, I see you've added yourself in cc. Yes, I think this is probably a bug in the valid-hole-fits code. Could you look at it? If you get stuck, or think it's not your code, do get back to me. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 20:56:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 20:56:43 -0000 Subject: [GHC] #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. In-Reply-To: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> References: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> Message-ID: <066.1b6e7c61b9f346abde69d2ef7c54ef01@haskell.org> #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. ---------------------------------+-------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | 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: | ---------------------------------+-------------------------------------- Comment (by simonpj): > it's far from clear to me how to implement it I think the right thing to do is probably to capture the `DynFlags` in an `Implication`. We already capture the `TcLclEnv` in `ic_env`; capturing the `DynFlags` too would be easy. Then the `DynFlags` would be conveniently to hand when generating the innaccessible-code warning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 20:57:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 20:57:11 -0000 Subject: [GHC] #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. In-Reply-To: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> References: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> Message-ID: <066.54c66b330fea7beded10b5d338d32642@haskell.org> #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving, | PatternMatchWarnings 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => deriving, PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 21:01:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 21:01:47 -0000 Subject: [GHC] #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. In-Reply-To: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> References: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> Message-ID: <066.8deaaaca5ef9105269d24be62ff67fd3@haskell.org> #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving, | PatternMatchWarnings 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I don't understand what `DynFlags` has to do with anything. `-Wno- inaccesible-code` already disables these warnings. I thought you were requesting that we //never// emit inaccessible code warnings for derived code (regardless of whether `-Winaccessible-code` is enabled or not). That's what I don't know how to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 21:11:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 21:11:44 -0000 Subject: [GHC] #15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7 In-Reply-To: <048.2e4683ede5797175b196c3bdda927d9f@haskell.org> References: <048.2e4683ede5797175b196c3bdda927d9f@haskell.org> Message-ID: <063.c17fe4f79da42e8e315411f2947ef39e@haskell.org> #15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7 -------------------------------------+------------------------------------- Reporter: ki11men0w | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: ghc-pkg | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4917 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Blimey. Amazing fix. Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 21:22:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 21:22:05 -0000 Subject: [GHC] #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. In-Reply-To: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> References: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> Message-ID: <066.ef3114670a6e165e4ff62f158f872193@haskell.org> #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving, | PatternMatchWarnings 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: | -------------------------------------+------------------------------------- Comment (by simonpj): > I thought you were requesting that we never emit inaccessible code warnings for derived code (regardless of whether -Winaccessible-code is enabled or not). Correct. So if we switch off `-Winaccessible-code` when typechecking derived code, that would do job. And we try to; see {{{ -- Now GHC-generated derived bindings, generics, and selectors -- Do not generate warnings from compiler-generated code; -- hence the use of discardWarnings tc_envs@(tcg_env, tcl_env) <- discardWarnings (tcTopBinds deriv_binds deriv_sigs) ; }}} in `TcRnDriver`. Unfortunately the `dicardWarnings` only discards warnings generated while doing `tcTopBinds`. But `tcTopBinds` also creates a bunch of constraints that don't "see" that `discardWarnings`. If instead switched off the warning `DynFlags`, and captured the `DynFlags` in an implication, the warning suppression would still work on the constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 22:06:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 22:06:32 -0000 Subject: [GHC] #15384: Every implication should bump the TcLevel exactly once In-Reply-To: <047.d56843a5a9456b5500d56ec561e931f3@haskell.org> References: <047.d56843a5a9456b5500d56ec561e931f3@haskell.org> Message-ID: <062.01ac57545d76249d2909f21bd321a991@haskell.org> #15384: Every implication should bump the TcLevel exactly once -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): Will do! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 18 22:26:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 18 Jul 2018 22:26:13 -0000 Subject: [GHC] #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 In-Reply-To: <047.0e132514379b72c39d1662f2412d5748@haskell.org> References: <047.0e132514379b72c39d1662f2412d5748@haskell.org> Message-ID: <062.9ebe2911dd29840e6d3f349f3160057a@haskell.org> #15338: ghc-pkg misbehaves after possible miscompilation on m68k and sh4 -------------------------------------+------------------------------------- Reporter: glaubitz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4959 Wiki Page: | -------------------------------------+------------------------------------- Comment (by glaubitz): Ok, looks like just adding the patch but not changing the optimization level addresses the build issue with haskell-ansi-wl-pprint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 00:39:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 00:39:28 -0000 Subject: [GHC] #15415: GHCi's :kind doesn't work with wildcards Message-ID: <047.9324d649243992c743ffcce486b06b5a@haskell.org> #15415: GHCi's :kind doesn't work with wildcards -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Witness this GHCi session: {{{ rae:20:35:37 ~/ghc/ghc-head/ghc> ~/ghc/ghc-head/inplace/bin/ghc-stage2 --interactive GHCi, version 8.7.20180716: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/rae/.ghc/ghci.conf Prelude> :set -XPartialTypeSignatures Prelude> import Data.Proxy Prelude Data.Proxy> :k Proxy _ Proxy _ :: * Prelude Data.Proxy> :k Proxy (Maybe :: _) :1:8: error: • Expecting one more argument to ‘Maybe’ Expected kind ‘_’, but ‘Maybe’ has kind ‘* -> *’ • In the first argument of ‘Proxy’, namely ‘(Maybe :: _)’ In the type ‘Proxy (Maybe :: _)’ }}} It seems we're not doing the correct wildcard thing here: GHCi should report that `_` should be `Type -> Type`. I believe that this is because `TcHsType.tcWildCardBinders` uses `newSkolemTyVar` internally; `tcWildCardBinders` is called from `TcRnDriver.tcRnType`, which is the implementation of GHCi's `:kind`. This is GHC's only call of `tcWildCardBinders`. All other places use `tcWildCardBindersX newWildTyVar`, which makes vastly more sense. I would just fix this myself, but it smells intentional. Does anyone know why we have all this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 00:40:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 00:40:07 -0000 Subject: [GHC] #15415: GHCi's :kind doesn't work with wildcards In-Reply-To: <047.9324d649243992c743ffcce486b06b5a@haskell.org> References: <047.9324d649243992c743ffcce486b06b5a@haskell.org> Message-ID: <062.1fa20501a6964716c759ac8376ea463f@haskell.org> #15415: GHCi's :kind doesn't work with wildcards -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by goldfire: Old description: > Witness this GHCi session: > > {{{ > rae:20:35:37 ~/ghc/ghc-head/ghc> ~/ghc/ghc-head/inplace/bin/ghc-stage2 > --interactive > GHCi, version 8.7.20180716: http://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /Users/rae/.ghc/ghci.conf > Prelude> :set -XPartialTypeSignatures > Prelude> import Data.Proxy > Prelude Data.Proxy> :k Proxy _ > Proxy _ :: * > Prelude Data.Proxy> :k Proxy (Maybe :: _) > > :1:8: error: > • Expecting one more argument to ‘Maybe’ > Expected kind ‘_’, but ‘Maybe’ has kind ‘* -> *’ > • In the first argument of ‘Proxy’, namely ‘(Maybe :: _)’ > In the type ‘Proxy (Maybe :: _)’ > }}} > > It seems we're not doing the correct wildcard thing here: GHCi should > report that `_` should be `Type -> Type`. > > I believe that this is because `TcHsType.tcWildCardBinders` uses > `newSkolemTyVar` internally; `tcWildCardBinders` is called from > `TcRnDriver.tcRnType`, which is the implementation of GHCi's `:kind`. > This is GHC's only call of `tcWildCardBinders`. All other places use > `tcWildCardBindersX newWildTyVar`, which makes vastly more sense. > > I would just fix this myself, but it smells intentional. Does anyone know > why we have all this? New description: Witness this GHCi session: {{{ rae:20:35:37 ~/ghc/ghc-head/ghc> ~/ghc/ghc-head/inplace/bin/ghc-stage2 --interactive GHCi, version 8.7.20180716: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/rae/.ghc/ghci.conf Prelude> :set -XPartialTypeSignatures Prelude> import Data.Proxy Prelude Data.Proxy> :k Proxy _ Proxy _ :: * Prelude Data.Proxy> :k Proxy (Maybe :: _) :1:8: error: • Expecting one more argument to ‘Maybe’ Expected kind ‘_’, but ‘Maybe’ has kind ‘* -> *’ • In the first argument of ‘Proxy’, namely ‘(Maybe :: _)’ In the type ‘Proxy (Maybe :: _)’ }}} It seems we're not doing the correct wildcard thing here: GHCi should report that `_` should be `Type -> Type`. I believe that this is because `TcHsType.tcWildCardBinders` uses `newSkolemTyVar` internally; `tcWildCardBinders` is called from `TcRnDriver.tcRnType`, which is the implementation of GHCi's `:kind`. This is GHC's only call of `tcWildCardBinders`. All other places use `tcWildCardBindersX newWildTyVar`, which makes vastly more sense. I would just fix this myself, but it smells intentional. Does anyone know why we have all this? (Credit to @int-index who found this bug.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 02:24:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 02:24:39 -0000 Subject: [GHC] #15380: Infinite typechecker loop in GHC 8.6 In-Reply-To: <050.ceee7eb83a4946e532604b8e627271f4@haskell.org> References: <050.ceee7eb83a4946e532604b8e627271f4@haskell.org> Message-ID: <065.726a0dcfe25bbc48b7e1449c327f3049@haskell.org> #15380: Infinite typechecker loop in GHC 8.6 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4974 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The patch now validates, but waiting for Simon's review before committing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 03:02:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 03:02:34 -0000 Subject: [GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 In-Reply-To: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> References: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> Message-ID: <066.d18d3de6606b6d87256e084222acca3b@haskell.org> #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NathanWaivio): I have found an undocumented flag: "-fno-worker-wrapper". When enabled the original code compiles in 43.20 seconds (37x improvement in time), and uses 660MB max (48x improvement in space) with GHC 8.4.2. All of the tests pass for the library and the benchmark still performs at the improved speed. It seems like the Worker/Wrapper Transformation is causing issues with this code. Why is that? Perhaps Worker/Wrapper shouldn't be run in certain circumstances. What do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 03:45:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 03:45:49 -0000 Subject: [GHC] #15415: GHCi's :kind doesn't work with wildcards In-Reply-To: <047.9324d649243992c743ffcce486b06b5a@haskell.org> References: <047.9324d649243992c743ffcce486b06b5a@haskell.org> Message-ID: <062.42bb46bd8144789d255398b3be797c9c@haskell.org> #15415: GHCi's :kind doesn't work with wildcards -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 04:09:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 04:09:51 -0000 Subject: [GHC] #12606: Linux (ELF) Support for "ghc -static -shared" In-Reply-To: <046.d447037062698bef3ad5e600ea6fd991@haskell.org> References: <046.d447037062698bef3ad5e600ea6fd991@haskell.org> Message-ID: <061.a3f04d0a2c67baf2f3b85950ac9f1d7c@haskell.org> #12606: Linux (ELF) Support for "ghc -static -shared" -------------------------------------+------------------------------------- Reporter: tmobile | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Resolution: wontfix | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tmobile): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 05:28:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 05:28:41 -0000 Subject: [GHC] #12045: Visible kind application In-Reply-To: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> References: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> Message-ID: <066.79d060e9151239e79ddccefd0e75e198@haskell.org> #12045: Visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mnguyen Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications TypeInType | GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ​Phab:D2216 Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 05:52:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 05:52:39 -0000 Subject: [GHC] #15415: GHCi's :kind doesn't work with wildcards In-Reply-To: <047.9324d649243992c743ffcce486b06b5a@haskell.org> References: <047.9324d649243992c743ffcce486b06b5a@haskell.org> Message-ID: <062.5b1a438afd94c103bf0cbd429b36d6b4@haskell.org> #15415: GHCi's :kind doesn't work with wildcards -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: simonpj (added) Comment: The patch that introduced this distinction is 15b9bf4ba4ab47e6809bf2b3b36ec16e502aea72. Simon, do you remember why you decided to separate `tcWildCardBinders` and `tcWildCardBindersX`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 09:15:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 09:15:05 -0000 Subject: [GHC] #15411: urk! lookup local fingerprint In-Reply-To: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> References: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> Message-ID: <060.a23a62ee4d7dbfa3e97c75f740f3167e@haskell.org> #15411: urk! lookup local fingerprint -------------------------------------+------------------------------------- Reporter: admock | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15399 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): Perhaps we can coordinate our efforts. In #15399 I am currently bisecting between changeset:d78dde9 (good) and changeset:ec22f7dd (with changeset:bdfc85b applied to fix validate). A commit in that range broke quite a few GHCi tests on PPC64 but not PPC64le. I wonder if you could help bisect from changeset:bdfc85b (good) to HEAD of 8.6.1-alpha2 (bad) and either find a commit that fixed GHCi (if one exists) or find the commit that is responsible for the breakage reported in this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 09:45:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 09:45:18 -0000 Subject: [GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 In-Reply-To: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> References: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> Message-ID: <066.7484c6e8273b51efd5bc918ddd1afea2@haskell.org> #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Sounds like a promising lead, if not the key to figuring this out. Worker/wrapper is generally a good thing to do; in theory, all it should do is turn arguments to recursive function calls closures, thus reducing the argument-passing overhead. But I can imagine that this would also get in the way of inlinings and `RULES`. So what we're looking for is code that follows the pattern that makes it a candidate for worker/wrapper optimization (parameters passed through recursive calls unchanged), such that the worker/wrapper optimization breaks up expressions that might otherwise trigger useful inlinings or rewrites. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 10:29:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 10:29:56 -0000 Subject: [GHC] #15064: T8089 mysteriously fails when GHC is built with LLVM In-Reply-To: <046.7f8c4e91c0adf39423142484582ab39d@haskell.org> References: <046.7f8c4e91c0adf39423142484582ab39d@haskell.org> Message-ID: <061.ba916bd557d285b7c3b7ef21894a1462@haskell.org> #15064: T8089 mysteriously fails when GHC is built with LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (LLVM) | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Can't reproduce locally. Can you share the circleci link that shows the failure? What version of llvm does circleci use? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 10:30:12 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 10:30:12 -0000 Subject: [GHC] #1965: Allow unconstrained existential contexts in newtypes In-Reply-To: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> References: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> Message-ID: <059.cc28577382410ef14638bb71d3fc1874@haskell.org> #1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 10:55:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 10:55:32 -0000 Subject: [GHC] #15414: Why both gen and gen_no in bdescr? In-Reply-To: <046.3e22919acbe44581425bc44a28f802be@haskell.org> References: <046.3e22919acbe44581425bc44a28f802be@haskell.org> Message-ID: <061.bada2965fa2a44e7baffc8bcaa1eb496@haskell.org> #15414: Why both gen and gen_no in bdescr? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): IIRC originally we had just the `bd->gen`, and adding `bd->gen_no` was a small optimisation because it saved a few instructions in the inner loop (`evacuate()`). I'm not sure I tried removing `bd->gen`, but I can always be persuaded of anything by data :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 12:08:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 12:08:31 -0000 Subject: [GHC] #15416: Higher rank types in pattern synonyms Message-ID: <044.53c8e12910c3cdd85f926a53a436c321@haskell.org> #15416: Higher rank types in pattern synonyms -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE RankNTypes, PatternSynonyms, ViewPatterns #-} }}} Consider the following two pattern synonyms: {{{#!hs pattern N :: () => () => forall r. r -> (a -> r) -> r pattern N <- ((\f -> f Nothing Just) -> Nothing) where N = \n j -> n pattern J :: a -> forall r. r -> (a -> r) -> r pattern J x <- ((\f -> f Nothing Just) -> Just x) where J x = \n j -> j x }}} The pattern synonym type declaration syntax is very fragile and awkward wrt quantifiers but that's a story for another ticket. Now consider four ways to write the same function: using pattern synonyms we've defined above vs. using the exact view patterns they were defiend with; and using a series of equations vs. an explicit `case of`: {{{#!hs fooVPEqns, fooVPCase, fooPSEqns, fooPSCase :: (forall r. r -> (a -> r) -> r) -> Maybe a fooVPEqns ((\f -> f Nothing Just) -> Nothing) = Nothing fooVPEqns ((\f -> f Nothing Just) -> Just x) = Just x fooVPCase v = case v of ((\f -> f Nothing Just) -> Nothing) -> Nothing ((\f -> f Nothing Just) -> Just x) -> Just x fooPSEqns N = Nothing fooPSEqns (J x) = Just x fooPSCase v = case v of N -> Nothing J x -> Just x }}} Three of these compile and work fine, the fourth breaks: {{{#!hs QuantPatSyn.hs:22:9: error: • Couldn't match expected type ‘r0 -> (a -> r0) -> r0’ with actual type ‘forall r. r -> (a0 -> r) -> r’ • In the pattern: N In a case alternative: N -> Nothing In the expression: case v of N -> Nothing J x -> Just x • Relevant bindings include v :: forall r. r -> (a -> r) -> r (bound at QuantPatSyn.hs:21:11) fooPSCase :: (forall r. r -> (a -> r) -> r) -> Maybe a (bound at QuantPatSyn.hs:21:1) | 22 | N -> Nothing | ^ QuantPatSyn.hs:23:9: error: • Couldn't match expected type ‘r0 -> (a -> r0) -> r0’ with actual type ‘forall r. r -> (a -> r) -> r’ • In the pattern: J x In a case alternative: J x -> Just x In the expression: case v of N -> Nothing J x -> Just x • Relevant bindings include v :: forall r. r -> (a -> r) -> r (bound at QuantPatSyn.hs:21:11) fooPSCase :: (forall r. r -> (a -> r) -> r) -> Maybe a (bound at QuantPatSyn.hs:21:1) | 23 | J x -> Just x | ^^^ }}} The exact wording of the error message (the appearance of `forall` in the "actual type") makes me think this is an error on the typechecker's side: the part of the typechecker that handles pattern synonyms doesn't handle higher rank types correctly. Another symptom can be observed with the following: {{{#!hs pattern V :: Void -> (forall r. r) pattern V x <- ((\f -> f) -> x) where V x = absurd x barVPEqns, barVPCase, barPSEqns, barPSCase :: (forall r. r) -> Void barVPEqns ((\f -> f) -> x) = x barVPCase v = case v of ((\f -> f) -> x) -> x barPSEqns (V x) = x barPSCase v = case v of V x -> x }}} {{{#!hs QuantPatSyn.hs:43:9: error: • Cannot instantiate unification variable ‘r0’ with a type involving foralls: forall r. r GHC doesn't yet support impredicative polymorphism • In the pattern: V x In a case alternative: V x -> x In the expression: case v of { V x -> x } | 43 | V x -> x | ^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 13:00:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 13:00:33 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <060.99bfaca6720319bae4bd473315224c52@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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): Phab:D4988 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ppk): * differential: => Phab:D4988 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 13:11:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 13:11:32 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <060.186be5833247fdc638a414532b3c73a5@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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): Phab:D4988 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ppk): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 14:39:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 14:39:44 -0000 Subject: [GHC] #15417: Memory leaks because of too conservative isAlive check in the GC Message-ID: <043.238b597548438e23acfb3d75b5cc5e97@haskell.org> #15417: Memory leaks because of too conservative isAlive check in the GC -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research needed Component: Runtime | Version: 8.5 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: -------------------------------------+------------------------------------- (See also the mailing list [https://mail.haskell.org/pipermail/ghc- devs/2018-July/016027.html thread]) Static objects with no SRTs and pointer fields are currently ignored by `evacuate()`. This is efficient but causes trouble when checking alive- ness of static objects in `isAlive()`, which is used for (among other things) checking whether a weak's key has died. This causes leaks as value of a weak with static key will always be kept alive. Here's a demonstration: {{{#!haskell module Main where import System.Mem.Weak (mkWeak, deRefWeak) import System.Mem (performMajorGC) mkKey :: IO String mkKey = readFile "/dev/random" -- mkKey :: IO Int -- mkKey = return 1 main :: IO () main = do w <- mkKey >>= \k -> mkWeak k () Nothing performMajorGC performMajorGC performMajorGC deRefWeak w >>= print }}} The idea is that the first `mkKey` function returns a non-static string and this program prints `Nothing`. If I enable the second `mkKey` function the key is now a static object and the program prints `Just ()`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 14:40:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 14:40:31 -0000 Subject: [GHC] #15417: Memory leaks in the GC due to static object collection (was: Memory leaks because of too conservative isAlive check in the GC) In-Reply-To: <043.238b597548438e23acfb3d75b5cc5e97@haskell.org> References: <043.238b597548438e23acfb3d75b5cc5e97@haskell.org> Message-ID: <058.c96971479651e6f900523de643c1f708@haskell.org> #15417: Memory leaks in the GC due to static object collection -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research | needed Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 15:40:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 15:40:00 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.c1c5fa8f7e76ac5fd7d5915b668fecd6@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Drilling down some more, I found that the biggest performance sink is `tcPolyInfer`, in both the pre- and post-patch versions; in both cases, it is responsible for just over 50% of allocations, but in terms of runtime, it's 36% before the patch, but 45% after - so that alone would explain a 5% performance deviation. Further data points: - On the first run after making a fresh build, `withCleanupSession.cleanup` shows up prominently, but from the second run onwards, it scores 0 on all metrics. - Overall performance for profile builds is such that the patch does actually produce a performance improvement, from approx. 1.25 seconds down to 1.07. - The patch does not touch `tcPolyInfer` at all, the entire module is identical between both versions - The performance counters suggests that code paths taken inside `tcPolyInfer` are the same -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 15:42:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 15:42:10 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.ca7bd3d168530967ea779647f8a38c6f@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * Attachment "logs.tar.gz" added. Performance logs for comparison -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 16:32:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 16:32:19 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.27db8c69adaf7fa2440b37e49cb479b9@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Given what you've found so far, I feel sure that the problems stem from the changes in `TyCoRep`. But I'm curious to see what else you find! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 17:21:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 17:21:42 -0000 Subject: [GHC] #15357: Make nofib suitable for runtime measurements. In-Reply-To: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> References: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> Message-ID: <062.6cc3bd3cb6a86b1ad621834ddd7d54f5@haskell.org> #15357: Make nofib suitable for runtime measurements. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: NoFib benchmark | Version: 8.4.3 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): Phab:D4989 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * status: new => patch * differential: => Phab:D4989 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 17:24:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 17:24:14 -0000 Subject: [GHC] #5793: make nofib awesome In-Reply-To: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> References: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> Message-ID: <060.f7135ef50fc9a04502db0086f3ae4f0e@haskell.org> #5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: michalt Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9571 | Blocking: Related Tickets: #15357 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * related: => #15357 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 17:24:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 17:24:42 -0000 Subject: [GHC] #15357: Make nofib suitable for runtime measurements. In-Reply-To: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> References: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> Message-ID: <062.f81a81f01558ff6efe032195fb59dba4@haskell.org> #15357: Make nofib suitable for runtime measurements. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: NoFib benchmark | Version: 8.4.3 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 | Differential Rev(s): Phab:D4989 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * related: => #5793 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 20:13:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 20:13:34 -0000 Subject: [GHC] #15418: Performance drop 60 times on non-profiling binary Message-ID: <045.a055029aec148ca416c29df30694b018@haskell.org> #15418: Performance drop 60 times on non-profiling binary ----------------------------------------+--------------------------------- Reporter: hth313 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 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: ----------------------------------------+--------------------------------- I have a rather large application that I have spent quite some time on tuning it as performance is just too bad. I have come to a point where the profiler reports about 14 seconds on a particular example, which is about 5x slower than I would like to see. However, building the same binary without profiling ability results in that the example takes 14 _minutes_. If I just touch a file and build with profiling information, but not giving it any profiling related RTS options, it takes about 30 seconds (not 14 seconds, but that is probably due to profiling overhead being there). How can performance drop 60x when I basically just relink it? From what I can see using "top" and memory profiling, memory consumption is quite stable over time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 20:43:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 20:43:17 -0000 Subject: [GHC] #15419: GHC 8.6.1 regression (buildKindCoercion) Message-ID: <050.8c636ff7b7100012a49f9742f3f82864@haskell.org> #15419: GHC 8.6.1 regression (buildKindCoercion) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program typechecks on GHC 8.4.1, but panics on GHC 8.6.1 and HEAD: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Kind data family Sing :: forall k. k -> Type data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 data instance Sing :: forall a b. (a, b) -> Type where STuple2 :: Sing x -> Sing y -> Sing '(x, y) newtype instance Sing (f :: k1 ~> k2) = SLambda { applySing :: forall t. Sing t -> Sing (f `Apply` t) } ----- newtype Par1 p = Par1 p newtype K1 c p = K1 c data (f :*: g) p = f p :*: g p data instance Sing :: forall p. Par1 p -> Type where SPar1 :: Sing x -> Sing ('Par1 x) data instance Sing :: forall k c (p :: k). K1 c p -> Type where SK1 :: Sing x -> Sing ('K1 x) data instance Sing :: forall k (f :: k -> Type) (g :: k -> Type) (p :: k). (f :*: g) p -> Type where (:%*:) :: Sing x -> Sing y -> Sing (x ':*: y) class Generic1 (f :: k -> Type) where type Rep1 f :: k -> Type from1 :: f a -> Rep1 f a to1 :: Rep1 f a -> f a class PGeneric1 (f :: k -> Type) where type From1 (z :: f a) :: Rep1 f a type To1 (z :: Rep1 f a) :: f a class SGeneric1 (f :: k -> Type) where sFrom1 :: forall (a :: k) (z :: f a). Sing z -> Sing (From1 z) sTo1 :: forall (a :: k) (r :: Rep1 f a). Sing r -> Sing (To1 r :: f a) instance Generic1 ((,) a) where type Rep1 ((,) a) = K1 a :*: Par1 from1 (x, y) = K1 x :*: Par1 y to1 (K1 x :*: Par1 y) = (x, y) instance PGeneric1 ((,) a) where type From1 '(x, y) = 'K1 x ':*: 'Par1 y type To1 ('K1 x ':*: 'Par1 y) = '(x, y) instance SGeneric1 ((,) a) where sFrom1 (STuple2 x y) = SK1 x :%*: SPar1 y sTo1 (SK1 x :%*: SPar1 y) = STuple2 x y ----- type family GenericFmap (g :: a ~> b) (x :: f a) :: f b where GenericFmap g x = To1 (Fmap g (From1 x)) class PFunctor (f :: Type -> Type) where type Fmap (g :: a ~> b) (x :: f a) :: f b type Fmap g x = GenericFmap g x class SFunctor (f :: Type -> Type) where sFmap :: forall a b (g :: a ~> b) (x :: f a). Sing g -> Sing x -> Sing (Fmap g x) default sFmap :: forall a b (g :: a ~> b) (x :: f a). ( SGeneric1 f, SFunctor (Rep1 f) , Fmap g x ~ GenericFmap g x ) => Sing g -> Sing x -> Sing (Fmap g x) sFmap sg sx = sTo1 (sFmap sg (sFrom1 sx)) ----- instance PFunctor Par1 where type Fmap f ('Par1 x) = 'Par1 (f `Apply` x) instance PFunctor (K1 c) where type Fmap _ ('K1 x) = 'K1 x instance PFunctor (f :*: g) where type Fmap h (x ':*: y) = Fmap h x ':*: Fmap h y instance SFunctor Par1 where sFmap sf (SPar1 sx) = SPar1 (sf `applySing` sx) instance SFunctor (K1 c) where sFmap _ (SK1 sx) = SK1 sx instance (SFunctor f, SFunctor g) => SFunctor (f :*: g) where sFmap sh (sx :%*: sy) = sFmap sh sx :%*: sFmap sh sy ----- instance PFunctor ((,) a) -- The line below causes the panic instance SFunctor ((,) a) }}} {{{ $ /opt/ghc/8.6.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.6.0.20180714 for x86_64-unknown-linux): buildKindCoercion K1 a_a1Nj :*: Par1 Rep1 ((,) a_a1Nj) * a_a1Nj Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/types/Coercion.hs:2069:9 in ghc:Coercion }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 22:37:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 22:37:06 -0000 Subject: [GHC] #15411: urk! lookup local fingerprint In-Reply-To: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> References: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> Message-ID: <060.a12a710bfbc4babb0e975a44d53aa1ba@haskell.org> #15411: urk! lookup local fingerprint -------------------------------------+------------------------------------- Reporter: admock | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15399 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by admock): I found that c35ad6e0b3c62976e6251f1e9c47fe83ff15f4ce breaks the build for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 23:07:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 23:07:27 -0000 Subject: [GHC] #15419: GHC 8.6.1 regression (buildKindCoercion) In-Reply-To: <050.8c636ff7b7100012a49f9742f3f82864@haskell.org> References: <050.8c636ff7b7100012a49f9742f3f82864@haskell.org> Message-ID: <065.69b6ab6cab562f0291d22e5f565e17e4@haskell.org> #15419: GHC 8.6.1 regression (buildKindCoercion) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire (added) Comment: Commit 3eaa55dcbcd860a035dfe2cae96866e96b008f67 (`Apply Note [EtaAppCo] in OptCoercion to another case`) is responsible for this regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 23:12:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 23:12:19 -0000 Subject: [GHC] #15419: GHC 8.6.1 regression (buildKindCoercion) In-Reply-To: <050.8c636ff7b7100012a49f9742f3f82864@haskell.org> References: <050.8c636ff7b7100012a49f9742f3f82864@haskell.org> Message-ID: <065.e74e99cfa0a1eaa84c2c21a602ba96e7@haskell.org> #15419: GHC 8.6.1 regression (buildKindCoercion) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: (none) => goldfire Comment: OK, Richard, that's your patch... you're up :-). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 23:30:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 23:30:23 -0000 Subject: [GHC] #15419: GHC 8.6.1 regression (buildKindCoercion) In-Reply-To: <050.8c636ff7b7100012a49f9742f3f82864@haskell.org> References: <050.8c636ff7b7100012a49f9742f3f82864@haskell.org> Message-ID: <065.3765a95a75e4e0c273831415dd4d52ea@haskell.org> #15419: GHC 8.6.1 regression (buildKindCoercion) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15346 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15346 Comment: Amusingly enough, I think this simply a symptom of #15346. I tried applying this patch: {{{#!diff diff --git a/compiler/coreSyn/CoreOpt.hs b/compiler/coreSyn/CoreOpt.hs index 8684c84..11cbd1e 100644 --- a/compiler/coreSyn/CoreOpt.hs +++ b/compiler/coreSyn/CoreOpt.hs @@ -979,7 +979,7 @@ pushCoTyArg co ty | isForAllTy tyL = ASSERT2( isForAllTy tyR, ppr co $$ ppr ty ) - Just (ty `mkCastTy` mkSymCo co1, MCo co2) + Just (ty `mkCastTy` co1, MCo co2) | otherwise = Nothing @@ -989,8 +989,8 @@ pushCoTyArg co ty -- tyL = forall (a1 :: k1). ty1 -- tyR = forall (a2 :: k2). ty2 - co1 = mkNthCo Nominal 0 co - -- co1 :: k1 ~N k2 + co1 = mkSymCo (mkNthCo Nominal 0 co) + -- co1 :: k2 ~N k1 -- Note that NthCo can extract a Nominal equality between the -- kinds of the types related by a coercion between forall-types. -- See the NthCo case in CoreLint. diff --git a/compiler/types/Coercion.hs b/compiler/types/Coercion.hs index 2ca5151..1557ce0 100644 --- a/compiler/types/Coercion.hs +++ b/compiler/types/Coercion.hs @@ -1812,7 +1812,7 @@ liftCoSubstVarBndrUsing fun lc@(LC subst cenv) old_var Pair k1 _ = coercionKind eta new_var = uniqAway (getTCvInScope subst) (setVarType old_var k1) - lifted = Refl (TyVarTy new_var) + lifted = GRefl Nominal (TyVarTy new_var) (MCo eta) new_cenv = extendVarEnv cenv old_var lifted -- | Is a var in the domain of a lifting context? }}} And with that, the program in this ticket no longer panics. Richard, you're currently validating this patch, yes? Would you mind adding this as a regression test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 19 23:30:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 19 Jul 2018 23:30:49 -0000 Subject: [GHC] #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression In-Reply-To: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> References: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> Message-ID: <065.fc9687a1b833bfe14b17f8ff2a7b14df@haskell.org> #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15419 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15419 Comment: I believe #15419 is a symptom of this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 00:12:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 00:12:57 -0000 Subject: [GHC] #15196: Invert floating point comparisons such that no extra parity check is required. In-Reply-To: <047.7b7b81a2e120787e43a042c6cb25c543@haskell.org> References: <047.7b7b81a2e120787e43a042c6cb25c543@haskell.org> Message-ID: <062.2da726022e962deca0880846ad7f9c7d@haskell.org> #15196: Invert floating point comparisons such that no extra parity check is required. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (NCG) | Version: 8.4.3 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4990 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * differential: => Phab:D4990 Comment: There is a patch but it's still buggy atm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 00:39:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 00:39:26 -0000 Subject: [GHC] #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. In-Reply-To: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> References: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> Message-ID: <066.e2add16fe75ba03bb00d0f3af52192c0@haskell.org> #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving, | PatternMatchWarnings 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah, I suppose that would work. There's one annoying hiccup, though: what should we name this new field in `Implication` of type `DynFlags`? Unfortunately, `ic_dflags` is already taken by `InteractiveContext`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 00:44:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 00:44:48 -0000 Subject: [GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families In-Reply-To: <045.61bc63eee0a790503467c9479892f97e@haskell.org> References: <045.61bc63eee0a790503467c9479892f97e@haskell.org> Message-ID: <060.56dfe70913ab6e4e622ea2275935f3a5@haskell.org> #14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13737 | Blocking: Related Tickets: #14457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Phab:D4974 purports to "get rid of the whole knot-tying business"... or so I thought. Actually, I don't think even Phab:D4974 would be sufficient to unblock this. The problem is that even with that patch, `res_tmpl` in comment:14 is //still// knot-tied (since it mentions the knot-tied `rep_tycon`). This means calling `unifyType` on it is doomed to loop infinitely. Alas, https://phabricator.haskell.org/D4974#137148 suggests that `rep_tycon` is destined to be knot-tied, so I'm not sure how this bug could ever be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 03:19:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 03:19:23 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <060.0038bca0e0d5b1e9971669064da19757@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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): Phab:D4988 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Piyush, I don't think the behavior of your example is consistent with the hypothesis. Consider the following program: {{{ {-# LANGUAGE DataKinds, KindSignatures #-} unit p where signature Abstract where import GHC.TypeLits data Foo :: Nat instance KnownNat Foo module Util where import Data.Proxy import Abstract import GHC.TypeLits foo = natVal (Proxy :: Proxy Foo) }}} I get: {{{ ezyang at autobox:~/Dev/ghc-known-nat$ inplace/bin/ghc-stage2 --backpack test.bkp -fforce-recomp [1 of 1] Processing p [1 of 2] Compiling Abstract[sig] ( p/Abstract.hsig, nothing ) [2 of 2] Compiling Util ( p/Util.hs, nothing ) test.bkp:12:11: error: • Overlapping instances for KnownNat Foo arising from a use of ‘natVal’ Matching instances: instance [safe] KnownNat Foo -- Defined at test.bkp:6:14 There exists a (perhaps superclass) match: (The choice depends on the instantiation of ‘’ To pick the first instance above, use IncoherentInstances when compiling the other instance declarations) • In the expression: natVal (Proxy :: Proxy Foo) In an equation for ‘foo’: foo = natVal (Proxy :: Proxy Foo) | 12 | foo = natVal (Proxy :: Proxy Foo) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} The overlap occurs before Concrete is considered at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 03:56:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 03:56:15 -0000 Subject: [GHC] #15420: executable with library and template haskell doesn't compile statically Message-ID: <043.9af3ad37632a9eefc33c55a13e3acec3@haskell.org> #15420: executable with library and template haskell doesn't compile statically -------------------------------------+------------------------------------- Reporter: tiny | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See the attached program. Make sure to compile it under a cabal sandbox so that it picks up the static compilation options in cabal.config. It doesn't compile, complaining about a missing dynamic (.so/.dll) library although everything should be static. It does work if either - the static compilation options are left out of cabal.config and everything compiles dynamically, or - the `tmp` variable from Main.hs is removed, or - the staticth library import is removed from the executable (remove dependency in staticth.cabal and import statement from Main.hs). If all 3 are present it doesn't compile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 03:56:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 03:56:32 -0000 Subject: [GHC] #15420: executable with library and template haskell doesn't compile statically In-Reply-To: <043.9af3ad37632a9eefc33c55a13e3acec3@haskell.org> References: <043.9af3ad37632a9eefc33c55a13e3acec3@haskell.org> Message-ID: <058.56db425c18468e16774cd76968254ab4@haskell.org> #15420: executable with library and template haskell doesn't compile statically -------------------------------------+------------------------------------- Reporter: tiny | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tiny): * Attachment "staticth-master.zip" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 04:15:31 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 04:15:31 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <060.10908caa01b8b0541c86f7da89db0aa1@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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): Phab:D4988 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ppk): Replying to [comment:12 ezyang]: > Piyush, I don't think the behavior of your example is consistent with the hypothesis. Consider the following program: > > {{{ > {-# LANGUAGE DataKinds, KindSignatures #-} > unit p where > signature Abstract where > import GHC.TypeLits > data Foo :: Nat > instance KnownNat Foo > > module Util where > import Data.Proxy > import Abstract > import GHC.TypeLits > foo = natVal (Proxy :: Proxy Foo) > > }}} Yes I realised it yesterday when I went back and tested with a similar example. In the backpack case, the comment:4 is the correct analysis: we know that the type T in question has a `KnownNat` instance but cannot find its dictionary. Unfortunately the error it triggers is not a cannot find instance but the following. (Notice the match on null `match_given` in that code). This also explains why the cleanup suggested by @simonpj works because `matchKnownNat` now does not try generating instances on the fly and fails but actually looks up the environment. The real explanation therefore looks like an unfortunate error message and the explanation in comment:4 is the correct one. Please let me know if this real explanation makes sense ;-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 06:23:29 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 06:23:29 -0000 Subject: [GHC] #15411: urk! lookup local fingerprint In-Reply-To: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> References: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> Message-ID: <060.53fd5a8aa5c9411a2b3498f170179e26@haskell.org> #15411: urk! lookup local fingerprint -------------------------------------+------------------------------------- Reporter: admock | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15399 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:5 admock]: > I found that c35ad6e0b3c62976e6251f1e9c47fe83ff15f4ce breaks the build for me. That is the commit updating libraries. We need to find the breaking library update and then bisect in that library. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 07:31:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 07:31:05 -0000 Subject: [GHC] #15421: Refactor (~) to reduce the superclass stack Message-ID: <046.7da112720f7a39139593aa39e2475ff2@haskell.org> #15421: Refactor (~) to reduce the superclass stack -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently (see `Note [The equality types story]` in `TysPrim`) we have {{{ -- Hetereogeneous equality class a ~# b => a ~~ b instance a ~# b => a ~~ b -- Homogeneous equality class a ~~ b => (a :: k) ~ (b :: k) instance a ~~ b => a ~ b }}} Note that `(~#)` is a superclass of `(~~)`, and `(~~)` is a superclass of `(~)`. This means that in the common case of using `(~)` we need two superclass selections to get to the `(~#)` we want. Nothing really wrong with that, but it bloats programs, and is confusing to read when debugging. I propose to change this to {{{ -- Homogeneous equality class a ~# b => (a :: k) ~ (b :: k) instance a ~# b => a ~ b }}} That is, implement `(~)` in precisely the same way as `(~~)`. This makes `(~)` a tiny bit more baked-in to the compiler, but in exchange it behaves in the same way as `(~~)`, instead of behaving in a slightly different way. There should be no observable effect for users. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 07:39:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 07:39:45 -0000 Subject: [GHC] #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. In-Reply-To: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> References: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> Message-ID: <066.6d5f9c11426331bcb9667935f7befd59@haskell.org> #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving, | PatternMatchWarnings 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: | -------------------------------------+------------------------------------- Comment (by simonpj): > Ah, I suppose that would work. Yes.. I like the principle that we are preserving, in the constraint tree, the environment in force when the implication was built, so that delaying solving the constraint (rather than somehow solving it immediately) doesn't change the behaviour. > Unfortunately, ic_dflags is already taken by InteractiveContext. Ha ha! I suppose the alternatives are * Use the same name, on the grounds that you'll seldom, if ever, want both in scope at the same time. Downside: grep won't find the right set of uses -- I used grep quite a lot * Use `implic_dflags` or something, with a short explanation about why it's different. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 08:03:31 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 08:03:31 -0000 Subject: [GHC] #15418: Performance drop 60 times on non-profiling binary In-Reply-To: <045.a055029aec148ca416c29df30694b018@haskell.org> References: <045.a055029aec148ca416c29df30694b018@haskell.org> Message-ID: <060.46a8d83786bb6d61b15d1eeaae0ea4d9@haskell.org> #15418: Performance drop 60 times on non-profiling binary -------------------------------------+------------------------------------- Reporter: hth313 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > How can performance drop 60x when I basically just relink it? If you previously linked with profiling libraries and runtime, relinking it with non-profiling libraries and runtime (or the other way around) can of course make a huge difference. In one case all library functions are profiled and you're using profiling RTS, in the other they're not profiled and the RTS has less overheads. I'm confused about what exactly you're doing. I understand that you have one program that you want to optimize, and you're trying different profiling settings. You have these three configurations: - Compiled without profiling and run - Compiled with profiling and run without profiling (i.e. no `+RTS -p`) - Compiled with profiling and run with profiling (`+RTS -p`) Can you report numbes for each of these? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 08:37:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 08:37:22 -0000 Subject: [GHC] #15422: GHCi debugger doesn't see free variables when using ApplicativeDo Message-ID: <047.abebc5551ef8954944967449b4712428@haskell.org> #15422: GHCi debugger doesn't see free variables when using ApplicativeDo -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: ApplicativeDo | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4991 | Wiki Page: -------------------------------------+------------------------------------- ``` > ghci break029.hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( break029.hs, interpreted ) Ok, one module loaded. *Main> :!cat break029.hs {-# LANGUAGE ApplicativeDo #-} f :: Int -> IO Int f x = do y <- return (x + 1) return (y * 2) *Main> :step f 3 Stopped in Main.f, break029.hs:(4,7)-(6,16) _result :: IO Int = _ x :: Int = 3 [break029.hs:(4,7)-(6,16)] [break029.hs:(4,7)-(6,16)] *Main> :list 3 f :: Int -> IO Int 4 f x = do 5 y <- return (x + 1) 6 return (y * 2) 7 [break029.hs:(4,7)-(6,16)] [break029.hs:(4,7)-(6,16)] *Main> :step Stopped in Main.f, break029.hs:5:8-21 _result :: IO Int = _ x :: Int = 3 [break029.hs:5:8-21] [break029.hs:5:8-21] *Main> :list 4 f x = do 5 y <- return (x + 1) 6 return (y * 2) [break029.hs:5:8-21] [break029.hs:5:8-21] *Main> :step Stopped in Main.f, break029.hs:6:11-15 _result :: Int = _ [break029.hs:6:11-15] [break029.hs:6:11-15] *Main> y :7:1: error: Variable not in scope: y ``` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 08:37:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 08:37:52 -0000 Subject: [GHC] #15422: GHCi debugger doesn't see free variables when using ApplicativeDo In-Reply-To: <047.abebc5551ef8954944967449b4712428@haskell.org> References: <047.abebc5551ef8954944967449b4712428@haskell.org> Message-ID: <062.2d4d13211c4f686e598c21c275916dfd@haskell.org> #15422: GHCi debugger doesn't see free variables when using ApplicativeDo -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4991 Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonmar: Old description: > ``` > > ghci break029.hs > GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( break029.hs, interpreted ) > Ok, one module loaded. > *Main> :!cat break029.hs > {-# LANGUAGE ApplicativeDo #-} > > f :: Int -> IO Int > f x = do > y <- return (x + 1) > return (y * 2) > *Main> :step f 3 > Stopped in Main.f, break029.hs:(4,7)-(6,16) > _result :: IO Int = _ > x :: Int = 3 > [break029.hs:(4,7)-(6,16)] [break029.hs:(4,7)-(6,16)] *Main> :list > 3 f :: Int -> IO Int > 4 f x = do > 5 y <- return (x + 1) > 6 return (y * 2) > 7 > [break029.hs:(4,7)-(6,16)] [break029.hs:(4,7)-(6,16)] *Main> :step > Stopped in Main.f, break029.hs:5:8-21 > _result :: IO Int = _ > x :: Int = 3 > [break029.hs:5:8-21] [break029.hs:5:8-21] *Main> :list > 4 f x = do > 5 y <- return (x + 1) > 6 return (y * 2) > [break029.hs:5:8-21] [break029.hs:5:8-21] *Main> :step > Stopped in Main.f, break029.hs:6:11-15 > _result :: Int = _ > [break029.hs:6:11-15] [break029.hs:6:11-15] *Main> y > > :7:1: error: Variable not in scope: y > ``` New description: {{{ > ghci break029.hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( break029.hs, interpreted ) Ok, one module loaded. *Main> :!cat break029.hs {-# LANGUAGE ApplicativeDo #-} f :: Int -> IO Int f x = do y <- return (x + 1) return (y * 2) *Main> :step f 3 Stopped in Main.f, break029.hs:(4,7)-(6,16) _result :: IO Int = _ x :: Int = 3 [break029.hs:(4,7)-(6,16)] [break029.hs:(4,7)-(6,16)] *Main> :list 3 f :: Int -> IO Int 4 f x = do 5 y <- return (x + 1) 6 return (y * 2) 7 [break029.hs:(4,7)-(6,16)] [break029.hs:(4,7)-(6,16)] *Main> :step Stopped in Main.f, break029.hs:5:8-21 _result :: IO Int = _ x :: Int = 3 [break029.hs:5:8-21] [break029.hs:5:8-21] *Main> :list 4 f x = do 5 y <- return (x + 1) 6 return (y * 2) [break029.hs:5:8-21] [break029.hs:5:8-21] *Main> :step Stopped in Main.f, break029.hs:6:11-15 _result :: Int = _ [break029.hs:6:11-15] [break029.hs:6:11-15] *Main> y :7:1: error: Variable not in scope: y }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 09:16:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 09:16:46 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <060.b4a924017f5a826a41b94e43394b9457@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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): Phab:D4988 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ppk): Some of the test cases in `backpack/should_fail/` are failing. Of which I think the bkpfail46.bkp is actually //not giving// a compilation failure (and hence the test is failing). Can you have a look at this test case ? Was this a previous limitation of backpack that was now fixed or is it the case that some thing that should not have been acceptable is now being accepted (thereby seriously questioning the type safety). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 09:20:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 09:20:15 -0000 Subject: [GHC] #15417: Weak pointers to static objects are sometimes not detected as unreachable (was: Memory leaks in the GC due to static object collection) In-Reply-To: <043.238b597548438e23acfb3d75b5cc5e97@haskell.org> References: <043.238b597548438e23acfb3d75b5cc5e97@haskell.org> Message-ID: <058.c8413021bf409c0cd7b92903df5ed858@haskell.org> #15417: Weak pointers to static objects are sometimes not detected as unreachable -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research | needed Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): (fixed the title to be a bit more accurate) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 09:25:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 09:25:50 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <060.af1532ce8834a40a2fa188d467d977f6@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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): Phab:D4988 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ppk): Also check bkpfail25. Where I am now getting the error that is explicitly mentioned should not be got. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 09:52:08 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 09:52:08 -0000 Subject: [GHC] #15423: Ungrammatical error message involving a pattern binding Message-ID: <050.ebe40367e5b7002505ad9262c3f388cc@haskell.org> #15423: Ungrammatical error message involving a pattern binding -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Take a look at this error message from GHC's `Typeable1` test case: {{{ Typeable1.hs:22:5: error: [-Winaccessible-code (in -Wdefault), -Werror =inaccessible-code] • Couldn't match type ‘ComposeK’ with ‘a3 b3’ Inaccessible code in a pattern with pattern synonym: App :: forall k2 (t :: k2). () => forall k1 (a :: k1 -> k2) (b :: k1). (t ~ a b) => TypeRep a -> TypeRep b -> TypeRep t, in a pattern binding in 'do' block }}} In particular, note the "in a pattern binding in 'do' block" part. I think that should be "in **a** 'do' block". I believe fixing this is a simple matter of applying this patch: {{{#!diff diff --git a/compiler/hsSyn/HsExpr.hs b/compiler/hsSyn/HsExpr.hs index 96d86c8..a5c65fb 100644 --- a/compiler/hsSyn/HsExpr.hs +++ b/compiler/hsSyn/HsExpr.hs @@ -2804,7 +2804,7 @@ pprMatchContextNoun PatBindGuards = text "pattern binding guards" pprMatchContextNoun LambdaExpr = text "lambda abstraction" pprMatchContextNoun ProcExpr = text "arrow abstraction" pprMatchContextNoun (StmtCtxt ctxt) = text "pattern binding in" - $$ pprStmtContext ctxt + $$ pprAStmtContext ctxt pprMatchContextNoun PatSyn = text "pattern synonym declaration" ----------------- }}} Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 09:54:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 09:54:21 -0000 Subject: [GHC] #15423: Ungrammatical error message involving a pattern binding In-Reply-To: <050.ebe40367e5b7002505ad9262c3f388cc@haskell.org> References: <050.ebe40367e5b7002505ad9262c3f388cc@haskell.org> Message-ID: <065.ccdd5af2565dbbc2964fe787b657e101@haskell.org> #15423: Ungrammatical error message involving a pattern binding -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4992 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4992 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 09:56:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 09:56:26 -0000 Subject: [GHC] #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. In-Reply-To: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> References: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> Message-ID: <066.4f233e611f32d1b1b5c87726a83b0d99@haskell.org> #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving, | PatternMatchWarnings 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:11 simonpj]: > * Use the same name, on the grounds that you'll seldom, if ever, want both in scope at the same time. Ah, if only. I actually did try adding a field named `ic_dflags` to `Implication`, and it resulted in compilation errors due to conflicting with `InteractiveContext`'s `ic_dflags` in certain modules, so this is a problem in practice. > * Use `implic_dflags` or something, with a short explanation about why it's different. I'll go with that idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 11:20:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 11:20:44 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.0db112dc50604e10f2bed8315f795059@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Hah, that's a good hint! I did another run, this time compiling with `-fprof-auto-top` on `TyCoRep` only, and this reveals two interesting things: - `tcvs_of_type`, which doesn't exist in the old version yet, is responsible for 4.5% of CPU time in the new version - `zonkTopDecls`, while allocating about 8.8% in both versions, jumps from 5.9% CPU to 8.2% I'll dig deeper on these two. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 11:35:17 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 11:35:17 -0000 Subject: [GHC] #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. In-Reply-To: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> References: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> Message-ID: <066.e134063a20d19d3efe522dff742308d8@haskell.org> #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving, | PatternMatchWarnings Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8128 #8740 | Differential Rev(s): Phab:D4993 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4993 * related: => #8128 #8740 Comment: A WIP patch for this is at Phab:D4993. I haven't added any documentation yet, since I'm not sure that this design is the one that Simon intended. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 11:50:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 11:50:27 -0000 Subject: [GHC] #15424: There should be a flag for GHCi that tells it to load as many modules as possible Message-ID: <045.4261cddc5cb5ae8d5c91b2614b345fbd@haskell.org> #15424: There should be a flag for GHCi that tells it to load as many modules as possible -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Right now if GHCi runs into a module that contains an error, it stop loading altogether, AFAIU. It'd be good if it attempted to load as many modules as possible instead. For example, if I have modules A, B, and C and C contains an error, then as long as A and B do not depend on C, I should end up with them in scope no matter in which order I specify the modules in load script (the `--ghci-script` thing). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 12:17:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 12:17:48 -0000 Subject: [GHC] #15423: Ungrammatical error message involving a pattern binding In-Reply-To: <050.ebe40367e5b7002505ad9262c3f388cc@haskell.org> References: <050.ebe40367e5b7002505ad9262c3f388cc@haskell.org> Message-ID: <065.5e6ab132293e2e1aa363f0dee70a45fd@haskell.org> #15423: Ungrammatical error message involving a pattern binding -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4992 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"99f45e2a751dda4fdf00256d397a2932d430f3a7/ghc" 99f45e2a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="99f45e2a751dda4fdf00256d397a2932d430f3a7" Fix #15423 by using pprAStmtContext Summary: Previously, we were using `pprStmtContext` instead, which led to error messages missing indefinite articles where they were required. Test Plan: make test TEST="T13242a T7786 Typeable1" Reviewers: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15423 Differential Revision: https://phabricator.haskell.org/D4992 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 12:19:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 12:19:54 -0000 Subject: [GHC] #15423: Ungrammatical error message involving a pattern binding In-Reply-To: <050.ebe40367e5b7002505ad9262c3f388cc@haskell.org> References: <050.ebe40367e5b7002505ad9262c3f388cc@haskell.org> Message-ID: <065.930ed1c8b314bf610b24de81e653448b@haskell.org> #15423: Ungrammatical error message involving a pattern binding -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4992 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 13:26:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 13:26:57 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.c763e16e4041d77345b19af60584d65b@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah! The `tcvs_of_type` thing sounds promising. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 13:37:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 13:37:49 -0000 Subject: [GHC] #15425: GHC does not warn when two conflicting packages with same name are given via a dependent package and -package-db Message-ID: <042.7496a1819d69eef507da11d8c336fd64@haskell.org> #15425: GHC does not warn when two conflicting packages with same name are given via a dependent package and -package-db -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- So I'm compiling a Setup.hs of `mypackage`, directly with `ghc` and without use of `Cabal`. It has a custom build type and imports `Distribution.Extra.Doctest` from `cabal-doctest`. For compiling `mypackage`'s Setup.hs I give a `-package-db` that contains a custom `Cabal` package. But when I compiled `doctest`, I did not give that custom `Cabal` package. I compile with {{{ ghc -package-db=/tmp/nix-build-hsyslog-5.0.1.drv-0/setup-package.conf.d -package Cabal -j4 -threaded --make -o Setup -odir $TMPDIR -hidir $TMPDIR $i -fforce-recomp -keep-tmp-files -v5 }}} The given package db looks like this: {{{ % ls -lah /tmp/nix-build-hsyslog-5.0.1.drv-0/setup-package.conf.d total 56K drwxr-xr-x 2 niklas niklas 4.0K Jul 20 03:14 ./ drwxr-xr-x 12 niklas niklas 4.0K Jul 20 03:49 ../ -r--r--r-- 1 niklas niklas 11K Jul 20 02:30 Cabal-2.2.0.1-302vnEvwKgd3FEKLIV6HbI.conf -r--r--r-- 1 niklas niklas 2.3K Jul 20 02:30 cabal- doctest-1.0.6-E57gwmEN5fa2uY0bq8bb44.conf -rw-rw-r-- 1 niklas niklas 31K Jul 20 03:14 package.cache -rw-r--r-- 1 niklas niklas 0 Jul 20 02:30 package.cache.lock }}} Full [https://pastebin.com/raw/HpVLbe4A ghc-pkg dump -f /tmp/nix-build- hsyslog-5.0.1.drv-0/setup-package.conf.d output] This results in the linker flags: {{{ -L/nix/store/hfi080vzqqzfip6bd6x4cxc2jgj56xn3-ghc-8.4.3/lib/ghc-8.4.3/Cabal-2.2.0.1 -L/nix/store/6x9r3kqn8h961ilaw2nj474jrfyg28lp- Cabal-2.2.0.1/ghc-8.4.3/Cabal-2.2.0.1 ... -lHSCabal-2.2.0.1 -lHSCabal-2.2.0.1-302vnEvwKgd3FEKLIV6HbI }}} When this happens, GHC will always prefer the `Cabal` version from the global package db, and not the one I have given with `-package`. This results in my compiled `Setup` file to not use the Cabal version I desire. I would expect GHC to warn me when two Cabal versions are at play, or entirely refuse to compile, instead of picking the one that I have NOT explicitly specified. See full `-v5` ghc output here: https://pastebin.com/raw/jGbLPjxF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 13:37:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 13:37:56 -0000 Subject: [GHC] #15425: GHC does not warn when two conflicting packages with same name are given via a dependent package and -package-db In-Reply-To: <042.7496a1819d69eef507da11d8c336fd64@haskell.org> References: <042.7496a1819d69eef507da11d8c336fd64@haskell.org> Message-ID: <057.927affe7082293678af4b88721321a87@haskell.org> #15425: GHC does not warn when two conflicting packages with same name are given via a dependent package and -package-db -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): `ezyang__` from IRC: > ok, I think I agree with your diagnosis > > one of the problems with warning in the default package mode (without -hide-all-packages) is that, in most databases, there are lots of inconsistent versions of things, so it would be warning basically all the time > > so you'd have to implement this after you handled imports; THEN check that the transitive closures of packages make sense -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 13:52:33 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 13:52:33 -0000 Subject: [GHC] #15380: Infinite typechecker loop in GHC 8.6 In-Reply-To: <050.ceee7eb83a4946e532604b8e627271f4@haskell.org> References: <050.ceee7eb83a4946e532604b8e627271f4@haskell.org> Message-ID: <065.8da3fd5c684e2bea9a928d0253656f1c@haskell.org> #15380: Infinite typechecker loop in GHC 8.6 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4974 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Richard and I discussed yesterday; he has a bit more to do and then will commmit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 14:12:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 14:12:58 -0000 Subject: [GHC] #15384: Every implication should bump the TcLevel exactly once In-Reply-To: <047.d56843a5a9456b5500d56ec561e931f3@haskell.org> References: <047.d56843a5a9456b5500d56ec561e931f3@haskell.org> Message-ID: <062.3a061c450f8fb2ad20946d3dc282a4e7@haskell.org> #15384: Every implication should bump the TcLevel exactly once -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): I've fixed the ones that were due to the hole fits setting the `TcLevel` incorrectly, and submitted a patch to Phabricator (https://phabricator.haskell.org/D4994). However, `T10384`, `T14040a` and `TcStaticPointersFail02` still fail, and are unrelated to typed-holes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 14:30:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 14:30:07 -0000 Subject: [GHC] #15399: Build failure on PowerPC 64-bit big endian In-Reply-To: <047.59eacae05c8ce75e039f0bbb218e3836@haskell.org> References: <047.59eacae05c8ce75e039f0bbb218e3836@haskell.org> Message-ID: <062.f6daf4966500494fddb749a00846b335@haskell.org> #15399: Build failure on PowerPC 64-bit big endian ----------------------------------------+--------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+--------------------------------- Comment (by trommler): The breaking commit is changeset:ec22f7dd. I have found an endianness issue with this commit in `compiler/ghci/RtClosureInspect.hs`. I am just validating a patch on ppc64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 14:59:17 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 14:59:17 -0000 Subject: [GHC] #15384: Every implication should bump the TcLevel exactly once In-Reply-To: <047.d56843a5a9456b5500d56ec561e931f3@haskell.org> References: <047.d56843a5a9456b5500d56ec561e931f3@haskell.org> Message-ID: <062.929bbb52b59728ffbf8124b1d47d9f1e@haskell.org> #15384: Every implication should bump the TcLevel exactly once -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Great. I've commented -- please commit after that. (Ben can help if need be.) Then let's look at the remaining 3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 15:40:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 15:40:49 -0000 Subject: [GHC] #14388: GHC Panic In-Reply-To: <048.ff04d4b22c4f4e0aec9c19da64e2231b@haskell.org> References: <048.ff04d4b22c4f4e0aec9c19da64e2231b@haskell.org> Message-ID: <063.3470f365a242c78ab1105f34939048d0@haskell.org> #14388: GHC Panic -------------------------------------+------------------------------------- Reporter: aferrandi | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: infoneeded => closed * resolution: => invalid Comment: Closing due to no followup. Please reopen if you can still reproduce the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 15:47:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 15:47:52 -0000 Subject: [GHC] #12714: T9405 fails on Windows In-Reply-To: <046.8d33f0cca216ec45205082af03358f60@haskell.org> References: <046.8d33f0cca216ec45205082af03358f60@haskell.org> Message-ID: <061.78082e86ec89588616e7f6969029fd03@haskell.org> #12714: T9405 fails on Windows -----------------------------------+-------------------------------------- Reporter: bgamari | Owner: RolandSenn Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 16:06:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 16:06:39 -0000 Subject: [GHC] #12714: T9405 fails on Windows In-Reply-To: <046.8d33f0cca216ec45205082af03358f60@haskell.org> References: <046.8d33f0cca216ec45205082af03358f60@haskell.org> Message-ID: <061.7363270cd60fee0c3b78b7c48635ce59@haskell.org> #12714: T9405 fails on Windows -----------------------------------+--------------------------------------- Reporter: bgamari | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: T9405W / T9405L Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D4997 Wiki Page: | -----------------------------------+--------------------------------------- Changes (by RolandSenn): * status: new => patch * testcase: => T9405W / T9405L * differential: => Phab: D4997 Comment: See [https://phabricator.haskell.org/D4997] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 16:34:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 16:34:52 -0000 Subject: [GHC] #15418: Performance drop 60 times on non-profiling binary In-Reply-To: <045.a055029aec148ca416c29df30694b018@haskell.org> References: <045.a055029aec148ca416c29df30694b018@haskell.org> Message-ID: <060.8678695fdf132bde5634399ddb89f604@haskell.org> #15418: Performance drop 60 times on non-profiling binary -------------------------------------+------------------------------------- Reporter: hth313 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hth313): Normal build (report using time) {{{ real 16m17.687s user 16m1.916s sys 0m10.150s }}} Profiling build (no `+RTS -p`) {{{ real 0m26.963s user 0m26.562s sys 0m0.378s }}} Profiling build, `+RTS -p` {{{ real 0m27.528s user 0m27.121s sys 0m0.471s }}} Peeking inside generated `.prof` {{{ total time = 14.04 secs (14037 ticks @ 1000 us, 1 processor) total alloc = 17,827,853,336 bytes (excludes profiling overheads) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 17:35:30 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 17:35:30 -0000 Subject: [GHC] #15399: Build failure on PowerPC 64-bit big endian In-Reply-To: <047.59eacae05c8ce75e039f0bbb218e3836@haskell.org> References: <047.59eacae05c8ce75e039f0bbb218e3836@haskell.org> Message-ID: <062.a31913926d280bcf5eb335f77319dae6@haskell.org> #15399: Build failure on PowerPC 64-bit big endian ----------------------------------------+--------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+--------------------------------- Comment (by trommler): My patch was not quite good enough. Here is another endianness issue: {{{ BCO -> do // removed checks let splitWord = rawWds !! 3 pure $ BCOClosure itbl (pts !! 0) (pts !! 1) (pts !! 2) // on big endian this is the wrong way around (fromIntegral splitWord) (fromIntegral $ shiftR splitWord (wORD_SIZE_IN_BITS `div` 2)) (drop 4 rawWds) }}} I need a way to tell whether I am running on a big endian system. Is there any way to know inside without access to `DynFlags`? Is there even a portable way to read the first half-word from a word in memory? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 17:36:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 17:36:19 -0000 Subject: [GHC] #15399: Build failure on PowerPC 64-bit big endian In-Reply-To: <047.59eacae05c8ce75e039f0bbb218e3836@haskell.org> References: <047.59eacae05c8ce75e039f0bbb218e3836@haskell.org> Message-ID: <062.943dacd94827f598cdcd957cdccc8764@haskell.org> #15399: Build failure on PowerPC 64-bit big endian ----------------------------------------+--------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+--------------------------------- Comment (by trommler): Actually, comment:3 applies to AP and PAP closures as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 17:52:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 17:52:12 -0000 Subject: [GHC] #15418: Performance drop 60 times on non-profiling binary In-Reply-To: <045.a055029aec148ca416c29df30694b018@haskell.org> References: <045.a055029aec148ca416c29df30694b018@haskell.org> Message-ID: <060.3845b965042226298812d49b704bee07@haskell.org> #15418: Performance drop 60 times on non-profiling binary -------------------------------------+------------------------------------- Reporter: hth313 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14414, #9599 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: => #14414, #9599 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 19:43:01 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 19:43:01 -0000 Subject: [GHC] #15426: `elemIndex` and `findIndex` still can't fuse Message-ID: <045.556cc5a15fe7d0c4bec73444eba7ef79@haskell.org> #15426: `elemIndex` and `findIndex` still can't fuse -------------------------------------+------------------------------------- Reporter: kabuhr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: | Version: 8.4.3 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Ticket #14387 introduced a change to the implementation of `listToMaybe` to allow: {{{#!hs findIndex p = listToMaybe . findIndices p }}} to fuse. However, to take advantage of this, it looks like we also need `findIndex` (and `elemIndex`) to be marked inlinable (or some similar step). As a concrete example, the module: {{{#!hs module Foo where import Data.List (findIndex) foo :: Maybe Int foo = findIndex (==999999) [1..1000000] }}} compiled with GHC 8.4.3 using `-O2` produces the following unfused core: {{{#!hs foo_go = \ ds1_a2ws eta_a2wt -> case ds1_a2ws of { [] -> Nothing; : y_a2wx ys_a2wy -> case eqInteger# y_a2wx ds_r2we of { __DEFAULT -> foo_go ys_a2wy (+# eta_a2wt 1#); 1# -> Just (I# eta_a2wt) } } foo = foo_go (enumDeltaToInteger1 foo2 foo1) 0# }}} but if the definition of `findIndex` from `Data.OldList` is copied into the module or imported from another module with an `INLINABLE` pragma, then it fuses fine: {{{#!hs foo_go = \ x_a2Du eta_B1 -> case gtInteger# x_a2Du lim_r2Ey of { __DEFAULT -> case eqInteger# x_a2Du ds_r2Cv of { __DEFAULT -> foo_go (plusInteger x_a2Du foo1) (+# eta_B1 1#); 1# -> Just (I# eta_B1) }; 1# -> Nothing } foo = foo_go foo1 0# }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 19:48:30 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 19:48:30 -0000 Subject: [GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families In-Reply-To: <045.61bc63eee0a790503467c9479892f97e@haskell.org> References: <045.61bc63eee0a790503467c9479892f97e@haskell.org> Message-ID: <060.1b4cd3dcc440eaec4cd386f4307b46f7@haskell.org> #14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13737 | Blocking: Related Tickets: #14457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think we have a way forward here, actually. First off, the problem isn't the main type-checker knot. The problem is the littler knot in `tcDataDefn` which retrieves the `tycon` from the future in order to, well, build the tycon. This tycon is used in three places: 1. In the `res_ty` passed to `tcConDecls`. This `res_ty` is, in turn, used in two places: a. In the call to `buildDataCon`, where it is used to set up the `dcOrigResTy` field of a `DataCon`. b. To do the result-type matching in `rejigConRes`. 2. As the `TyCon` passed to `tcConDecls`. That is used only when building the `DataCon`, so that a `DataCon` knows what `TyCon` it has come from. 3. In `mkNewTyConRhs`, so that a newtype `CoAxiom` knows what `TyCon` it has come from. Usages 1a, 2, and 3 absolutely need the final, correct, fully zonked `TyCon`. However, usage 1b does ''not''. Conveniently, usage 1b is the one causing us trouble. The solution is to use `kcLookupTcTyCon` to get the `TcTyCon` of interest and build the `res_ty` with un-knot-tied types. Pass this (as a new parameter) to `tcConDecls`. And away you go! Remaining to do: 1. Send all the stuff in `TyCon`s through Core Lint. I'm pretty sure we have some bits and pieces that are not fully zonked sneaking into `TyCon`s. For example, the `final_bndrs` in `tcDataDefn` look not to have ever been zonked (by `zonkTcTypeToType` or a friend). 2. Fix the errors that arise in (1). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 20 20:12:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 20 Jul 2018 20:12:49 -0000 Subject: [GHC] #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. In-Reply-To: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> References: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> Message-ID: <066.e1179815b8a70101ff5c1dd2cbffa577@haskell.org> #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving, | PatternMatchWarnings Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8128 #8740 | Differential Rev(s): Phab:D4993 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): If we really want to capture the environment in an implication, we could just store the `Env TcGblEnv TcLclEnv`, as retrieved by `getEnv`. We might want to do this in `CtLoc`, too, for similar reasons. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 08:29:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 08:29:01 -0000 Subject: [GHC] #15409: Quantified constraints half-work with equality constraints In-Reply-To: <043.7fe1c010678d8ef67ceed7a0b99678e5@haskell.org> References: <043.7fe1c010678d8ef67ceed7a0b99678e5@haskell.org> Message-ID: <058.2d7b166a2657772cc12d4b1d5f87c9f7@haskell.org> #15409: Quantified constraints half-work with equality constraints -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 15359 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * os: Windows => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 08:37:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 08:37:21 -0000 Subject: [GHC] #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) In-Reply-To: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> References: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> Message-ID: <065.979d78de35e5a17aceec44041efb4815@haskell.org> #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): After some investigation, here is some more info: I'm running this on the branch on which I've fixed #15384, and now it generates a different panic: {{{ Filling a filled coercion hole co_a1we Sym (S _N _N (Sym (GRefl nominal r_a1vN[sk:1] (Sym (Either _N (Sym co_a1vU))_N)) ; GRefl nominal r_a1vN[sk:1] (Sym (Either _N (Sym co_a1vU))_N)))_N ; {co_a1ws} Sym (S _N _N (Sym (GRefl nominal r_a1vN[sk:1] (Sym (Either _N (Sym co_a1vU))_N)) ; GRefl nominal r_a1vN[sk:1] (Sym (Either _N (Sym co_a1vU))_N)))_N ; {co_a1wm} }}} This happens when trying to simplify: {{{ WC {wc_impl = Implic { TcLevel = 1 Skolems = x_a1vL[sk:1] y_a1vM[sk:1] (r_a1vN[sk:1] :: Either x_a1vL[sk:1] y_a1vM[sk:1]) No-eqs = True Status = Insoluble Given = Wanted = WC {wc_impl = Implic { TcLevel = 2 Skolems = No-eqs = False Status = Insoluble Given = co_a1vU :: y_a1vM[sk:1] GHC.Prim.~# x_a1vL[sk:1] Wanted = WC {wc_simple = [WD] hole{co_a1wo} {0}:: (S r_a1vN[sk:1] -> ()) GHC.Prim.~# S (r_a1vN[sk:1] |> Sym (Either _N (Sym co_a1vU))_N) (CNonCanonical) [WD] hole{co_a1we} {1}:: S (r_a1vN[sk:1] |> Sym (Either _N (Sym co_a1vU))_N) GHC.Prim.~# () (CNonCanonical) [WD] $dNum_a1wf {0}:: Num (S (r_a1vN[sk:1] |> Sym (Either _N (Sym co_a1vU))_N)) (CNonCanonical)} Binds = EvBindsVar a pattern with constructor: Refl :: forall k (a :: k). a :~: a, in a case alternative }} }}} where {{{ WC {wc_simple = [WD] hole{co_a1wi} {0}:: y_a1vM[sk:1] GHC.Prim.~# x_a1vL[sk:1] (CNonCanonical)} }}} is generated by `tcSubType_NC`. I'm not sure how to prevent/catch the filling of the unfilled coercion hole and discard those fits. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 10:36:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 10:36:01 -0000 Subject: [GHC] #11829: C++ does not catch exceptions when used with Haskell-main and linked by ghc In-Reply-To: <041.08b08e181b7a4c97ec0ab8f67992afaf@haskell.org> References: <041.08b08e181b7a4c97ec0ab8f67992afaf@haskell.org> Message-ID: <056.ae5cf1e458ff7f9a1187a8a5a4a3a55f@haskell.org> #11829: C++ does not catch exceptions when used with Haskell-main and linked by ghc -------------------------------------+------------------------------------- Reporter: pl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: c++ | exceptions Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by syntheorem): I just ran into this, but the `-lto_library` flag didn't fix the problem (Clang is passing it automatically now anyway). What ultimately worked for me was adding `-Wl,-keep_dwarf_unwind` to my `ld-options`. I tried your method of writing `main` in C++ and manually linking via Clang to see what it does. Interestingly, just linking against the Haskell libraries and RTS with no other flags broke exceptions for me. But I also got the same warning: {{{ ld: warning: could not create compact unwind for _ffi_call_unix64: does not use RBP or RSP based frame }}} I searched for that and discovered that you could use `-Wl,-no_compact_unwind` to disable the warning; and GHC already passes that flag to Clang during linking. But that option also somehow breaks the exception handling tables; the system will fall back on the DWARF exception tables if you include them by passing `-Wl,-keep_dwarf_unwind`. Also worth noting that I'm on macOS 10.12.6, which is about a year out of date, so the issue might be fixed on the most recent version. Using GHC 8.4.3 and Clang 6.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 11:34:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 11:34:12 -0000 Subject: [GHC] #15427: Calling hs_try_putmvar from an unsafe foreign call can cause the RTS to hang Message-ID: <049.decdf9f369f07feac7a1415f9c9ba9fe@haskell.org> #15427: Calling hs_try_putmvar from an unsafe foreign call can cause the RTS to hang -------------------------------------+------------------------------------- Reporter: syntheorem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime | Version: 8.4.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- An unsafe foreign call which calls `hs_try_putmvar` can cause the RTS to hang, preventing any Haskell threads from making progress. However, compiling with `-debug` causes it instead to fail an assertion in the scheduler: {{{ internal error: ASSERTION FAILED: file rts/Schedule.c, line 510 (GHC version 8.4.3 for x86_64_apple_darwin) }}} Here is a minimal test case which reproduces the assertion. It needs to be built with `-debug -threaded` and run with `+RTS -N2` or higher. {{{#!hs import Control.Concurrent (forkIO, threadDelay) import Control.Concurrent.MVar (MVar, newEmptyMVar, takeMVar) import Control.Monad (forever) import Foreign.C.Types (CInt(..)) import Foreign.StablePtr (StablePtr) import GHC.Conc (PrimMVar, newStablePtrPrimMVar) foreign import ccall unsafe hs_try_putmvar :: CInt -> StablePtr PrimMVar -> IO () main = do mvar <- newEmptyMVar forkIO $ forever $ do takeMVar mvar forkIO $ forever $ do sp <- newStablePtrPrimMVar mvar hs_try_putmvar (-1) sp threadDelay 1 -- Let it spin a few times to trigger the bug threadDelay 500 }}} I actually checked out GHC and added this as a test case and did some debugging. The specific assertion that fails is `ASSERT(task->cap == cap)`. This seems to happen because of this code in `hs_try_putmvar`: {{{#!c Task *task = getTask(); // ... ACQUIRE_LOCK(&cap->lock); // If the capability is free, we can perform the tryPutMVar immediately if (cap->running_task == NULL) { cap->running_task = task; task->cap = cap; RELEASE_LOCK(&cap->lock); // ... releaseCapability(cap); } else { // ... } }}} Basically it assumes that the current thread's task isn't currently running a capability, so it takes a new one and then releases it without restoring the previous value of `task->cap`. Modifying the code to restore the value of `task->cap` after releasing the capability fixes the assertion. But I don't know enough about the RTS to be sure I'm not missing something here. In particular, is there a problem with the task basically holding two capabilities for a short time? My other thought is that maybe it should check if its task is currently running a capability, and in that case do something else. But I'm not sure what. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 12:47:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 12:47:34 -0000 Subject: [GHC] #15428: GHC 8.6+ panics (piResultTys2), older GHCs don't Message-ID: <050.3c0a11195082b4606825f1a42a15bbbb@haskell.org> #15428: GHC 8.6+ panics (piResultTys2), older GHCs don't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program panics when compiled with GHC 8.6.1 or HEAD: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind import Data.Proxy import Data.Type.Equality type family Flurmp :: k type family Pure (x :: a) :: f a wat :: forall (f :: Type -> Type) (p :: Type). Proxy (f p) -> () wat _ = let s :: (Flurmp :: f p) :~: Pure (Flurmp :: p -> p) (Flurmp :: p) s = undefined in () }}} {{{ $ /opt/ghc/8.6.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.6.0.20180714 for x86_64-unknown-linux): piResultTys2 f_aAT a_aAU [(->) p_a1uI[sk:1], p_a1uI[sk:1] -> p_a1uI[sk:1], Flurmp, Flurmp] [Flurmp] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1041:9 in ghc:Type }}} On GHC 8.4 and earlier, this simply gives an error message: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:18:16: error: • Expecting one more argument to ‘Pure (Flurmp :: p -> p)’ Expected kind ‘p -> f p’, but ‘Pure (Flurmp :: p -> p)’ has kind ‘p -> p -> p’ • In the second argument of ‘(:~:)’, namely ‘Pure (Flurmp :: p -> p) (Flurmp :: p)’ In the type signature: s :: (Flurmp :: f p) :~: Pure (Flurmp :: p -> p) (Flurmp :: p) In the expression: let s :: (Flurmp :: f p) :~: Pure (Flurmp :: p -> p) (Flurmp :: p) s = undefined in () • Relevant bindings include wat :: Proxy (f p) -> () (bound at Bug.hs:16:1) | 18 | :~: Pure (Flurmp :: p -> p) (Flurmp :: p) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 13:09:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 13:09:58 -0000 Subject: [GHC] #15428: GHC 8.6+ panics (piResultTys2), older GHCs don't In-Reply-To: <050.3c0a11195082b4606825f1a42a15bbbb@haskell.org> References: <050.3c0a11195082b4606825f1a42a15bbbb@haskell.org> Message-ID: <065.2e38942b7d43609b05b02c4fdb5da68d@haskell.org> #15428: GHC 8.6+ panics (piResultTys2), older GHCs don't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType, | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): Simpler version, also panicks 8.4: {{{ {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where data Flurmp type family Pure (x :: a) :: f a type T = Pure Flurmp Flurmp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 13:13:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 13:13:55 -0000 Subject: [GHC] #15428: Oversaturated type family application panicks GHC (piResultTys2) (was: GHC 8.6+ panics (piResultTys2), older GHCs don't) In-Reply-To: <050.3c0a11195082b4606825f1a42a15bbbb@haskell.org> References: <050.3c0a11195082b4606825f1a42a15bbbb@haskell.org> Message-ID: <065.6a3c33368a6a22cf510701525dfb45c0@haskell.org> #15428: Oversaturated type family application panicks GHC (piResultTys2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType, | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Nice find. I've changed the title accordingly, since this affects all GHCs back to 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 13:50:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 13:50:31 -0000 Subject: [GHC] #15384: Every implication should bump the TcLevel exactly once In-Reply-To: <047.d56843a5a9456b5500d56ec561e931f3@haskell.org> References: <047.d56843a5a9456b5500d56ec561e931f3@haskell.org> Message-ID: <062.a6306d62d1c69068d0a631d29151e690@haskell.org> #15384: Every implication should bump the TcLevel exactly once -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"b202e7a48401bd8e805a92dcfe5ea059cbd8e41c/ghc" b202e7a4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b202e7a48401bd8e805a92dcfe5ea059cbd8e41c" Fix the TcLevel not being set correctly when finding valid hole fits Summary: This fixes the problem revealed by a new assert as it relates to valid hole fits. However, tests `T10384`, `T14040a` and `TcStaticPointersFail02` still fail the assert, but they are unrelated to valid hole fits. Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #15384 Differential Revision: https://phabricator.haskell.org/D4994 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 14:23:33 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 14:23:33 -0000 Subject: [GHC] #14242: Ticks and join points don't play well In-Reply-To: <046.44b5c9487253d57677726ed143b46a84@haskell.org> References: <046.44b5c9487253d57677726ed143b46a84@haskell.org> Message-ID: <061.dbad90863d6717470c74b05b818138da@haskell.org> #14242: Ticks and join points don't play well -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 14:48:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 14:48:30 -0000 Subject: [GHC] #15429: The docs for Unsafe.Coerce should recommend using Data.Coerce instead Message-ID: <046.8a6604cd9bdf0e40765788bc77cbcc29@haskell.org> #15429: The docs for Unsafe.Coerce should recommend using Data.Coerce instead -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Core | Version: 8.4.3 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently there's no reference from `Unsafe.Coerce` to `Data.Coerce` at all. Unsuspecting people might use `unsafeCoerce` where `coerce` would also work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 15:04:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 15:04:22 -0000 Subject: [GHC] #15418: Performance drop 60 times on non-profiling binary In-Reply-To: <045.a055029aec148ca416c29df30694b018@haskell.org> References: <045.a055029aec148ca416c29df30694b018@haskell.org> Message-ID: <060.8eb91647cb0f2f8d337e62c4331a1889@haskell.org> #15418: Performance drop 60 times on non-profiling binary -------------------------------------+------------------------------------- Reporter: hth313 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14414, #9599 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): Can you provide a reproducible case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 15:13:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 15:13:56 -0000 Subject: [GHC] #14414: Profiled program runs 2.5x faster than non-profiled In-Reply-To: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> References: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> Message-ID: <062.9952acf164134dcc394fe4a71142cda6@haskell.org> #14414: Profiled program runs 2.5x faster than non-profiled -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): To the filer: what operating system are you on? What hardware? How many cores? Can you try a later ghc version? Ben: I can't find the spinning explanation you reference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 15:23:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 15:23:01 -0000 Subject: [GHC] #12714: T9405 fails on Windows In-Reply-To: <046.8d33f0cca216ec45205082af03358f60@haskell.org> References: <046.8d33f0cca216ec45205082af03358f60@haskell.org> Message-ID: <061.7531d8dd792fd1c81e4636d754ad656e@haskell.org> #12714: T9405 fails on Windows -----------------------------------+-------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Changes (by RolandSenn): * testcase: T9405W / T9405L => * owner: RolandSenn => (none) * differential: Phab: D4997 => Comment: The problem is intermittend! Under Windows, sometimes the test case T9405 succeeds, sometimes it fails. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 15:32:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 15:32:31 -0000 Subject: [GHC] #14414: Profiled program runs 2.5x faster than non-profiled In-Reply-To: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> References: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> Message-ID: <062.d5dfa9fedacb9325033e072af0a34cc7@haskell.org> #14414: Profiled program runs 2.5x faster than non-profiled -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): I am not able to reproduce this on my Mac running 10.13.6 with 4 cores and GHC version 8.6.0.20180714 time for profiled version: Total time 1.244s ( 0.451s elapsed) time for non-profiled version: Total time 0.242s ( 0.134s elapsed) Also I checked that both programs produce the same output by writing to a file and doing a diff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 15:33:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 15:33:34 -0000 Subject: [GHC] #14414: Profiled program runs 2.5x faster than non-profiled In-Reply-To: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> References: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> Message-ID: <062.692edd319eb6149f6d31615873703082@haskell.org> #14414: Profiled program runs 2.5x faster than non-profiled -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 George): * status: new => infoneeded * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 16:01:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 16:01:53 -0000 Subject: [GHC] #15418: Performance drop 60 times on non-profiling binary In-Reply-To: <045.a055029aec148ca416c29df30694b018@haskell.org> References: <045.a055029aec148ca416c29df30694b018@haskell.org> Message-ID: <060.3d8f4a9cba036a1d2a7f062f942299ad@haskell.org> #15418: Performance drop 60 times on non-profiling binary -------------------------------------+------------------------------------- Reporter: hth313 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14414, #9599 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hth313): I can provide a binary with needed input files for download. I can also try on my side if I get some suggestions what to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 16:59:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 16:59:18 -0000 Subject: [GHC] #15419: GHC 8.6.1 regression (buildKindCoercion) In-Reply-To: <050.8c636ff7b7100012a49f9742f3f82864@haskell.org> References: <050.8c636ff7b7100012a49f9742f3f82864@haskell.org> Message-ID: <065.e11595390675263aea888953a490815e@haskell.org> #15419: GHC 8.6.1 regression (buildKindCoercion) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15346 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): I've tried to simplify the original bug report, but it's still long: {{{ #!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Kind data Prod a b data Proxy p = Proxy ----- data family Sing :: forall k. k -> Type data instance Sing x = STuple ----- type family Rep1 (f :: k -> Type) :: k -> Type type instance Rep1 ((,) a) = Prod a type family From1 (f :: Type -> Type) a (z :: f a) :: Rep1 f a type family To1 (f :: Type -> Type) a (z :: Rep1 f a) :: f a class Generic1 (f :: Type -> Type) where sFrom1 :: forall (a :: Type) (z :: f a). Proxy z -> Sing (From1 f a z) sTo1 :: forall (a :: Type) (r :: Rep1 f a). Proxy r -> Proxy (To1 f a r :: f a) instance Generic1 ((,) a) where sFrom1 Proxy = undefined sTo1 Proxy = undefined ----- type family Fmap (g :: b) (x :: f a) :: f b type instance Fmap (g :: b) (x :: (u, a)) = To1 ((,) u) b (Fmap g (From1 ((,) u) a x)) class PFunctor (f :: Type -> Type) where sFmap :: forall a b (g :: b) (x :: f a). Proxy g -> Sing x -> Proxy (Fmap g x) instance PFunctor (Prod a) where sFmap _ STuple = undefined sFmap1 :: forall (f :: Type -> Type) (u :: Type) (b :: Type) (g :: b) (x :: f u). (Generic1 f, PFunctor (Rep1 f), Fmap g x ~ To1 f b (Fmap g (From1 f u x)) ) => Proxy g -> Proxy x -> Proxy (Fmap g x) sFmap1 sg sx = sTo1 (sFmap sg (sFrom1 sx)) sFmap2 :: forall (p :: Type) (a :: Type) (b :: Type) (g :: b) (x :: (p, a)). Proxy g -> Proxy x -> Proxy (Fmap g x) sFmap2 = sFmap1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 17:23:59 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 17:23:59 -0000 Subject: [GHC] #9599: app runs 10 times faster when compiled with profilling information than without it In-Reply-To: <046.8ed82e950558f4005f25e1c4df3b6688@haskell.org> References: <046.8ed82e950558f4005f25e1c4df3b6688@haskell.org> Message-ID: <061.020308e4b097caf5e9f0a1badbb8aaaa@haskell.org> #9599: app runs 10 times faster when compiled with profilling information than without it -------------------------------------+------------------------------------- Reporter: kgardas | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Solaris | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * status: new => infoneeded Comment: Any updates? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 17:30:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 17:30:18 -0000 Subject: [GHC] #15418: Performance drop 60 times on non-profiling binary In-Reply-To: <045.a055029aec148ca416c29df30694b018@haskell.org> References: <045.a055029aec148ca416c29df30694b018@haskell.org> Message-ID: <060.c3559a2478e49dd09d5ddab9f8077194@haskell.org> #15418: Performance drop 60 times on non-profiling binary -------------------------------------+------------------------------------- Reporter: hth313 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14414, #9599 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): Best to have source also with details on how to produce a binary and how to run it so people can try this on different ghc versions and on different platforms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 17:31:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 17:31:38 -0000 Subject: [GHC] #15418: Performance drop 60 times on non-profiling binary In-Reply-To: <045.a055029aec148ca416c29df30694b018@haskell.org> References: <045.a055029aec148ca416c29df30694b018@haskell.org> Message-ID: <060.f46b2594a3555fa4da5ff68bf16942ca@haskell.org> #15418: Performance drop 60 times on non-profiling binary -------------------------------------+------------------------------------- Reporter: hth313 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14414, #9599 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * failure: None/Unknown => Runtime performance bug * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 19:46:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 19:46:42 -0000 Subject: [GHC] #15349: fixST is a bit wrong In-Reply-To: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> References: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> Message-ID: <060.8d6f386751e9eab9a126208b8eaf791b@haskell.org> #15349: fixST is a bit wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4948 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"5a49651f3161473b383ec497af38e9daa022b9ac/ghc" 5a49651f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5a49651f3161473b383ec497af38e9daa022b9ac" Harden fixST Trac #15349 reveals that lazy blackholing can cause trouble for `fixST` much like it can for `fixIO`. Make `fixST` work just like `fixIO`. Reviewers: simonmar, hvr, bgamari Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15349 Differential Revision: https://phabricator.haskell.org/D4948 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 19:48:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 19:48:39 -0000 Subject: [GHC] #15349: fixST is a bit wrong In-Reply-To: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> References: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> Message-ID: <060.f23cec5c2fc117ae4b01c9f581a8f021@haskell.org> #15349: fixST is a bit wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4948 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => merge Comment: If we can merge this, that would be nice. We don't yet have a fix for lazy `ST`, and I honestly don't know what that should look like. It ties my brain up in knots. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 20:11:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 20:11:12 -0000 Subject: [GHC] #15349: fixST is a bit wrong In-Reply-To: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> References: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> Message-ID: <060.ea1fd958a53bb515cf46cf8eadc44134@haskell.org> #15349: fixST is a bit wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4948 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Let's try to think this lazy thing through a little bit. In the general case, we have something like {{{#!hs runST $ (m >>= \x -> fixST (f x)) >>= g }}} There are lots of possible ways the dependencies could go. `g` may demand a value and/or a state token. Depending on that, `f x` may demand a value and/or a state token. If `f x` does ''not'' end up demanding a state token, then that means it doesn't mutate anything, so it's safe to duplicate its evaluation (but also perfectly fine to ensure that doesn't happen, of course). On the flip side, the `MVar` solution can easily fall apart here; if we read a value from an `MVar`, we have to make sure to run an action to fill it. Furthermore, we can't just stick `MVar` creation into the state thread, because that will demand a state token that we're not allowed to demand. If `f x` demands a state token, then it ''might'' perform mutation, and therefore mustn't be duplicated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 22:23:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 22:23:47 -0000 Subject: [GHC] #15418: Performance drop 60 times on non-profiling binary In-Reply-To: <045.a055029aec148ca416c29df30694b018@haskell.org> References: <045.a055029aec148ca416c29df30694b018@haskell.org> Message-ID: <060.316fa3d4941a792722daa1fbc3f3577e@haskell.org> #15418: Performance drop 60 times on non-profiling binary -------------------------------------+------------------------------------- Reporter: hth313 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14414, #9599 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hth313): Code base is unfortunately not open source. Problem is at least also on GHC 8.2.2 as that is I was using when I encountered it. I upgraded to 8.4.3 but unfortunately the problem was still there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 21 23:53:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 21 Jul 2018 23:53:29 -0000 Subject: [GHC] #15365: Argument-less infix declarations printed without parentheses in -ddump-splices In-Reply-To: <050.44adfa65cdb3af03785c9fae8905524a@haskell.org> References: <050.44adfa65cdb3af03785c9fae8905524a@haskell.org> Message-ID: <065.23460fdf71221385db378067b9e3de4f@haskell.org> #15365: Argument-less infix declarations printed without parentheses in -ddump- splices -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: monoidal Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * owner: (none) => monoidal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 22 04:24:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jul 2018 04:24:19 -0000 Subject: [GHC] #14414: Profiled program runs 2.5x faster than non-profiled In-Reply-To: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> References: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> Message-ID: <062.8aef007cad93442c2688da97bc96b85b@haskell.org> #14414: Profiled program runs 2.5x faster than non-profiled -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Comment (by Fuuzetsu): I believe I was on NixOS, IIRC Intel i7 6700k CPU on 8.2. That machine is on another continent and I won't be able to retry the experiment... If someone can confirm the bug doesn't occur on Linux with modern GHC, I'm happy for the ticket to be closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 22 09:18:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jul 2018 09:18:53 -0000 Subject: [GHC] #15365: Argument-less infix declarations printed without parentheses in -ddump-splices In-Reply-To: <050.44adfa65cdb3af03785c9fae8905524a@haskell.org> References: <050.44adfa65cdb3af03785c9fae8905524a@haskell.org> Message-ID: <065.e744363547745a0619e0932058935019@haskell.org> #15365: Argument-less infix declarations printed without parentheses in -ddump- splices -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: monoidal Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4998 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => patch * differential: => Phab:D4998 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 22 15:03:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jul 2018 15:03:53 -0000 Subject: [GHC] #15422: GHCi debugger doesn't see free variables when using ApplicativeDo In-Reply-To: <047.abebc5551ef8954944967449b4712428@haskell.org> References: <047.abebc5551ef8954944967449b4712428@haskell.org> Message-ID: <062.f68035c4c209845803c27faf3f1dc6fd@haskell.org> #15422: GHCi debugger doesn't see free variables when using ApplicativeDo -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4991 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"4ea9311cc5c3b99ea6915bee23f0a6776731f20e/ghc" 4ea9311/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4ea9311cc5c3b99ea6915bee23f0a6776731f20e" Fix the GHCi debugger with ApplicativeDo Summary: `collectLStmtsBinders` was returning nothing for `ApplicativeStmts`, which caused the debugger to not track free variables in many cases when using `ApplicativeDo`. Test Plan: * new test case * validate Reviewers: bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15422 Differential Revision: https://phabricator.haskell.org/D4991 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 22 15:06:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jul 2018 15:06:37 -0000 Subject: [GHC] #15422: GHCi debugger doesn't see free variables when using ApplicativeDo In-Reply-To: <047.abebc5551ef8954944967449b4712428@haskell.org> References: <047.abebc5551ef8954944967449b4712428@haskell.org> Message-ID: <062.31e114d90e5c971233dc917e55c41154@haskell.org> #15422: GHCi debugger doesn't see free variables when using ApplicativeDo -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4991 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 22 15:10:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jul 2018 15:10:19 -0000 Subject: [GHC] #15418: Performance drop 60 times on non-profiling binary In-Reply-To: <045.a055029aec148ca416c29df30694b018@haskell.org> References: <045.a055029aec148ca416c29df30694b018@haskell.org> Message-ID: <060.e4c5b5c7ce7e8bc4535959d6d4ca1c7c@haskell.org> #15418: Performance drop 60 times on non-profiling binary -------------------------------------+------------------------------------- Reporter: hth313 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14414, #9599 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): I think without a reduced test case with source this will be very hard to fix. It would be interesting to see if you can reproduce the issue in the related tickets above as I don't believe others have been able to. Others will probably have suggestions about what you can do on your side. You might want to take a look at the performance debugging section of https://ghc.haskell.org/trac/ghc/wiki/Debugging -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 22 16:51:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jul 2018 16:51:50 -0000 Subject: [GHC] #15430: Merge llvm fix to ghc-8.6 Message-ID: <047.e2f6587a5c3bcdb8c94fc02e2e26f5a5@haskell.org> #15430: Merge llvm fix to ghc-8.6 -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This ticket is a reminder to make sure that https://phabricator.haskell.org/D4969 (Fix a major copy'n'paste error in LLVM CodeGen) is merged to ghc-8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 22 16:52:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jul 2018 16:52:08 -0000 Subject: [GHC] #15430: Merge llvm fix to ghc-8.6 In-Reply-To: <047.e2f6587a5c3bcdb8c94fc02e2e26f5a5@haskell.org> References: <047.e2f6587a5c3bcdb8c94fc02e2e26f5a5@haskell.org> Message-ID: <062.ba107e3c68143340f040ada5d54cab4d@haskell.org> #15430: Merge llvm fix to ghc-8.6 -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 22 16:58:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jul 2018 16:58:50 -0000 Subject: [GHC] #15365: Argument-less infix declarations printed without parentheses in -ddump-splices In-Reply-To: <050.44adfa65cdb3af03785c9fae8905524a@haskell.org> References: <050.44adfa65cdb3af03785c9fae8905524a@haskell.org> Message-ID: <065.1ac69fac2f9b6cef9c63e273a35fbc05@haskell.org> #15365: Argument-less infix declarations printed without parentheses in -ddump- splices -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: monoidal Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4998 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"3aa09cc5af9cacba91915c095f9652ee5ed31ec7/ghc" 3aa09cc5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3aa09cc5af9cacba91915c095f9652ee5ed31ec7" Fix pretty-printing of data declarations in splices Test Plan: validate Reviewers: RyanGlScott, bgamari Reviewed By: RyanGlScott Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15365 Differential Revision: https://phabricator.haskell.org/D4998 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 22 17:01:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jul 2018 17:01:07 -0000 Subject: [GHC] #15365: Argument-less infix declarations printed without parentheses in -ddump-splices In-Reply-To: <050.44adfa65cdb3af03785c9fae8905524a@haskell.org> References: <050.44adfa65cdb3af03785c9fae8905524a@haskell.org> Message-ID: <065.f33f814be66d722d60600853f6c68ecd@haskell.org> #15365: Argument-less infix declarations printed without parentheses in -ddump- splices -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: monoidal Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4998 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 22 18:06:26 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jul 2018 18:06:26 -0000 Subject: [GHC] #12714: T9405 fails on Windows In-Reply-To: <046.8d33f0cca216ec45205082af03358f60@haskell.org> References: <046.8d33f0cca216ec45205082af03358f60@haskell.org> Message-ID: <061.36142d1a8ca9e7788e9db4083aa59691@haskell.org> #12714: T9405 fails on Windows -----------------------------------+-------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Changes (by monoidal): * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 22 18:20:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jul 2018 18:20:02 -0000 Subject: [GHC] #15399: Build failure on PowerPC 64-bit big endian In-Reply-To: <047.59eacae05c8ce75e039f0bbb218e3836@haskell.org> References: <047.59eacae05c8ce75e039f0bbb218e3836@haskell.org> Message-ID: <062.ad54000dfaf911d3299321d646e75df6@haskell.org> #15399: Build failure on PowerPC 64-bit big endian ----------------------------------------+---------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5001 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by trommler): * differential: => Phab:D5001 Comment: Here is a fix for one of the 36 failing GHCi tests. It fixes three endianness issues introduced by changeset:ec22f7dd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 22 18:50:41 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 22 Jul 2018 18:50:41 -0000 Subject: [GHC] #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' In-Reply-To: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> References: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> Message-ID: <062.84502051e8a8608d3f60726bb072743c@haskell.org> #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' ---------------------------------+---------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by goldfire): * priority: normal => highest * milestone: 8.8.1 => 8.6.1 Comment: I'm going to bump the priority here. I just downloaded the 8.4.3 (yes, I know, behind the times) binaries for my Mac and installed them with `./configure; make install`. Now, every time I link an executable, I get {{{ clang: warning: argument unused during compilation: '-nopie' [-Wunused- command-line-argument] }}} I downloaded straight from `downloads.haskell.org/~ghc/8.4.3`. As comment:7 suggests, if I adjust the `settings` file, all is well. It seems easy enough to fix this, and we're giving a bad user experience without this fix. If you disagree with my priority bump (either because, say, there's something unique about my setup which makes my experience atypical; or because this is actually hard to fix and shouldn't be a release blocker) feel free to reverse my actions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 00:42:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 00:42:11 -0000 Subject: [GHC] #15219: Implement UnliftedNewtypes proposal In-Reply-To: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> References: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> Message-ID: <064.0946c8c97f05a74cbd5f3ec1f060b3c1@haskell.org> #15219: Implement UnliftedNewtypes proposal -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | UnliftedNewtypes, GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1311 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 02:48:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 02:48:24 -0000 Subject: [GHC] #15431: Coercible and Existential types don't play nicely Message-ID: <046.f58bd30ad49ea13ff113888a9d6b4132@haskell.org> #15431: Coercible and Existential types don't play nicely -------------------------------------+------------------------------------- Reporter: NioBium | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the following example, {{{f}}} compiles but {{{g}}} doesn't. {{{ data T t where A :: Show (t a) => t a -> T t B :: Coercible Int (t a) => t a -> T t f :: T t -> String f (A t) = show t g :: T t -> Int g (B t) = coerce t • Couldn't match representation of type ‘Int’ with that of ‘t a’ Inaccessible code in a pattern with constructor: B :: forall k (t :: k -> *) (a :: k). Coercible Int (t a) => t a -> T t, in an equation for ‘g’ • In the pattern: B t In an equation for ‘g’: g (B t) = coerce t }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 07:21:16 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 07:21:16 -0000 Subject: [GHC] #14414: Profiled program runs 2.5x faster than non-profiled In-Reply-To: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> References: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> Message-ID: <062.003ce4bb9c79eb82f549d4ef401f5e1b@haskell.org> #14414: Profiled program runs 2.5x faster than non-profiled -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Comment (by osa1): I also can't reproduce this with GHC 8.4.2 on Linux. When I increase the input by 10x (otherwise it runs too fast on my system) and call `time` I get these numbers: - Profiled: 12.18s, `-s` reports: 12.17s - Non-profiled: 2.00s, `-s` reports: 1.9s Non-threaded runtime: - Profiled: 3.73s, `-s` reports: 3.72s - Non-profiled: 1.29s, `-s` reports: 1.28s -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 10:12:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 10:12:53 -0000 Subject: [GHC] #15260: Xmobar crashes with segmentation fault In-Reply-To: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> References: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> Message-ID: <061.4944b66d898f3e1f28e683a10ce300aa@haskell.org> #15260: Xmobar crashes with segmentation fault ----------------------------------+-------------------------------------- Reporter: Voronwe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by osa1): Someone reported on another github issue (and I've also confirmed) that the segfault disappears when compiled with GHC 8.2.2. Not sure if important but versions of dependencies are different with GHC 8.4.2 and 8.2.2: - directory-1.3.3.0 in 8.4.2, directory-1.3.0.2 in 8.2.2 - process-1.6.3.0 in 8.4.2, process-1.6.1.0 in 8.2.2 - stm-2.5.0.0 in 8.4.2, stm-2.4.5.0 in 8.2.2 - unix-2.8.0.0 in 8.4.2, unix-2.7.2.2 in 8.2.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 12:51:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 12:51:39 -0000 Subject: [GHC] #15431: Coercible and Existential types don't play nicely In-Reply-To: <046.f58bd30ad49ea13ff113888a9d6b4132@haskell.org> References: <046.f58bd30ad49ea13ff113888a9d6b4132@haskell.org> Message-ID: <061.b0d39cdee9c60612e3c25478fb66bd9e@haskell.org> #15431: Coercible and Existential types don't play nicely -------------------------------------+------------------------------------- Reporter: NioBium | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14333 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => Roles * related: => #14333 Comment: Hm, this is interesting. This can be minimized to the following examples, which are slight variations of each other: {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} module Bug where import Data.Coerce import Data.Functor.Identity g1 :: Coercible (t a) Int => t a -> Int g1 = coerce g2 :: Coercible Int (t a) => t a -> Int g2 = coerce }}} `g1` typechecks, but `g2` doesn't! {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:12:6: error: • Couldn't match representation of type ‘t a’ with that of ‘Int’ arising from a use of ‘coerce’ • In the expression: coerce In an equation for ‘g2’: g2 = coerce • Relevant bindings include g2 :: t a -> Int (bound at Bug.hs:12:1) | 12 | g2 = coerce | ^^^^^^ }}} I'm not sure if this is related to #14333 or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 13:24:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 13:24:57 -0000 Subject: [GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families In-Reply-To: <045.61bc63eee0a790503467c9479892f97e@haskell.org> References: <045.61bc63eee0a790503467c9479892f97e@haskell.org> Message-ID: <060.010700acd57b77896bb08f5ad002fb6c@haskell.org> #14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13737 | Blocking: Related Tickets: #14457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Aha! Thank you goldfire, that plan works beautifully. With that, I am able to write a patch (based off of comment:14, and applied on top of Phab:D4974) which fixes the original program. Woohoo! ...there's one gotcha, though. Since we're now straight-up using `unifyType` in `tcConDecl`, some of the error messages degrade in quality. One example is in the `T12087` test case, which currently gives a rather informative error message: {{{ T12087.hs:6:3: error: • GADT constructor type signature cannot contain nested ‘forall’s or contexts Suggestion: instead use this type signature: MkF1 :: forall a. (Ord a, Eq a) => a -> F1 a • In the definition of data constructor ‘MkF1’ In the data type declaration for ‘F1’ }}} But after my patch, this turns into: {{{ T12087.hs:6:3: Couldn't match expected type ‘F1 a0’ with actual type ‘Eq a1 => a1 -> F1 a1’ In the definition of data constructor ‘MkF1’ }}} Which kind of sucks. The reason this happens is because the `GADT constructor type signature cannot contain nested ‘forall’s or contexts` error is emitted in `checkValidDataCon`, which comes //after// `tcConDecl` (currently, GHC assumes that `tcConDecl` will ignore ill formatted data constructors like these, and let `checkValidDataCon` catch them afterwards). I'm not quite sure how to deal with this. Perhaps we should carve out that particular check from `checkValidDataCon` and put it before the call to `unifyType` in `tcConDecl`? It's a bit arbitrary, but I think it would address the issue. As an added bonus, it might fix #11384, since performing this check earlier might give GHC a chance to spot an improper return type before kind-checking occurs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 13:27:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 13:27:03 -0000 Subject: [GHC] #14333: GHC doesn't use the fact that Coercible is symmetric In-Reply-To: <051.317ebc999077ee18339a9e5fa0ad5d1c@haskell.org> References: <051.317ebc999077ee18339a9e5fa0ad5d1c@haskell.org> Message-ID: <066.fc598d46380d55b8190cb9125e746696@haskell.org> #14333: GHC doesn't use the fact that Coercible is symmetric -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies, | Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14323, #15431 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #14323 => #14323, #15431 Comment: Is this bug fixed? (Also, see #15431 for a possibly related issue.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 13:44:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 13:44:05 -0000 Subject: [GHC] #15432: Referring to current module (or aliasing current module) Message-ID: <043.a38f77cae4a1227e03f71ef48177abb1@haskell.org> #15432: Referring to current module (or aliasing current module) -------------------------------------+------------------------------------- Reporter: moll | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Hey, Suppose I got a record type `Game` in a module `Lib.Game` that has a field `player`. I'd occasionally like to use the variable `player` in a closure, but still refer to the `player` field accessor once to assign the variable. Is it me or right now there's no way to refer to the current module by anything other than its full name? That is, to disambiguate the variable and function, I have to type `let player = Lib.Game.player`. In other words, I'd like the invocation of `Lib.Game.player` below to be shortened somehow, either by assigning an alias to the current module via `import qualified` (can't now as it results in a self-cycle) or by some other means of referring to the closing module. {{{#!hs module Lib.Game where data Game = Game {player :: Player} play game = foo player where player = Lib.Game.player game }}} This is vaguely similar to https://ghc.haskell.org/trac/ghc/ticket/10336, but the `SOURCE` pragma seems to be about actually cyclical imports. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 14:09:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 14:09:51 -0000 Subject: [GHC] #15431: Coercible and Existential types don't play nicely In-Reply-To: <046.f58bd30ad49ea13ff113888a9d6b4132@haskell.org> References: <046.f58bd30ad49ea13ff113888a9d6b4132@haskell.org> Message-ID: <061.16d7cd17cd3690b7e98e807bdff4fd6a@haskell.org> #15431: Coercible and Existential types don't play nicely -------------------------------------+------------------------------------- Reporter: NioBium | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14333 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm not all that surprised here. GHC has no way of decomposing `Coercible Int (t a)`, and so it just remembers that constraint in case it needs to prove exactly `Coercible Int (t a)`. In this case, it's trying to prove `Coercible (t a) Int`, and so it gives up. I suppose we special-case the lookup to include looking for a symmetrical constraint, but there will always be incompleteness lurking around the corner. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 14:16:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 14:16:03 -0000 Subject: [GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families In-Reply-To: <045.61bc63eee0a790503467c9479892f97e@haskell.org> References: <045.61bc63eee0a790503467c9479892f97e@haskell.org> Message-ID: <060.ffac28cedd2de26c8c5a19bcb203cca6@haskell.org> #14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13737 | Blocking: Related Tickets: #14457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): There is precedent with the strategy in comment:21. Note the arity check toward the top of `tcFamTyPats`. This check is fully redundant, but it gives a nice arity error (simple to understand!) instead of an obscure kind error. So, I would say to go with comment:21, with a comment (not sure if it needs a Note) explaining why do the eager check outside of `checkValidDataCon`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 14:25:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 14:25:31 -0000 Subject: [GHC] #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression In-Reply-To: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> References: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> Message-ID: <065.56ddfe344e56eb59728fbd25080637fa@haskell.org> #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15419 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"af624071fa063158d6e963e171280676f9c0a0b0/ghc" af624071/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="af624071fa063158d6e963e171280676f9c0a0b0" Fix some casts. This fixes #15346, and is a team effort between Ryan Scott and myself (mostly Ryan). We discovered two errors related to FC's "push" rules, one in the TPush rule (as implemented in pushCoTyArg) and one in KPush rule (it shows up in liftCoSubstVarBndr). The solution: do what the paper says, instead of whatever random thoughts popped into my head as I was actually implementing. Also fixes #15419, which is actually the same underlying problem. Test case: dependent/should_compile/T{15346,15419}. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 14:25:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 14:25:31 -0000 Subject: [GHC] #15419: GHC 8.6.1 regression (buildKindCoercion) In-Reply-To: <050.8c636ff7b7100012a49f9742f3f82864@haskell.org> References: <050.8c636ff7b7100012a49f9742f3f82864@haskell.org> Message-ID: <065.30d9d76aedea0f425b5e3ded8123a869@haskell.org> #15419: GHC 8.6.1 regression (buildKindCoercion) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15346 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"af624071fa063158d6e963e171280676f9c0a0b0/ghc" af624071/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="af624071fa063158d6e963e171280676f9c0a0b0" Fix some casts. This fixes #15346, and is a team effort between Ryan Scott and myself (mostly Ryan). We discovered two errors related to FC's "push" rules, one in the TPush rule (as implemented in pushCoTyArg) and one in KPush rule (it shows up in liftCoSubstVarBndr). The solution: do what the paper says, instead of whatever random thoughts popped into my head as I was actually implementing. Also fixes #15419, which is actually the same underlying problem. Test case: dependent/should_compile/T{15346,15419}. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 14:26:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 14:26:50 -0000 Subject: [GHC] #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression In-Reply-To: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> References: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> Message-ID: <065.e525b00f40d991e590aba489db987c9c@haskell.org> #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | dependent/should_compile/T15346 Blocked By: | Blocking: Related Tickets: #15419 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => dependent/should_compile/T15346 Comment: This should be merged -- it's a downright bug with a tiny patch. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 14:27:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 14:27:56 -0000 Subject: [GHC] #15419: GHC 8.6.1 regression (buildKindCoercion) In-Reply-To: <050.8c636ff7b7100012a49f9742f3f82864@haskell.org> References: <050.8c636ff7b7100012a49f9742f3f82864@haskell.org> Message-ID: <065.d667e1ab14beaceff05d51873c5c701f@haskell.org> #15419: GHC 8.6.1 regression (buildKindCoercion) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | dependent/should_compile/T15419 Blocked By: | Blocking: Related Tickets: #15346 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => dependent/should_compile/T15419 * status: new => closed * resolution: => fixed Comment: Labeling this as "fixed", because I set #15346 as "merge" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 14:44:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 14:44:25 -0000 Subject: [GHC] #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) In-Reply-To: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> References: <050.4ab788898b2e99f4770613874ab863ca@haskell.org> Message-ID: <065.12c3f04d5821d56d4a3fd2e39a3585e8@haskell.org> #15334: (forall x. c x, forall x. d x) is not equivalent to forall x. (c x, d x) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: fixed | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: quantified- valid program | constraints/T15334 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: merge => closed * resolution: => fixed * milestone: 8.6.1 => 8.8.1 Comment: Judging from comment:12, this won't make it into 8.6. Punting to 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 14:53:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 14:53:52 -0000 Subject: [GHC] #15431: Coercible and Existential types don't play nicely In-Reply-To: <046.f58bd30ad49ea13ff113888a9d6b4132@haskell.org> References: <046.f58bd30ad49ea13ff113888a9d6b4132@haskell.org> Message-ID: <061.84863c87c9fca8b8b777a788fc632c9e@haskell.org> #15431: Coercible and Existential types don't play nicely -------------------------------------+------------------------------------- Reporter: NioBium | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14333 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f0d27f515ffbc476144d1d1dd1a71bf9fa93c94b/ghc" f0d27f5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f0d27f515ffbc476144d1d1dd1a71bf9fa93c94b" Stop marking soluble ~R# constraints as insoluble We had a constraint (a b ~R# Int), and were marking it as 'insoluble'. That's bad; it isn't. And it caused Trac #15431. Soultion is simple. I did a tiny refactor on can_eq_app, so that it is used only for nominal equalities. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 14:56:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 14:56:07 -0000 Subject: [GHC] #14333: GHC doesn't use the fact that Coercible is symmetric In-Reply-To: <051.317ebc999077ee18339a9e5fa0ad5d1c@haskell.org> References: <051.317ebc999077ee18339a9e5fa0ad5d1c@haskell.org> Message-ID: <066.403ddf7cece3601de6175bc82f092b5e@haskell.org> #14333: GHC doesn't use the fact that Coercible is symmetric -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: TypeFamilies, | Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T14333 Blocked By: | Blocking: Related Tickets: #14323, #15431 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_compile/T14333 * resolution: => fixed Comment: Yes I believe this is fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 14:57:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 14:57:21 -0000 Subject: [GHC] #15431: Coercible and Existential types don't play nicely In-Reply-To: <046.f58bd30ad49ea13ff113888a9d6b4132@haskell.org> References: <046.f58bd30ad49ea13ff113888a9d6b4132@haskell.org> Message-ID: <061.30846b41865776721a885591337557ee@haskell.org> #15431: Coercible and Existential types don't play nicely -------------------------------------+------------------------------------- Reporter: NioBium | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14333 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: There was a palpable bug that meant the constraint was marked as insoluble, when it wasn't. This fixes both the OP and coment:1. The fix in #14333 (comment:10) does the symmetry bit. I agree that incompleteness is still lurking! The fix is a modest one; could be merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 15:40:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 15:40:31 -0000 Subject: [GHC] #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) In-Reply-To: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> References: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> Message-ID: <065.ccb6f1ae8b0b1be399fc32322c3f0b08@haskell.org> #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Tritlo, what commit are you on? I just tried compiling the program in comment:1 using commit f0d27f515ffbc476144d1d1dd1a71bf9fa93c94b, and to my surprise, it no longer panics! {{{ $ inplace/bin/ghc-stage2 ../Bug.hs [1 of 1] Compiling Bug ( ../Bug.hs, ../Bug.o ) ../Bug.hs:14:10: error: • Couldn't match type ‘n’ with ‘j’ ‘n’ is a rigid type variable bound by the type signature for: mkRefl :: forall k (n :: k) (j :: k). n :~: j at ../Bug.hs:13:1-17 ‘j’ is a rigid type variable bound by the type signature for: mkRefl :: forall k (n :: k) (j :: k). n :~: j at ../Bug.hs:13:1-17 Expected type: n :~: j Actual type: n :~: n • In the expression: Refl In an equation for ‘mkRefl’: mkRefl = Refl • Relevant bindings include mkRefl :: n :~: j (bound at ../Bug.hs:14:1) | 14 | mkRefl = Refl | ^^^^ ../Bug.hs:20:13: error: • Couldn't match type ‘S r’ with ‘()’ Expected type: () Actual type: S r • In the expression: no + _ In a case alternative: Refl -> no + _ In the expression: case mkRefl @x @y of { Refl -> no + _ } • Relevant bindings include no :: S r (bound at ../Bug.hs:18:7) right :: S r -> () (bound at ../Bug.hs:18:1) | 20 | Refl -> no + _ | ^^^^^^ ../Bug.hs:20:18: error: • Found hole: _ :: S r Where: ‘r’, ‘y’, ‘x’ are rigid type variables bound by the type signature for: right :: forall x y (r :: Either x y). S r -> () at ../Bug.hs:(16,1)-(17,18) • In the second argument of ‘(+)’, namely ‘_’ In the expression: no + _ In a case alternative: Refl -> no + _ • Relevant bindings include no :: S r (bound at ../Bug.hs:18:7) right :: S r -> () (bound at ../Bug.hs:18:1) Constraints include y ~ x (from ../Bug.hs:20:5-8) | 20 | Refl -> no + _ | ^ }}} Which seems positive, although I'm not sure which commit would have fixed this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 15:51:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 15:51:45 -0000 Subject: [GHC] #15361: Error message displays redundant equality constraint In-Reply-To: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> References: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> Message-ID: <065.9d2dd58c0290cf48154f7cc34134512e@haskell.org> #15361: Error message displays redundant equality constraint -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14394 | Differential Rev(s): Phab:D5002 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5002 Comment: In that case, I'll go for that approach. See Phab:D5002. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 16:16:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 16:16:50 -0000 Subject: [GHC] #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) In-Reply-To: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> References: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> Message-ID: <065.2d7e4f39a031a7b29ee7919946e0eb4c@haskell.org> #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): I'm on a branch based on 973ff4a142e77e247caebf828aa51f9810394938, with the changes from b202e7a48401bd8e805a92dcfe5ea059cbd8e41c on top. In b202e7a4, I remove the call to `tcTyVarLevel`, which was calling `tcTyVarDetails` and causing the original panic. I suspect af624071fa063158d6e963e171280676f9c0a0b0, which I believe changes the `hole{co_a1wi} {0}:: y_a1vM[sk:1] GHC.Prim.~# x_a1vL[sk:1]` constraint that was causing the crash. I'll check to confirm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 16:56:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 16:56:18 -0000 Subject: [GHC] #15411: urk! lookup local fingerprint In-Reply-To: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> References: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> Message-ID: <060.4580f24f66652c1d73e1b61510632c01@haskell.org> #15411: urk! lookup local fingerprint -------------------------------------+------------------------------------- Reporter: admock | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15399 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:6 trommler]: > That is the commit updating libraries. We need to find the breaking library update and then bisect in that library. I eyeballed some of the libraries and I will bisect in containers next. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 16:57:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 16:57:13 -0000 Subject: [GHC] #15411: urk! lookup local fingerprint In-Reply-To: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> References: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> Message-ID: <060.7ddd75e1dce98417f4aaee4fee43bf0b@haskell.org> #15411: urk! lookup local fingerprint -------------------------------------+------------------------------------- Reporter: admock | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15399 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * owner: (none) => trommler -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 16:57:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 16:57:48 -0000 Subject: [GHC] #15399: Build failure on PowerPC 64-bit big endian In-Reply-To: <047.59eacae05c8ce75e039f0bbb218e3836@haskell.org> References: <047.59eacae05c8ce75e039f0bbb218e3836@haskell.org> Message-ID: <062.93717f810fb0406293c034f7f1d4c7ce@haskell.org> #15399: Build failure on PowerPC 64-bit big endian ----------------------------------------+---------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5001 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by trommler): * owner: (none) => trommler -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 18:09:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 18:09:48 -0000 Subject: [GHC] #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) In-Reply-To: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> References: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> Message-ID: <065.bb216923927181e6165ddec5b6072831@haskell.org> #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): I'm still getting the latter error on f0d27f515ffbc476144d1d1dd1a71bf9fa93c94b,when I build with the devel2 flavor (even after make distclean). Are you sure you're not seeing it RyanGlScott? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 18:26:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 18:26:24 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.777af44fcde7b4cf43e9a63b3ef891aa@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Managed to get meaningful ticky-ticky profiling data. Before the patch: {{{ The following table is explained by http://ghc.haskell.org/trac/ghc/wiki/Debugging/TickyTicky All allocation numbers are in bytes. ************************************************** Entries Alloc Alloc'd Non-void Arguments STG Name -------------------------------------------------------------------------------- 172005 90819296 0 5 EMMMS ghc:TcUnify.promoteTcType2{v r3m} (fun) 2301299 85611504 0 2 >L base:GHC.Base.map{v 01X} (fun) 1612793 73036520 0 3 i.M containers-0.5.11.0:Data.IntMap.Internal.$winsert{v r7O} (fun) 699656 37268264 0 1 L go4{v sNuG} (ghc:TcMType) (fun) in r1Y 448802 35904160 0 7 E>>>>.M ghc:TcMType.$s$wmapType{v r1Y} (fun) 367181 23499584 0 2 LS ghc:TcRnMonad.traceTc1{v rlu} (fun) 887399 22625616 0 1 M go28{v sNuF} (ghc:TcMType) (fun) in r1Y 283135 21931488 0 4 >SSM ghc:TcHsSyn.$wzonkTyVarOcc{v r1F} (fun) 269137 18194264 0 1 L go13{v sSIr} (ghc:TcHsSyn) (fun) in rN 302653 16395904 0 5 +>LLL ghc:MonadUtils.zipWith3M{v rp} (fun) 194400 15552000 0 7 E>>>>.M ghc:TcHsSyn.$s$wmapType{v rN} (fun) 559499 15509096 0 1 M ghc:TcMType.zonkTcTyVar{v r1l} (fun) 138823 13706576 0 1 S sat_sMU6{v} (ghc:TcMType) (fun) in r6P 459700 11089080 0 1 S sat_sNvf{v} (ghc:TcMType) (fun) in sNuF }}} After: {{{ The following table is explained by http://ghc.haskell.org/trac/ghc/wiki/Debugging/TickyTicky All allocation numbers are in bytes. ************************************************** Entries Alloc Alloc'd Non-void Arguments STG Name -------------------------------------------------------------------------------- 172005 90819296 0 5 EMMMS ghc:TcUnify.promoteTcType2{v r3m} (fun) 2330347 86853624 0 2 >L base:GHC.Base.map{v 01X} (fun) 1271867 57141560 0 3 i.M containers-0.5.11.0:Data.IntMap.Internal.$winsert{v r7O} (fun) 699656 37268264 0 1 L go4{v sNmh} (ghc:TcMType) (fun) in r1Y 448802 35904160 0 7 E>>>>.M ghc:TcMType.$s$wmapType{v r1Y} (fun) 693375 27595440 0 3 MIM poly_merge1{v rs9H} (containers-0.5.11.0:Data.IntMap.Internal) (fun) 367181 23499584 0 2 LS ghc:TcRnMonad.traceTc1{v rlu} (fun) 887399 22625616 0 1 M go28{v sNmg} (ghc:TcMType) (fun) in r1Y 283135 21931488 0 4 >SSM ghc:TcHsSyn.$wzonkTyVarOcc{v r1F} (fun) 269137 18194264 0 1 L go13{v sSHY} (ghc:TcHsSyn) (fun) in rN 95951 16510560 0 2 >L base:Data.OldList.sortBy{v rD} (fun) 302653 16395904 0 5 +>LLL ghc:MonadUtils.zipWith3M{v rp} (fun) 194400 15552000 0 7 E>>>>.M ghc:TcHsSyn.$s$wmapType{v rN} (fun) 559499 15509096 0 1 M ghc:TcMType.zonkTcTyVar{v r1l} (fun) }}} Note the `poly_merge1` entry in the post-patch one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 19:02:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 19:02:00 -0000 Subject: [GHC] #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) In-Reply-To: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> References: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> Message-ID: <065.257f00a4fbd95b71d2aeb77f1496b3a4@haskell.org> #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To be clear, is the error that you're experiencing in comment:4 an assertion failure, or a different form of panic? If it's the former, then that would explain why I'm not seeing it—I'm not using a `devel*` build flavor, so I don't have assertions enabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 19:21:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 19:21:54 -0000 Subject: [GHC] #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) In-Reply-To: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> References: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> Message-ID: <065.ea9449cca865ff80192e43c5c039d079@haskell.org> #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): It's an assertion error. That would explain it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 19:43:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 19:43:17 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.c3a7836c585968caf531791d7cff5729@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): `poly_merge1` is likely coming from the `mergeWithKey'` function from `Data.IntMap` (which `unionVarSet` is implemented in terms of), as it has a helper function named `merge1`. The question, I suppose, is //which// use(s) of `unionVarSet` are problematic. There are at least a couple new uses of `unionVarSet` in Phab:D4769: * In `mapUnionVarSetSet`, which is used in the pivotal `closeOverKinds` function * Directly in `closeOverKinds` itself * In `nonDetCmpTypes` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 19:51:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 19:51:39 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.f1e3347b30385b21f4b41f8420f5cfa8@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Question: is it more efficient to use `closeOverKinds (unionVarSet set1 set2)` than `unionVarSet (closeOverKinds set1) (closeOverKinds set2)`? If so, I think the way `nonDetCmpTypes` is currently implemented is inefficient. We currently have: {{{#!hs nonDetCmpTypes :: [Type] -> [Type] -> Ordering nonDetCmpTypes ts1 ts2 = nonDetCmpTypesX rn_env ts1 ts2 where rn_env = mkRnEnv2 (mkInScopeSet (tyCoVarsOfTypes ts1 `unionVarSet` tyCoVarsOfTypes ts2)) }}} In particular, note this part: {{{#!hs tyCoVarsOfTypes ts1 `unionVarSet` tyCoVarsOfTypes ts2 }}} `tyCoVarsOfTypes` calls `closeOverKinds`, so we're calling `closeOverKinds` once more than is necessary. Perhaps this should be written like this? {{{#!hs tyCoVarsOfTypes (ts1 ++ ts2) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 20:59:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 20:59:37 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.1a05b6edb973fb6bd6a0d27d469cbadc@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Re comment:46, yes maybe it'd be more efficient like that. But I doubt this is the issue. `nonDetCmpTypes` (I hope) only evaluates that free-var set if it compare types involving forall. Otherwise it's just a thunk. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 21:17:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 21:17:22 -0000 Subject: [GHC] #15433: Internal error with PartialTypeSignatures and TH Message-ID: <047.aaa61fb434c95ee87d6470832f02e171@haskell.org> #15433: Internal error with PartialTypeSignatures and TH -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- File: {{{ {-# LANGUAGE TemplateHaskell #-} type T = $([t| _ |]) }}} gives a bad error message in 8.4 and HEAD: {{{ • GHC internal error: ‘_’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [r1sn :-> ATcTyCon T :: k0] • In the type ‘(_)’ In the type declaration for ‘T’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 21:33:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 21:33:59 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.0b3bdaf334b69171daaabf81f9e4392f@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I have a new hypothesis, provoked by this merge popping up in the statistics. * Previously, `tyCoVarsOfTypes` used `tyCoFVsOfTypes`, which in turn uses `unionFV` (from `utils/FV.hs`). This `FV` thing is relatively elaborate, maintaining a `VarSet` alongside a list. Plus an "interesting" predicate which, in the case of `tyCoVarsOfType` is `const True`. * In the patch, `tyCoVarsOfType` switches to using `unionVarSet`. This "obviously" shold be more efficient, because it just maintains a `VarSet`, with no list. * BUT `tyCoVarsOfType` does not use an accumulator; it just straightforwardly unions the free-vars in a tree-like way. In contrast, `unionFV` does use accumulator style, behind the scenes. * Bottom line: in the old version we make many calls to `extendVarSet`; in the new one we make many calls to `unionVarSet`. It should jolly well be the case that inserting 100 things one by one into a set should be no faster than unioning a balanced tree of the same 100 things. But looking at `Data.Map.Internal.insert`, and comparing with `Data.Map.Internal.mergeWithKey'`, I bet the former is faster. This hypothesis is easy to test: just change the new `tcvs_of_type` to take an accumulator. If this turns out to make a difference, I think we should file a bug on `containers`. Users should not have to worry about this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 23 22:05:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 23 Jul 2018 22:05:49 -0000 Subject: [GHC] #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) In-Reply-To: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> References: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> Message-ID: <065.2a203b1f684420829d5dd18802ee83da@haskell.org> #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I have a hypothesis about the assertion failure in comment:4 I see in `TcHoleErrors.tcCheckHoleFit` {{{ ; let w_rel_cts = addSimples wanted relevantCts ... ; let w_givens = foldr setWC w_rel_cts outermost_first ... ; rem <- runTcSDeriveds $ simpl_top w_givens }}} So the same `relevantCts` are used in multiple runs of `runTcSDerived`. You are careful to freshen the `ic_binds` of the implicatations, but if `relevantCts` contains any equalities they will have `HoleDest`, a coercion hole that is filled in directly. You really need to clone those holes too. Use `TcMType.cloneWanted` as in `cloneWC`. As it happens, this `cloneWanted` is overkill, and I'm improving it in an upcoming patch, but for now I think it'll do what you need. Does that make sense? Best to verify that this is indeed what is happening. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 01:40:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 01:40:49 -0000 Subject: [GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families In-Reply-To: <045.61bc63eee0a790503467c9479892f97e@haskell.org> References: <045.61bc63eee0a790503467c9479892f97e@haskell.org> Message-ID: <060.47d0d8efa5c63e6a5d0c0bd5978a3790@haskell.org> #14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13737 | Blocking: Related Tickets: #14457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Ryan, what happens if you try this example in your patch: {{{#!hs type S = T data T where MkT :: Int -> S }}} That works today. But I have a feeling it will fail with your patch. The problem is actually an oversight in Phab:D4974, but I was surprised that Phab:D4974 actually accepts the program above. However, a sneaking suspicion is that, with your patch as well, the program will be rejected. I'm wondering if I should bother fixing this (maybe it wasn't an oversight after all), and so I'm curious to know the behavior on your branch with that program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 04:21:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 04:21:52 -0000 Subject: [GHC] #15418: Performance drop 60 times on non-profiling binary In-Reply-To: <045.a055029aec148ca416c29df30694b018@haskell.org> References: <045.a055029aec148ca416c29df30694b018@haskell.org> Message-ID: <060.19d753c87b18e7c414f12db51668f1d9@haskell.org> #15418: Performance drop 60 times on non-profiling binary -------------------------------------+------------------------------------- Reporter: hth313 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14414, #9599 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hth313): I tried #14414 but I cannot reproduce that problem. Building my program on Linux (x86_64), I can confirm the problem I have encountered is also present there. I also tried to build with `-ticky`, but I cannot say the output made me any wiser. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 05:18:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 05:18:41 -0000 Subject: [GHC] #15411: urk! lookup local fingerprint In-Reply-To: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> References: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> Message-ID: <060.91262fae8fa2624cb99c64af3d4d9153@haskell.org> #15411: urk! lookup local fingerprint -------------------------------------+------------------------------------- Reporter: admock | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15399 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): I confirmed that changeset:c35ad6e builds with the containers version bump reverted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 07:11:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 07:11:37 -0000 Subject: [GHC] #15260: Xmobar crashes with segmentation fault In-Reply-To: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> References: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> Message-ID: <061.c7d46a6af8af5896013f3e3747aece1c@haskell.org> #15260: Xmobar crashes with segmentation fault ----------------------------------+-------------------------------------- Reporter: Voronwe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by osa1): I was posting my updates to the Github thread but I think this is a better place for them so moving those here and post future updates here as well. Two interesting finds: - The segfault is very easy to trigger when I add `performMajorGC`s around xmobar's `nextEvent'`: {{{ diff --git a/src/XUtil.hsc b/src/XUtil.hsc index 9063147..97f4961 100644 --- a/src/XUtil.hsc +++ b/src/XUtil.hsc @@ -39,6 +39,7 @@ import Graphics.X11.Xlib.Extras import System.Mem.Weak ( addFinalizer ) import System.Posix.Types (Fd(..)) import System.IO +import System.Mem (performMajorGC) #if defined XFT || defined UTF8 # if __GLASGOW_HASKELL__ < 612 @@ -207,8 +208,9 @@ newWindow dpy scr rw (Rectangle x y w h) o = do nextEvent' :: Display -> XEventPtr -> IO () nextEvent' d p = do pend <- pending d + performMajorGC if pend /= 0 - then nextEvent d p + then nextEvent d p >> performMajorGC else do threadWaitRead (Fd fd) nextEvent' d p }}} - If I compile xmobar with `-O0` I can't reproduce the segfault. (by default it's compiled with `-O1`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 07:38:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 07:38:15 -0000 Subject: [GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families In-Reply-To: <045.61bc63eee0a790503467c9479892f97e@haskell.org> References: <045.61bc63eee0a790503467c9479892f97e@haskell.org> Message-ID: <060.7da3d4097e62a50732217cdc4f8829f1@haskell.org> #14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13737 | Blocking: Related Tickets: #14457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I am intensely relaxed about this. It seems to me to be outright confusing to allow type synonyms in the result type of a data constructor signature. Let's just not allow it, and insist on `T` in the result type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 07:58:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 07:58:45 -0000 Subject: [GHC] #15428: Oversaturated type family application panicks GHC (piResultTys2) In-Reply-To: <050.3c0a11195082b4606825f1a42a15bbbb@haskell.org> References: <050.3c0a11195082b4606825f1a42a15bbbb@haskell.org> Message-ID: <065.b9312389eaeeead14ee74c98dca28c83@haskell.org> #15428: Oversaturated type family application panicks GHC (piResultTys2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType, | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm on this -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 08:51:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 08:51:36 -0000 Subject: [GHC] #15351: QuantifiedConstraints ignore FunctionalDependencies In-Reply-To: <049.c965c400807873236afd2b5848198ad6@haskell.org> References: <049.c965c400807873236afd2b5848198ad6@haskell.org> Message-ID: <064.d062d0f1c09ba687bd8bfc1ece0d2431@haskell.org> #15351: QuantifiedConstraints ignore FunctionalDependencies -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > How difficult would it be? The logic for top-level instances is in `TcInteract.doTopReactDict`: see `try_fundep_improvement`. You want to do something similar for the local quantified constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 08:53:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 08:53:57 -0000 Subject: [GHC] #14770: Allow static pointer expressions to have static pointer free variables In-Reply-To: <048.bed690b6ed6632ceb9361aef80b57ffb@haskell.org> References: <048.bed690b6ed6632ceb9361aef80b57ffb@haskell.org> Message-ID: <063.f48561b8be04b49adac58e7790ae8dc3@haskell.org> #14770: Allow static pointer expressions to have static pointer free variables -------------------------------------+------------------------------------- Reporter: TheKing01 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Gershom: you've just added yourself in cc. Do you have a use-case? Generally, this ticket would be much stronger if there were some concrete examples. I'm pretty sympathetic to the line of reasoning -- I think that static pointers are not yet "right" -- but we need compelling examples. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 10:21:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 10:21:28 -0000 Subject: [GHC] #15428: Oversaturated type family application panicks GHC (piResultTys2) In-Reply-To: <050.3c0a11195082b4606825f1a42a15bbbb@haskell.org> References: <050.3c0a11195082b4606825f1a42a15bbbb@haskell.org> Message-ID: <065.cec06623a3539face003940316e1f191@haskell.org> #15428: Oversaturated type family application panicks GHC (piResultTys2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType, | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"e1b5a1174e42e390855b153015ce5227b3251d89/ghc" e1b5a11/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e1b5a1174e42e390855b153015ce5227b3251d89" Fix a nasty bug in piResultTys I was failing to instantiate vigorously enough in Type.piResultTys and in the very similar function ToIface.toIfaceAppArgsX This caused Trac #15428. The fix is easy. See Note [Care with kind instantiation] in Type.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 10:22:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 10:22:58 -0000 Subject: [GHC] #15428: Oversaturated type family application panicks GHC (piResultTys2) In-Reply-To: <050.3c0a11195082b4606825f1a42a15bbbb@haskell.org> References: <050.3c0a11195082b4606825f1a42a15bbbb@haskell.org> Message-ID: <065.5691b1cbc3ab23646818f03c269bd6e0@haskell.org> #15428: Oversaturated type family application panicks GHC (piResultTys2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType, | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_compile/T15428 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_compile/T15428 * status: new => merge Comment: Thanks for the nice test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 12:39:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 12:39:55 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF In-Reply-To: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> References: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> Message-ID: <060.520c3655792a86b0ac78bcbdfbf6a941@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | perf/should_run/T15226, 15226a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4796 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Considering seq# strict can be rather bad, I believe. I'm not sure about that. First, let's remember (I always forget this) that `seq#` has type {{{ seq# ::a -> State# s -> (# State# s, a #) }}} That is, it involves the IO monad. It's used to implement {{{ evaluate :: a -> IO a evaluate a = IO $ \s -> seq# a s -- NB. see #2273, #5129 }}} See Trac #5129. Now consider {{{ \s. let x = blah in let y = x+1 in case seq# x s of (# s', x' #) -> ... }}} It seems fine to me transform this to {{{ \x. case blah of x -> let y = x+1 in case seq# x s of (# s', x' #) -> ... }}} What if the `seq#` is after some other IO operations thus: {{{ \s. let x = blah in case f s of (# s1, r #) -> case seq# x s of (# s2, x' #) -> ...... }}} Now you might worry that `x` might be evaluated (and throw an exception) before `f` gets a chance to run. But it doesn't: there's a hack in the strictness analyser (see `See Note [IO hack in the demand analyser]` in `DmdAnal`) that will make `x`'s binding lazy; in effect the strictness analyser treats the `case f s of ...` as if it had an extra invisible alternative not mentioning `x`. It's not that important. But I think that `seq#` can safely be strict in `x`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 12:50:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 12:50:55 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF In-Reply-To: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> References: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> Message-ID: <060.41ec6efa5d37e72144408ba3b7a9f8e5@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | perf/should_run/T15226, 15226a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4796 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm going to re-open this because there are two loose ends: * Should `seq#` be strict? See comment:10 * Is it worth doing the "binder-swap" thing? See comment:6 and following. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 12:51:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 12:51:50 -0000 Subject: [GHC] #15226: GHC doesn't know that seq# produces something in WHNF In-Reply-To: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> References: <045.3294ae09d35b2fa3a849d6f84936abd7@haskell.org> Message-ID: <060.c77d648459c44249929ff6743725487d@haskell.org> #15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Exceptions Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | perf/should_run/T15226, 15226a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4796 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Exceptions -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 13:21:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 13:21:36 -0000 Subject: [GHC] #14506: Configure Harbormaster to trigger CircleCI builds In-Reply-To: <046.9f61d9ef87c94b26144834dd33459a90@haskell.org> References: <046.9f61d9ef87c94b26144834dd33459a90@haskell.org> Message-ID: <061.8c822cff427c25744d59563c0a708ee6@haskell.org> #14506: Configure Harbormaster to trigger CircleCI builds -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Continuous | Version: 8.2.1 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): We now have a tiny web application that can act as a bridge between Phabricator and Circle CI. Ben and I will next look into deploying this. The code is available at https://github.com/alpmestan/phab-circleci- bridge, and you can see an example of using this on Harbormaster [https://phabricator.haskell.org/harbormaster/build/49274/ here]. Getting the build logs to Phabricator is proving to be a bit hard, I'll see what more I can do there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 13:24:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 13:24:43 -0000 Subject: [GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families In-Reply-To: <045.61bc63eee0a790503467c9479892f97e@haskell.org> References: <045.61bc63eee0a790503467c9479892f97e@haskell.org> Message-ID: <060.a0360255d9585883a818be8d45755ad8@haskell.org> #14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13737 | Blocking: Related Tickets: #14457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Correct, the program in comment:23 no longer compiles: {{{ Bug.hs:6:3: error: • Couldn't match expected type ‘T’ with actual type ‘S’ • In the definition of data constructor ‘MkT’ In the data declaration for ‘T’ | 6 | MkT :: Int -> S | ^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 13:43:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 13:43:17 -0000 Subject: [GHC] #14460: Symlink resolving fails against SMB mounts In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.dfecbb2c146ee3d39b745ede34faaccb@haskell.org> #14460: Symlink resolving fails against SMB mounts -------------------------------------+------------------------------------- Reporter: astert | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4216 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Vyse007): I am still facing this exact issue with 8.4.3. On a mounted network drive (shows up as "Network Drive, NTFS" under "This PC" on Windows 10), installing GHC and then invoking it throws the following error (Z is the networked drive): {{{ PS Z:\sandbox\Vyse\8.4.3> cd .\bin\ PS Z:\sandbox\Vyse\8.4.3\bin> .\ghci ghc.exe: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-mingw32): can't decompose ghc.exe path: "Z:\\sandbox\\Vyse\\8.4.3\\bin\\ghc.exe" }}} I originally thought this error must be because `doesDirectoryExist` returns false when trying to decompose this path, but that's not the case... (Note that the `ghci` used below is the one currently on PATH, i.e., not on the networked drive) {{{ PS Z:\sandbox\Vyse\8.4.3\bin> ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> import System.Directory Prelude System.Directory> doesDirectoryExist "Z:\\sandbox\\Vyse\\8.4.3\\bin\\" True }}} It might be worth noting that I don't have write permissions for all of `Z:\`, but only for my own folder there. I am willing to debug this further but I don't really know how to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 13:51:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 13:51:57 -0000 Subject: [GHC] #8128: Standalone deriving fails for GADTs due to inaccessible code In-Reply-To: <049.b5f919d61189346fb956f5afd152d2c9@haskell.org> References: <049.b5f919d61189346fb956f5afd152d2c9@haskell.org> Message-ID: <064.d708a6a71db1590b483bc2693c19f559@haskell.org> #8128: Standalone deriving fails for GADTs due to inaccessible code -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 7.7 checker) | Keywords: GADTs, Resolution: fixed | deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T8128 Blocked By: | Blocking: Related Tickets: #8740, #11066 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"44a7b9baa45c4ab939c7d996519b5e3de3e13c5a/ghc" 44a7b9b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="44a7b9baa45c4ab939c7d996519b5e3de3e13c5a" Suppress -Winaccessible-code in derived code Summary: It's rather unfortunate that derived code can produce inaccessible code warnings (as demonstrated in #8128, #8740, and #15398), since the programmer has no control over the generated code. This patch aims to suppress `-Winaccessible-code` in all derived code. It accomplishes this by doing the following: * Generalize the `ic_env :: TcLclEnv` field of `Implication` to be of type `Env TcGblEnc TcLclEnv` instead. This way, it also captures `DynFlags`, which record the flag state at the time the `Implication` was created. * When typechecking derived code, turn off `-Winaccessible-code`. This way, any insoluble given `Implication`s that are created when typechecking this derived code will remember that `-Winaccessible-code` was disabled. * During error reporting, consult the `DynFlags` of an `Implication` before making the decision to report an inaccessible code warning. Test Plan: make test TEST="T8128 T8740 T15398" Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: monoidal, rwbarton, thomie, carter GHC Trac Issues: #8128, #8740, #15398 Differential Revision: https://phabricator.haskell.org/D4993 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 13:51:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 13:51:57 -0000 Subject: [GHC] #8740: Deriving instance conditionally compiles In-Reply-To: <050.1c0f14a319b334387d7bd66c85f19a98@haskell.org> References: <050.1c0f14a319b334387d7bd66c85f19a98@haskell.org> Message-ID: <065.63add6f5978b0d535499b32c9bba6ebf@haskell.org> #8740: Deriving instance conditionally compiles -------------------------------------+------------------------------------- Reporter: thomaseding | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: GADTs, Resolution: fixed | deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T8740 Blocked By: | Blocking: Related Tickets: #8128, #11066 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"44a7b9baa45c4ab939c7d996519b5e3de3e13c5a/ghc" 44a7b9b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="44a7b9baa45c4ab939c7d996519b5e3de3e13c5a" Suppress -Winaccessible-code in derived code Summary: It's rather unfortunate that derived code can produce inaccessible code warnings (as demonstrated in #8128, #8740, and #15398), since the programmer has no control over the generated code. This patch aims to suppress `-Winaccessible-code` in all derived code. It accomplishes this by doing the following: * Generalize the `ic_env :: TcLclEnv` field of `Implication` to be of type `Env TcGblEnc TcLclEnv` instead. This way, it also captures `DynFlags`, which record the flag state at the time the `Implication` was created. * When typechecking derived code, turn off `-Winaccessible-code`. This way, any insoluble given `Implication`s that are created when typechecking this derived code will remember that `-Winaccessible-code` was disabled. * During error reporting, consult the `DynFlags` of an `Implication` before making the decision to report an inaccessible code warning. Test Plan: make test TEST="T8128 T8740 T15398" Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: monoidal, rwbarton, thomie, carter GHC Trac Issues: #8128, #8740, #15398 Differential Revision: https://phabricator.haskell.org/D4993 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 13:51:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 13:51:57 -0000 Subject: [GHC] #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. In-Reply-To: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> References: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> Message-ID: <066.78236addaef82d3db98d1f722f68969e@haskell.org> #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving, | PatternMatchWarnings Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8128 #8740 | Differential Rev(s): Phab:D4993 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"44a7b9baa45c4ab939c7d996519b5e3de3e13c5a/ghc" 44a7b9b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="44a7b9baa45c4ab939c7d996519b5e3de3e13c5a" Suppress -Winaccessible-code in derived code Summary: It's rather unfortunate that derived code can produce inaccessible code warnings (as demonstrated in #8128, #8740, and #15398), since the programmer has no control over the generated code. This patch aims to suppress `-Winaccessible-code` in all derived code. It accomplishes this by doing the following: * Generalize the `ic_env :: TcLclEnv` field of `Implication` to be of type `Env TcGblEnc TcLclEnv` instead. This way, it also captures `DynFlags`, which record the flag state at the time the `Implication` was created. * When typechecking derived code, turn off `-Winaccessible-code`. This way, any insoluble given `Implication`s that are created when typechecking this derived code will remember that `-Winaccessible-code` was disabled. * During error reporting, consult the `DynFlags` of an `Implication` before making the decision to report an inaccessible code warning. Test Plan: make test TEST="T8128 T8740 T15398" Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: monoidal, rwbarton, thomie, carter GHC Trac Issues: #8128, #8740, #15398 Differential Revision: https://phabricator.haskell.org/D4993 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 13:55:05 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 13:55:05 -0000 Subject: [GHC] #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. In-Reply-To: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> References: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> Message-ID: <066.fa5494785653781e24a1b99b25f535be@haskell.org> #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving, | PatternMatchWarnings Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8128 #8740 | Differential Rev(s): Phab:D4993 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 14:05:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 14:05:35 -0000 Subject: [GHC] #15434: DerivingVia (and perhaps even GND) works badly with DeriveGeneric Message-ID: <043.ff232ba9b1a1c824943c65988fdfafcf@haskell.org> #15434: DerivingVia (and perhaps even GND) works badly with DeriveGeneric -------------------------------------+------------------------------------- Reporter: konn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `DerivingVia` together with `DeriveGeneric` can generate wrong instances for `Generic`. Consider the following: {{{#!haskell {-# LANGUAGE DeriveGeneric, DerivingStrategies, DerivingVia, GADTs #-} {-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies, UndecidableInstances #-} module Data.Foldable.Bad where import GHC.Generics newtype Bad a = Bad a deriving (Generic) data Foo = Foo Int deriving (Read, Show, Eq, Ord) deriving (Generic) via Bad Foo }}} which gives the following representation, which is considered to be wrong for `Foo`: {{{#!haskell ghci> from $ Foo 12 M1 {unM1 = M1 {unM1 = M1 {unM1 = K1 {unK1 = Foo 12}}}} ghci> :t it it :: D1 ('MetaData "Bad" "Data.Foldable.Bad" "main" 'True) (C1 ('MetaCons "Bad" 'PrefixI 'False) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (Rec0 Foo))) x }}} Also, `DerivingStrategies` + GND + `DeriveGeneric` already can generate wrong instance: {{{#!haskell newtype Bad2 = Bad2 Bool deriving newtype (Generic) {- ghci> from $ Bad2 False M1 {unM1 = L1 (M1 {unM1 = U1})} ghci> :t it it :: D1 ('MetaData "Bool" "GHC.Types" "ghc-prim" 'False) (C1 ('MetaCons "False" 'PrefixI 'False) U1 :+: C1 ('MetaCons "True" 'PrefixI 'False) U1) x -} }}} I tested this against GHC 8.6.1-alpha1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 14:15:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 14:15:42 -0000 Subject: [GHC] #15434: DerivingVia (and perhaps even GND) works badly with DeriveGeneric In-Reply-To: <043.ff232ba9b1a1c824943c65988fdfafcf@haskell.org> References: <043.ff232ba9b1a1c824943c65988fdfafcf@haskell.org> Message-ID: <058.9b30490c360ae39553a237b75c1e0eed@haskell.org> #15434: DerivingVia (and perhaps even GND) works badly with DeriveGeneric -------------------------------------+------------------------------------- Reporter: konn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving Comment: I'm not sure what the bug is here. You're explicitly requesting that you reuse the `Generic` instance for `Bad Foo`, and lo and behold, GHC gives you it. If you don't like this behavior, don't combine `DerivingVia` with `Generic`—the former wasn't meant to be combined with the latter (indeed, this code will give an error if combined with the `Safe` extension). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 14:32:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 14:32:13 -0000 Subject: [GHC] #15434: DerivingVia (and perhaps even GND) works badly with DeriveGeneric In-Reply-To: <043.ff232ba9b1a1c824943c65988fdfafcf@haskell.org> References: <043.ff232ba9b1a1c824943c65988fdfafcf@haskell.org> Message-ID: <058.d799646dc7ddab6b918bdaceccfdebd9@haskell.org> #15434: DerivingVia (and perhaps even GND) works badly with DeriveGeneric -------------------------------------+------------------------------------- Reporter: konn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by konn): > You're explicitly requesting that you reuse the Generic instance for Bad Foo, and lo and behold, GHC gives you it. I can't imagine the situation where `Generic` should give the different information than its true structure. Although the code above is simple enough, I think it might be error-prone to allow writing Generic in DerivingVia-clause. As for GND, deriving strategy `newtype` is used as a prefix for the deriving clause, so one can easily notice the mistake; but as for DerivingVia, since `via`-clause is placed after constraints, one can easily overlook that the current deriving strategy. > this code will give an error if combined with the Safe extension Hence, I think this behaviour should be enabled by default, even without `Safe` extension. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 14:42:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 14:42:27 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.9dc5f5c9b192f5228763a93ab7f740a4@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think that the regression is on `perf/compiler/T9872d`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 14:48:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 14:48:03 -0000 Subject: [GHC] #15435: Make nofib-style anaysis for perf/compiler Message-ID: <046.01c4b4abf9f0686fae9fa8a24a18eaac@haskell.org> #15435: Make nofib-style anaysis for perf/compiler -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The compiler runtime tests in `perf/compiler` only complain if the perf gets worse by more than 5% or 10% or whatever (varies by test). I would '''love''' it if I could get a `nofib-analyse` style comparison of these benchmarks, comparing the compiler perf before and after some patch I've made. At the moment I simply can't do this comparison in a time-effective way. If we could generate a log-file in the right format, `nofib-analyse` might already do the job. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 16:00:48 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 16:00:48 -0000 Subject: [GHC] #12736: Calling a complex Haskell function (obtained via FFI wrapper function) from MSVC 64-bit C code (passed in as FunPtr) can leave SSE2 registers in the XMM6-XMM15 range modified In-Reply-To: <045.6a4ef3245edc9818770cf2e6fe05bb30@haskell.org> References: <045.6a4ef3245edc9818770cf2e6fe05bb30@haskell.org> Message-ID: <060.6337e7aca96bef413bc9be0fb34326b6@haskell.org> #12736: Calling a complex Haskell function (obtained via FFI wrapper function) from MSVC 64-bit C code (passed in as FunPtr) can leave SSE2 registers in the XMM6-XMM15 range modified -------------------------------------+------------------------------------- Reporter: bavism | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (FFI) | Version: 7.10.3 Resolution: fixed | Keywords: | ffi,registers,sse2,clobber,xmm Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | https://github.com/bavis-m/raycast Blocked By: | Blocking: Related Tickets: #14619 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * status: new => closed * resolution: => fixed * related: => #14619 Comment: Fixed with #14619. GHC did not respect callee saved XMM registers on windows. Leading to them being clobbered. I do not have VS2015 to confirm the repro case is fixed. But it's exactly what I would expect to happen without the fix so I'm closing this as fixed. Feel free to reopen if the issue persists. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 16:07:48 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 16:07:48 -0000 Subject: [GHC] #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation In-Reply-To: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> References: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> Message-ID: <061.88cba901658762ef69ebd2ce1b791502@haskell.org> #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation -------------------------------------+------------------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: Resolution: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): If this were fixed, then I believe that GHC could usefully use empty types as many of its "Trees That Grow" extension fields, make the extensions strict, and then remove many tiresome panics in redundant patterns. For example (simplified): {{{#!hs data HsImplicitBndrs pass = UsefulConstructor ... | XHsImplicitBndrs !(XXHsImplicitBndrs pass) type instance XXHsImplicitBndrs (GhcPass _) = Void }}} Note the bang. Currently, if we did this, we would ''still'' need to match against `XHsImplicitBndrs` every time. But with this patch fixed, we could avoid doing so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 16:19:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 16:19:43 -0000 Subject: [GHC] #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) In-Reply-To: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> References: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> Message-ID: <065.16997d7b142524d8586718e009a5c5fd@haskell.org> #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): That was indeed what was happening. A fix is up on Phabricator (https://phabricator.haskell.org/D5004), including a regression test (the code from comment:4). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 16:24:40 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 16:24:40 -0000 Subject: [GHC] #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) In-Reply-To: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> References: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> Message-ID: <065.d0b8e67b74c323d2eec31f2df411ebd8@haskell.org> #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Tritlo): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 16:27:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 16:27:20 -0000 Subject: [GHC] #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation In-Reply-To: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> References: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> Message-ID: <061.496c817424f690a7a317908df98c662c@haskell.org> #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation -------------------------------------+------------------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: Resolution: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: alanz, sh.najd@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 16:30:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 16:30:47 -0000 Subject: [GHC] #15433: Internal error with PartialTypeSignatures and TH In-Reply-To: <047.aaa61fb434c95ee87d6470832f02e171@haskell.org> References: <047.aaa61fb434c95ee87d6470832f02e171@haskell.org> Message-ID: <062.ddde701b1ba854699cc46f8f2371c138@haskell.org> #15433: Internal error with PartialTypeSignatures and TH -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * component: Compiler => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 17:01:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 17:01:15 -0000 Subject: [GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families In-Reply-To: <045.61bc63eee0a790503467c9479892f97e@haskell.org> References: <045.61bc63eee0a790503467c9479892f97e@haskell.org> Message-ID: <060.2384593332d59143d003415b6a185df2@haskell.org> #14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13737 | Blocking: Related Tickets: #14457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Recording some thoughts from a conversation with Richard and Simon: * The fact that programs like in the one in comment:23 won't compile is OK. In general, the type of a data constructor is quite restricted compared to other type signatures, and there already precedent for disallowing type synonyms in certain spots of data constructors. For instance, GHC rejects this example (from #7494): {{{#!hs data Steps s y where Yield :: y -> FK s y -> FK s y Done :: Steps s y type FK s y = s -> Steps s y }}} So it's perhaps not so unusual for GHC to reject the example from comment:23 as well. But this should be documented in the users' guide. (Should this bullet point have its own ticket?) * The code in comment:14 is slightly unusual in that we call `unifyType`, but immediately throw away the coercion that it returns. But this is also OK—there is an invariant that the coercion returned here will always be reflexive. As evidence for this claim, consider the following example: {{{#!hs type family F a type instance F Char = [Bool] data family T a b data instance T a [a] where MkT :: T Bool (F Char) }}} Compiling `MkT` should require a //non//-reflexive coercion in order to cast its return type `T Bool [Bool]` to `T Bool (F Char)`. But we disallow such shenanigans in `checkValidDataCon`, which checks that the type of a data constructor really is an instance of the parent type (//without// reducing any type families). Therefore, the shape of the data constructor return type must be the same as the shape of the parent type, so any coercion between the two must be reflexive. This subtlety should at least be documented. (Ideally, we'd add an `ASSERT`ion for it too, but this would be tricky to do in `tcConDecl`, and the alternative of stashing the coercion in `MkDataCon` only to check it later in the code if `ASSERT`ions are enabled is rather ghastly.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 17:21:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 17:21:02 -0000 Subject: [GHC] #15434: DerivingVia (and perhaps even GND) works badly with DeriveGeneric In-Reply-To: <043.ff232ba9b1a1c824943c65988fdfafcf@haskell.org> References: <043.ff232ba9b1a1c824943c65988fdfafcf@haskell.org> Message-ID: <058.5b93660738e53efcea86ad2ed2095dcb@haskell.org> #15434: DerivingVia (and perhaps even GND) works badly with DeriveGeneric -------------------------------------+------------------------------------- Reporter: konn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: dfeuer (added) Comment: As a counterpoint, I quite dislike the idea of GHC demanding that users write instances a certain way. In fact, one of the very reasons I authored `DerivingStrategies` in the first place was because one couldn't derive classes like `Read` or `Show` by any means except `stock` deriving. True, 90% of the time, this is what you want, but for the other 10%, having explicit control through `DerivingStrategies` is quite handy. Replying to [comment:2 konn]: > I can't imagine the situation where `Generic` should give the different information than its true structure. There are folks out there who write `Generic` instances which differ from what `stock` deriving would give you for various reasons. One reason is that some people like to define data types abstractly and only allow creating/matching on values of that data type through pattern synonyms. While I don't have any examples of people `newtype`/`via`-deriving `Generic` instances on hand, it's not inconceivable that folks might want to do this. > Hence, I think this behaviour should be enabled by default, even without `Safe` extension. I [https://ghc.haskell.org/trac/ghc/ticket/13065 used to share this opinion], but I no longer do. I don't think GHC (or `Safe`) should be in the business of enforcing the structure of `Generic` instances. You'll never segfault from using a hand-written `Generic` instance (unlike, say, `Typeable`). I think what you want is for GHC to be able to verify that a particular `Generic` instance's structure actually matches the data type it was derived for. This is a reasonable desire, since there are certain properties about data types that can easily be discerned from a `Rep` instance, but only if you have confidence that the `Rep` instance isn't "lying". dfeuer (cc'd) has toyed with some ideas for how this could be achieved in GHC—perhaps he could chime in here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 17:23:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 17:23:02 -0000 Subject: [GHC] #15260: Xmobar crashes with segmentation fault In-Reply-To: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> References: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> Message-ID: <061.95e1ecbf5fc64a87cc321a33754d6e8f@haskell.org> #15260: Xmobar crashes with segmentation fault ----------------------------------+-------------------------------------- Reporter: Voronwe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by incertia): Replying to [comment:9 osa1]: > Two interesting finds: It is also interesting to note that running it under `valgrind` also makes the segfault disappear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 17:27:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 17:27:08 -0000 Subject: [GHC] #15433: Internal error with PartialTypeSignatures and TH In-Reply-To: <047.aaa61fb434c95ee87d6470832f02e171@haskell.org> References: <047.aaa61fb434c95ee87d6470832f02e171@haskell.org> Message-ID: <062.f235028d8a495431f7af6b90137a5b1d@haskell.org> #15433: Internal error with PartialTypeSignatures and TH -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Indeed, the renamer normally catches things like `type T = _`, so the typechecker never has a chance to get its claws on it. This same phenomenon can also be observed in other places where wildcards are disallowed (for example, `instance C (Maybe $([t| _ |]))` also gives the same internal error). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 17:54:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 17:54:03 -0000 Subject: [GHC] #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation In-Reply-To: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> References: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> Message-ID: <061.402a7615a528d0c46fa1d6cad4c2aed9@haskell.org> #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation -------------------------------------+------------------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: Resolution: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To be clear, this is another occurrence of this phenomenon, right? {{{#!hs {-# LANGUAGE EmptyCase #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Bug where import Data.Void data Abyss = Abyss !Void stareIntoTheAbyss :: Abyss -> a stareIntoTheAbyss a = case a of {} }}} (In that GHC warns that `stareIntoTheAbyss` in non-exhaustive, even though it shouldn't?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 18:12:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 18:12:02 -0000 Subject: [GHC] #15418: Performance drop 60 times on non-profiling binary In-Reply-To: <045.a055029aec148ca416c29df30694b018@haskell.org> References: <045.a055029aec148ca416c29df30694b018@haskell.org> Message-ID: <060.b2e6362f6f0e305a151d0e5086411d79@haskell.org> #15418: Performance drop 60 times on non-profiling binary -------------------------------------+------------------------------------- Reporter: hth313 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14414, #9599 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hth313): Trying some low-tech profiling I compiled with `-debug` and ran in `lldb`, then stop using ctrl-c from time to time to see what it was up to. The following two are definitely main offenders, especically the second one. The first is the garbage collector in some way, I am not really sure what is going on in the second. {{{ * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x000000010097d553 tcc6502`countBlocks(bd=0x0000004202400fc0) at BlockAlloc.c:782 frame #1: 0x0000000100988cd6 tcc6502`genBlocks(gen=0x0000000110c07528) at Sanity.c:870 frame #2: 0x0000000100988fff tcc6502`memInventory(show=false) at Sanity.c:900 frame #3: 0x00000001009821b8 tcc6502`GarbageCollect(collect_gen=0, do_heap_census=false, gc_type=0, cap=0x0000000101dc4500, idle_cap=0x0000000000000000) at GC.c:297 frame #4: 0x00000001009730b9 tcc6502`scheduleDoGC(pcap=0x00007ffeefbff770, task=0x0000000110c078a0, force_major=false) at Schedule.c:1809 frame #5: 0x00000001009724d4 tcc6502`schedule(initialCapability=0x0000000101dc4500, task=0x0000000110c078a0) at Schedule.c:558 frame #6: 0x00000001009737d8 tcc6502`scheduleWaitThread(tso=0x0000004200105388, ret=0x0000000000000000, pcap=0x00007ffeefbff870) at Schedule.c:2544 frame #7: 0x000000010096a496 tcc6502`rts_evalLazyIO(cap=0x00007ffeefbff870, p=0x0000000101d74e68, ret=0x0000000000000000) at RtsAPI.c:530 frame #8: 0x000000010096d448 tcc6502`hs_main(argc=7, argv=0x00007ffeefbff9c8, main_closure=0x0000000101d74e68, rts_config=RtsConfig @ 0x00007ffeefbff890) at RtsMain.c:72 frame #9: 0x000000010063eec6 tcc6502`main + 166 frame #10: 0x00007fff692ec015 libdyld.dylib`start + 1 frame #11: 0x00007fff692ec015 libdyld.dylib`start + 1 }}} {{{ frame #0: 0x00000001001105c4 tcc6502`c5kzn_info + 36 tcc6502`c5kzn_info: -> 0x1001105c4 <+36>: leaq 0x888175(%rip), %rdx ; stg_MUT_ARR_PTRS_DIRTY_info 0x1001105cb <+43>: movq %rdx, (%rbx) 0x1001105ce <+46>: leaq 0x18(%rbx), %rdx 0x1001105d2 <+50>: shrq $0x7, %rax Target 0: (tcc6502) stopped. (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x00000001001105c4 tcc6502`c5kzn_info + 36 frame #1: 0x0000000109a19b60 libclang.dylib`llvm::TargetLibraryInfoImpl::StandardNames + 896 frame #2: 0x0000000108a6440b libclang.dylib frame #3: 0x0000000101d3f8c1 tcc6502`TranslatorziTargetziMOS6502ziCompilerziRegister_RCzuY_closure + 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 19:20:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 19:20:13 -0000 Subject: [GHC] #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation In-Reply-To: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> References: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> Message-ID: <061.8d0ac10c717ccd4c5bd0dbcf85eab5f4@haskell.org> #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation -------------------------------------+------------------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: Resolution: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I tried thinking of an (ad hoc) algorithm to check for this sort of thing. This is the closest I could get: 1. In `mkOneConFull` (which generates pattern-matching information for each constructor), record the type and strictness of each constructor's fields. 2. When checking if a match on that constructor is reachable, perform the following additional checks: i. Check if all fields are strict. ii. Check if each field's type is uninhabitable. If both (i) and (ii) are true, then deem the entire constructor to be unreachable. I think this would work for the original program, but not the program in comment:6 {{{#!hs data Abyss = MkAbyss !Abyss stareIntoTheAbyss :: Abyss -> a stareIntoTheAbyss a = case a of {} }}} Why? In order to check that a match on `(MkAbyss _)` is unreachable, we need to check: i. That the field of `MkAbyss` is strict. (This is the case.) ii. That the type of the field of `MkAbyss` (`Abyss`) is uninhabitable. But in order to check that `Abyss` in uninhabitable, we need to check the `MkAbyss` constructor again, which requires repeating this algorithm. Now we've entered an infinite loop! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 21:35:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 21:35:15 -0000 Subject: [GHC] #15347: QuantifiedConstraints: Implication constraints with type families don't work In-Reply-To: <049.446b77184844bcadda01810c8c61d990@haskell.org> References: <049.446b77184844bcadda01810c8c61d990@haskell.org> Message-ID: <064.7dd6771185a8554a8cce065b6f403e8d@haskell.org> #15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aaronvargo): Replying to [comment:10 simonpj]: A few things: First, there's probably another way to do this without a free-variable analysis: float type families out when they appear in wanted constraints. E.g. in `foo`, the floating would happen because `F b` appears in the wanted constraint, not because it's independent of the forall'd variables in the given quantified constraint. Would something like that be more feasible? Second, > Consider this: > {{{ > type family F a > type instance F Int = Bool > > instance Eq a => Eq (F a) where ... > }}} > Should we allow this? Obviously not. It's like allowing... Indeed, but this is an argument for disallowing ambiguity, not for disallowing type families. In your `Eq` example, `a` is ambiguous since `F` may not be injective. (likewise, `xs` and `ys` are ambiguous in the `map` example since `(++)` isn't injective). Not all uses of type families cause such ambiguity, and the compiler already has a perfectly good ambiguity check which can determine whether they do. Some cases where they don't are: 1. The type family is independent of the quantified variables 2. The type family is injective 3. The type family can be reduced to an expression which is unambiguous (this is #13262) 4. The quantified variables appear ambiguously in the type family, but are still made unambiguous by the rest of the instance head (e.g. `forall a. C (F a) a`) For top-level instances there may be coherence issues with allowing type families even when they don't cause ambiguity (though I'm not sure that there are), but such issues don't apply to QCs, which can't introduce incoherence. So why not allow type families in QCs, but require that the quantified variables be unambiguous? Third, working around this by manually floating out type families can be hugely painful, as it requires sacrificing one of the major benefits of type families, namely the ability to avoid passing around extra class parameters which are already determined by other parameters. The basic problem is this: suppose we have a class: {{{#!hs class (forall a. Eq a => Eq (f a)) => C f t | t -> f }}} Currently, the parameter `f` can never be instantiated with a type family without breaking the quantified constraint. This means the extra parameter needs to be repeated throughout the code for the QC to continue to work, despite the fact that `f` is already determined by `t`. Consider the following encoding of categories and functors, which makes use of type families: {{{#!hs type Hom k = k -> k -> Type -- Natural transformations data (==>) (p :: Hom i) (q :: Hom j) (f :: i -> j) (g :: i -> j) class ( Category (Op p) , Op (Op p) ~ p , Ob (Op p) ~ Ob p , FunctorOf' (Op p) (p ==> (->)) p , forall a. Ob p a => FunctorOf' p (->) (p a) ) => Category (p :: Hom k) where type Ob p :: k -> Constraint type Op p :: Hom k -- FunctorOf without superclasses, to work around issues with UndecidableSuperClasses class FunctorOf' p q (f :: i -> j) | f -> p q -- FunctorOf' with proper superclasses class ( FunctorOf' p q f , Category p , Category q , forall a. Ob p a => Ob q (f a) ) => FunctorOf p q f instance ( FunctorOf' p q f , Category p , Category q , forall a. Ob p a => Ob q (f a) ) => FunctorOf p q f }}} Note that `Category p` has a superclass `Category (Op p)`, which has a superclass: {{{#!hs -- noting that Ob (Op p) ~ Ob p forall a. Ob p a => FunctorOf' (Op p) (->) (Op p a) }}} and that the superclasses of `FunctorOf p q f` include: {{{#!hs forall a. Ob p a => Ob q (f a) forall a. Ob p a => FunctorOf' (Op p) (->) (Op p a) forall a. Ob q a => FunctorOf' (Op q) (->) (Op q a) }}} All of these have independent type families in the heads. Floating them out manually requires doubling the number of class parameters for both `Category` and `FunctorOf`: {{{#!hs class (..., op ~ Op p) => Category op p where ... class ( FunctorOf' p q f , Category opP p , Category opQ q , obQ ~ Ob q , forall a. Ob p a => obQ (f a) ) => FunctorOf opP p opQ q obQ f }}} These parameters will spread throughout all of the code. Subclasses will add yet more parameters, and will never be able to use type families for anything which is a functor or a category, without sacrificing some QCs. Types will be lost in a sea of parameters. This ends up being more painful than just using `Dict`s. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 21:59:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 21:59:26 -0000 Subject: [GHC] #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) In-Reply-To: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> References: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> Message-ID: <065.d97406293dcebd36d37e6fc666356bc9@haskell.org> #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"0dc86f6bc454253969dedc31bed477eded4cf82d/ghc" 0dc86f6b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0dc86f6bc454253969dedc31bed477eded4cf82d" Clone relevant constraints to avoid side-effects on HoleDests. Fixes #15370. Summary: When looking for valid hole fits, the constraints relevant to the hole may sometimes contain a HoleDest. Previously, these were not cloned, which could cause the filling of filled coercion hole being, which would cause an assert to fail. This is now fixed. Test Plan: Regression test included. Reviewers: simonpj, bgamari, goldfire Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15370 Differential Revision: https://phabricator.haskell.org/D5004 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 22:01:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 22:01:15 -0000 Subject: [GHC] #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) In-Reply-To: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> References: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> Message-ID: <065.ee1c0ca80c27572de94e5e38a34d03c6@haskell.org> #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: merge Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 23:15:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 23:15:31 -0000 Subject: [GHC] #15426: `elemIndex` and `findIndex` still can't fuse In-Reply-To: <045.556cc5a15fe7d0c4bec73444eba7ef79@haskell.org> References: <045.556cc5a15fe7d0c4bec73444eba7ef79@haskell.org> Message-ID: <060.74417140a3c7d3d0d37f5a672fb760bd@haskell.org> #15426: `elemIndex` and `findIndex` still can't fuse -------------------------------------+------------------------------------- Reporter: kabuhr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries/base | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Looks plausible to me. Would anyone like to submit a patch and (preferably) a test that demonstrates fusion. Please include a Note with the INLINABLE pragma to explain carefully why it's there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 23:16:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 23:16:11 -0000 Subject: [GHC] #15427: Calling hs_try_putmvar from an unsafe foreign call can cause the RTS to hang In-Reply-To: <049.decdf9f369f07feac7a1415f9c9ba9fe@haskell.org> References: <049.decdf9f369f07feac7a1415f9c9ba9fe@haskell.org> Message-ID: <064.cc01ca7f9bc0458eea6ee870f4c7a314@haskell.org> #15427: Calling hs_try_putmvar from an unsafe foreign call can cause the RTS to hang -------------------------------------+------------------------------------- Reporter: syntheorem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 24 23:19:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 24 Jul 2018 23:19:19 -0000 Subject: [GHC] #15436: Compile-time panic, Prelude.!!: negative index Message-ID: <047.11105fbd3a2250b4dd24d6c191fbb08d@haskell.org> #15436: Compile-time panic, Prelude.!!: negative index -------------------------------------+------------------------------------- Reporter: pbrisbin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here is a reproduction case: **ghc-repro.cabal** {{{ name: ghc-repro version: 0.0.0 build-type: Simple cabal-version: >= 1.10 library exposed-modules: Lib other-modules: Paths_ghc_repro hs-source-dirs: src build-depends: base default-language: Haskell2010 }}} **src/Lib.hs** {{{#!hs {-# OPTIONS_GHC -v4 #-} module Lib where import GHC.Enum -- | At this many elements, it panics. One fewer, it works data USState = AL | AK | AZ | AR | CA | CO | CT | DE | FL -- | GA -- | HI | ID | IL | IN | IA | KS | KY | LA | ME | MD -- | MA | MI | MN | MS | MO | MT | NE | NV | NH | NJ -- | NM | NY | NC | ND | OH | OK | OR | PA | RI | SC -- | SD | TN | TX | UT | VT | VA | WA | WV | WI | WY -- | DC | PR | VI | AS | GU | MP | AA | AE | AP deriving (Eq, Show, Ord, Bounded, Read, Enum) data USStateOrIntl = International | US USState instance Enum USStateOrIntl where fromEnum International = 0 fromEnum (US s) = 1 + fromEnum s enumFrom = boundedEnumFrom enumFromThen = boundedEnumFromThen toEnum 0 = International toEnum i = US . toEnum $ i - 1 instance Bounded USStateOrIntl where minBound = International maxBound = US maxBound }}} **Results**: {{{ ghc-repro-0.0.0: build (lib) Preprocessing library for ghc-repro-0.0.0.. Building library for ghc-repro-0.0.0.. Running phase HsPp HsSrcFile compile: input file src/Lib.hs *** Checking old interface for ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib (use -ddump-hi-diffs for more details): [1 of 2] Compiling Lib ( src/Lib.hs, .stack- work/dist/x86_64-linux/Cabal-2.2.0.1/build/Lib.o ) *** Parser [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: !!! Parser [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 8.31 milliseconds, allocated 17.533 megabytes *** Renamer/typechecker [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: !!! Renamer/typechecker [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 354.49 milliseconds, allocated 312.556 megabytes *** Desugar [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: Result size of Desugar (after optimization) = {terms: 752, types: 352, coercions: 33, joins: 1/4} !!! Desugar [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 142.79 milliseconds, allocated 226.278 megabytes *** Simplifier [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: Result size of Simplifier iteration=1 = {terms: 1,222, types: 790, coercions: 143, joins: 1/3} Result size of Simplifier iteration=2 = {terms: 1,219, types: 788, coercions: 126, joins: 0/1} Result size of Simplifier = {terms: 1,217, types: 786, coercions: 123, joins: 0/1} !!! Simplifier [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 374.08 milliseconds, allocated 587.256 megabytes *** Specialise [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: Result size of Specialise = {terms: 1,217, types: 786, coercions: 123, joins: 0/1} !!! Specialise [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 154.05 milliseconds, allocated 235.323 megabytes *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [ghc- repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 1,551, types: 1,410, coercions: 123, joins: 0/0} !!! Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [ghc- repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: finished in 6.24 milliseconds, allocated 5.556 megabytes *** Simplifier [ghc-repro-0.0.0-K1NxTAQg5MjG2d3fZc1tOj:Lib]: Result size of Simplifier iteration=1 = {terms: 1,667, types: 1,082, coercions: 123, joins: 7/19} ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): Prelude.!!: negative index Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The above output was produced through my normal tooling, so {{{ stack build --resolver lts-12.2 --pedantic }}} To rule out stack, I was also able to reproduce the panic with plain cabal using this **Dockerfile**: {{{ FROM haskell:8.4.3 RUN mkdir /src WORKDIR /src COPY ghc-repro.cabal /src/ghc-repo.cabal COPY src/Lib.hs /src/src/Lib.hs RUN cabal build }}} {{{ docker build --tag ghc-repro . }}} It still panics, but the output is different and much larger so I'll leave it here: https://8n1.org/13499/5c92 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 02:28:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 02:28:24 -0000 Subject: [GHC] #15349: fixST is a bit wrong In-Reply-To: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> References: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> Message-ID: <060.4dfdacaa6a1c105d42fdd38489a6ec15@haskell.org> #15349: fixST is a bit wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4948 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I took a deep dive into lazy `ST` and came up with an absurdly inefficient "reference implementation" that I believe should be extremely correct. How inefficient? The monadic bind creates three `MVar`s and two green threads! I wonder if someone has a good idea about how to turn that into something both correct and efficient. The idea here is to turn each suspended computation into its very own green thread, and to use `MVar`s to communicate between them. One `MVar` requests a state token, while another is used to transfer one. {{{#!hs {-# language MagicHash, UnboxedTuples, GADTs, RankNTypes, BangPatterns #-} module Control.Monad.ST.Lazy.Imp where import qualified Control.Monad.ST as ST import qualified GHC.ST as ST import GHC.IO import GHC.Exts import Control.Concurrent.MVar import Control.Monad import Control.Applicative import Control.Concurrent infixl 1 :>>= data ST s a where Pure :: a -> ST s a StrictToLazyST :: ST.ST s a -> ST s a (:>>=) :: ST s a -> (a -> ST s b) -> ST s b FixST :: (a -> ST s a) -> ST s a strictToLazyST :: ST.ST s a -> ST s a strictToLazyST = StrictToLazyST instance Functor (ST s) where fmap = liftM instance Applicative (ST s) where pure = Pure (<*>) = ap liftA2 = liftM2 instance Monad (ST s) where (>>=) = (:>>=) data State s = State (State# s) -- We don't care about thread IDs forkIO_ :: IO () -> IO () forkIO_ m = void (forkIO m) run -- Request and receive a state token :: MVar () -> MVar (State RealWorld) -- Wait for a request and provide a state token -> MVar () -> MVar (State RealWorld) -> ST RealWorld a -> IO a run !s_in !m_in !s_out !m_out (Pure a) = do forkIO_ $ do readMVar s_out -- If we need the state, _ <- tryPutMVar s_in () -- request the state takeMVar m_in >>= putMVar m_out -- and transfer it pure () pure a run s_in m_in _s_out m_out (StrictToLazyST (ST.ST m)) = do putMVar s_in () -- Request the state State s <- takeMVar m_in -- Get the state case m s of (# s', a #) -> do putMVar m_out (State s') -- Put the new state pure a -- This is the hard case. We have to 'run' @n@ if we need -- *either* its state token *or* its value. run s_in m_in s_out m_out (n :>>= f) = do sn_out <- newEmptyMVar n_out <- newEmptyMVar resv <- newEmptyMVar -- run_it gets filled if we need to run @n@, either for its -- value or for its state. run_it <- newEmptyMVar forkIO_ $ readMVar sn_out >> tryPutMVar run_it () >> return () forkIO_ $ do readMVar run_it res <- run s_in m_in sn_out n_out n putMVar resv res run sn_out n_out s_out m_out (f $ unsafeDupablePerformIO $ tryPutMVar run_it () >> readMVar resv) run s_in m_in s_out m_out (FixST f) = do resv <- newEmptyMVar res <- run s_in m_in s_out m_out (f $ unsafeDupablePerformIO $ readMVar resv) putMVar resv res pure res runST :: (forall s. ST s a) -> a runST st = runRW# $ \s -> let ss = State s in case unIO (do s_in <- newEmptyMVar m_in <- newMVar ss s_out <- newEmptyMVar m_out <- newEmptyMVar run s_in m_in s_out m_out st) s of (# _, a #) -> a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 02:35:04 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 02:35:04 -0000 Subject: [GHC] #15349: fixST is a bit wrong In-Reply-To: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> References: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> Message-ID: <060.14e1eb6769a0c2a1fc57a70033419720@haskell.org> #15349: fixST is a bit wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4948 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Note: the crazy implementation above never actually needs to `takeMVar`; `readMVar` should be sufficient. So `IVar`s would be sufficient. But to get close to something practical, we need to avoid `forkIO`. Maybe I can do that; I'm not sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 07:19:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 07:19:30 -0000 Subject: [GHC] #15436: Compile-time panic, Prelude.!!: negative index In-Reply-To: <047.11105fbd3a2250b4dd24d6c191fbb08d@haskell.org> References: <047.11105fbd3a2250b4dd24d6c191fbb08d@haskell.org> Message-ID: <062.da9bd1b58c81295f7244982fcf31a22b@haskell.org> #15436: Compile-time panic, Prelude.!!: negative index -------------------------------------+------------------------------------- Reporter: pbrisbin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * version: 8.4.3 => 8.5 Comment: Confirmed on GHC HEAD. To reproduce without cabal just do `ghc-stage2 Lib.hs -O`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 07:39:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 07:39:46 -0000 Subject: [GHC] #15436: Compile-time panic, Prelude.!!: negative index In-Reply-To: <047.11105fbd3a2250b4dd24d6c191fbb08d@haskell.org> References: <047.11105fbd3a2250b4dd24d6c191fbb08d@haskell.org> Message-ID: <062.05964c02b9c9139e9288ad74b5df8539@haskell.org> #15436: Compile-time panic, Prelude.!!: negative index -------------------------------------+------------------------------------- Reporter: pbrisbin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): The failing `!!` call is this (in PrelRules.hs): {{{ get_con :: Type -> ConTagZ -> DataCon get_con ty tag = tyConDataCons (tyConAppTyCon ty) !! tag }}} Which is passed a negative tag in this call site probably (same file): {{{ tx_con_dtt ty (LitAlt (LitNumber LitNumInt i _)) = DataAlt (get_con ty (fromInteger i)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 07:44:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 07:44:26 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.af6e4224a8490d934deb24f9ca99ddc0@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): So far, a naive attempt at rewriting `tcvs_of_type` in terms of `VarSet -> VarSet` didn't produce significant performance improvements; however, I have not eliminated `unionVarSet` completely yet - the `ForAll` cases in both `tcvs_of_type` and `tcvs_of_co` are both such that naively expressing them as compositions of applications of `tcvs_of_...` and `delVarSet` does not produce correct results - I assume this is because the order in which vars are added and deleted from the set matter. So I'm now testing a replacement for `delVarSet` that is written in terms of set insertions instead of set unions; hopefully this will show a bigger difference. I should probably also benchmark the relevant set operations on their own, to verify that they do indeed expose the performance issue we're suspecting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 09:21:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 09:21:43 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.ca9349cf6a41f539aaafa2bb4730f757@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Update; the rewritten `unionVarSet` performs significantly worse than the original one. So either I did something wrong there, or our suspicion isn't correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 09:30:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 09:30:54 -0000 Subject: [GHC] #15437: Internal error when applying a scoped type variable inside a typed expression quotation Message-ID: <047.2c380fe49bc2106873d739da05bad0b7@haskell.org> #15437: Internal error when applying a scoped type variable inside a typed expression quotation -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TemplateHaskell #-} import TestMod f :: Int f = $$(foo) main :: IO () main = main }}} {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeApplications #-} module TestMod where import Language.Haskell.TH.Syntax (Q, TExp) get :: forall a. Int get = 1 foo :: forall a. Q (TExp Int) foo = [|| get @a ||] }}} {{{ Test.hs:6:8: error: • The exact Name ‘a’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful • In the result of the splice: $foo To see what the splice expanded to, use -ddump-splices In the Template Haskell splice $$(foo) In the expression: $$(foo) | 6 | f = $$(foo) | ^^^ Test.hs:6:8: error: • GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [r3Kl :-> Identifier[f::Int, TopLevelLet [] True], r3PI :-> Identifier[main::IO (), TopLevelLet [r3PI :-> main] True]] • In the type ‘a’ In the expression: get @a In the result of the splice: $foo To see what the splice expanded to, use -ddump-splices | 6 | f = $$(foo) | }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 10:15:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 10:15:52 -0000 Subject: [GHC] #15438: Misleading error message for higher rank type Message-ID: <046.9cf33af1ac16400854deead46b4c071a@haskell.org> #15438: Misleading error message for higher rank type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{ foo :: (forall a b. C a b => b -> b) -> Int foo = error "urk" }}} With GHC (for ages, incl 8.6) we get {{{ • Could not deduce (C a0 b) from the context: C a b bound by the type signature for: foo :: forall a b. C a b => b -> b <======= Not true! at Foo.hs:7:8-43 The type variable ‘a0’ is ambiguous • In the ambiguity check for ‘foo’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature: foo :: (forall a b. C a b => b -> b) -> Int }}} But `foo`'s type signature is NOT `foo :: forall a b. C a b => b -> b`!! Let's fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 11:24:41 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 11:24:41 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.8d2a95302da0483bf1280e6ff3f35d0a@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > So far, a naive attempt at rewriting tcvs_of_type in terms of VarSet -> VarSet didn't produce significant performance improvements What does the naive attempt look like. I'm expecting: {{{ tcvs_of_type :: Type -> VarSet -> VarSet tcvs_of_type (App t1 t2) acc = tcvs_of_type t1 (tcvs_of_type t2 acc) ...etc... }}} Is that what you have? I would not worry about foralls -- they are relatively rare. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 11:25:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 11:25:47 -0000 Subject: [GHC] #15438: Misleading error message for higher rank type In-Reply-To: <046.9cf33af1ac16400854deead46b4c071a@haskell.org> References: <046.9cf33af1ac16400854deead46b4c071a@haskell.org> Message-ID: <061.ea7de8ec072bbf6007aed1ab31df54d1@haskell.org> #15438: Misleading error message for higher rank type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"12c0f03a66bcd978bda6472384ddc0348c5a1d7a/ghc" 12c0f03a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="12c0f03a66bcd978bda6472384ddc0348c5a1d7a" Set GenSigCtxt for the argument part of tcSubType The reason for this change is described in TcUnify Note [Settting the argument context], and Trac #15438. The only effect is on error messages, where it stops GHC reporting an outright falsity (about the type signature for a function) when it finds an errors in a higher-rank situation. The testsuite changes in this patch illustrate the problem. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 11:25:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 11:25:47 -0000 Subject: [GHC] #14185: Non-local bug reporting around levity polymorphism In-Reply-To: <047.b7b54b9f6935b8234dc0884836db560a@haskell.org> References: <047.b7b54b9f6935b8234dc0884836db560a@haskell.org> Message-ID: <062.cf179809660763c5dfb1e844273c1bf7@haskell.org> #14185: Non-local bug reporting around levity polymorphism -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: | LevityPolymorphism, | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"6c19112ece09a098c71faac1f7a58dbb1e63ee71/ghc" 6c19112/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6c19112ece09a098c71faac1f7a58dbb1e63ee71" Build more implications The "non-local error" problem in Trac #14185 was due to the interaction of constraints from different function definitions. This patch makes a start towards fixing it. It adds TcUnify.alwaysBuildImplication to unconditionally build an implication in some cases, to keep the constraints from different functions separate. See the new Note [When to build an implication] in TcUnify. But a lot of error messages change, so for now I have set alwaysBuildImplication = False Result: no operational change at all. I'll get back to it! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 11:25:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 11:25:48 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.b6b181efbcb5cded510edfe4fe5c9dae@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Typeable, Resolution: | LevityPolymorphism, Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3316 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c5d31df70b16dc346b5860077c8bbe585ddb7a78/ghc" c5d31df7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c5d31df70b16dc346b5860077c8bbe585ddb7a78" Treat isConstraintKind more consistently It turned out that we were not being consistent about our use of isConstraintKind. It's delicate, because the typechecker treats Constraint and Type as /distinct/, whereas they are the /same/ in the rest of the compiler (Trac #11715). And had it wrong, which led to Trac #15412. This patch does the following: * Rename isConstraintKind to tcIsConstraintKind returnsConstraintKind to tcReturnsConstraintKind to emphasise that they use the 'tcView' view of types. * Move these functions, and some related ones (tcIsLiftedTypeKind), from Kind.hs, to group together in Type.hs, alongside isPredTy. It feels very unsatisfactory that these 'tcX' functions live in Type, but it happens because isPredTy is called later in the compiler too. But it's a consequence of the 'Constraint vs Type' dilemma. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 11:25:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 11:25:47 -0000 Subject: [GHC] #15413: Poor error message when trying to import non-existent class methods In-Reply-To: <057.fe732ba2a4ee42f10d59fc52f46c8bd8@haskell.org> References: <057.fe732ba2a4ee42f10d59fc52f46c8bd8@haskell.org> Message-ID: <072.75003dbcdf248c741590179b0c4649ab@haskell.org> #15413: Poor error message when trying to import non-existent class methods -------------------------------------+------------------------------------- Reporter: | Owner: (none) quasicomputational | Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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 Simon Peyton Jones ): In [changeset:"f7d3054a133247cea1f488993695d3cbb941f29d/ghc" f7d3054a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f7d3054a133247cea1f488993695d3cbb941f29d" Improve error message on un-satisfied import Consider import M( C( a,b,c ) ) where class C is defined as module M where class C x where a :: blah c :: blah Tnen (Trac #15413) we'd like to get an error message only about failing to import C( b ), not C( a,b,c ). This was fairly easy (and local) to do. Turned out that the existing tests mod81 and mod91 are adequate tests for the feature. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 11:25:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 11:25:48 -0000 Subject: [GHC] #15412: "Instance head is not headed by a class" when `Constraint` replaced with `type C = Constraint` In-Reply-To: <051.c4281f14deae6a8271fa4ba5fd050a12@haskell.org> References: <051.c4281f14deae6a8271fa4ba5fd050a12@haskell.org> Message-ID: <066.93e13646ad61ac06ac9e1e014b52bc0d@haskell.org> #15412: "Instance head is not headed by a class" when `Constraint` replaced with `type C = Constraint` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c5d31df70b16dc346b5860077c8bbe585ddb7a78/ghc" c5d31df7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c5d31df70b16dc346b5860077c8bbe585ddb7a78" Treat isConstraintKind more consistently It turned out that we were not being consistent about our use of isConstraintKind. It's delicate, because the typechecker treats Constraint and Type as /distinct/, whereas they are the /same/ in the rest of the compiler (Trac #11715). And had it wrong, which led to Trac #15412. This patch does the following: * Rename isConstraintKind to tcIsConstraintKind returnsConstraintKind to tcReturnsConstraintKind to emphasise that they use the 'tcView' view of types. * Move these functions, and some related ones (tcIsLiftedTypeKind), from Kind.hs, to group together in Type.hs, alongside isPredTy. It feels very unsatisfactory that these 'tcX' functions live in Type, but it happens because isPredTy is called later in the compiler too. But it's a consequence of the 'Constraint vs Type' dilemma. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 11:35:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 11:35:57 -0000 Subject: [GHC] #15438: Misleading error message for higher rank type In-Reply-To: <046.9cf33af1ac16400854deead46b4c071a@haskell.org> References: <046.9cf33af1ac16400854deead46b4c071a@haskell.org> Message-ID: <061.02a39feb1593f2de94730adc656d4553@haskell.org> #15438: Misleading error message for higher rank type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T15438 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_fail/T15438 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 11:36:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 11:36:48 -0000 Subject: [GHC] #15413: Poor error message when trying to import non-existent class methods In-Reply-To: <057.fe732ba2a4ee42f10d59fc52f46c8bd8@haskell.org> References: <057.fe732ba2a4ee42f10d59fc52f46c8bd8@haskell.org> Message-ID: <072.35f67113b9d228ffd85ad5a0a7b22fc8@haskell.org> #15413: Poor error message when trying to import non-existent class methods -------------------------------------+------------------------------------- Reporter: | Owner: (none) quasicomputational | Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: module/mod81, | mod91 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => module/mod81, mod91 * resolution: => fixed Comment: Good idea, thank you! And fairly easy to implement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 11:37:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 11:37:51 -0000 Subject: [GHC] #15412: "Instance head is not headed by a class" when `Constraint` replaced with `type C = Constraint` In-Reply-To: <051.c4281f14deae6a8271fa4ba5fd050a12@haskell.org> References: <051.c4281f14deae6a8271fa4ba5fd050a12@haskell.org> Message-ID: <066.45ac7743253e95eb5fca96cf572d7e44@haskell.org> #15412: "Instance head is not headed by a class" when `Constraint` replaced with `type C = Constraint` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/typecheck/should_compile/T15412 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => testsuite/tests/typecheck/should_compile/T15412 Comment: Wow, that was bad! Thank you for reporting; now fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 11:41:17 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 11:41:17 -0000 Subject: [GHC] #15437: Internal error when applying a scoped type variable inside a typed expression quotation In-Reply-To: <047.2c380fe49bc2106873d739da05bad0b7@haskell.org> References: <047.2c380fe49bc2106873d739da05bad0b7@haskell.org> Message-ID: <062.d0c0ebf2fa5c0844e4750eb910b11ea3@haskell.org> #15437: Internal error when applying a scoped type variable inside a typed expression quotation -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * component: Compiler => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 12:25:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 12:25:52 -0000 Subject: [GHC] #15436: Compile-time panic, Prelude.!!: negative index In-Reply-To: <047.11105fbd3a2250b4dd24d6c191fbb08d@haskell.org> References: <047.11105fbd3a2250b4dd24d6c191fbb08d@haskell.org> Message-ID: <062.47a8c0f98bf04a52768b395e3787d832@haskell.org> #15436: Compile-time panic, Prelude.!!: negative index -------------------------------------+------------------------------------- Reporter: pbrisbin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): `-fno-case-folding` makes the panic disappear -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 12:30:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 12:30:26 -0000 Subject: [GHC] #15436: Compile-time panic, Prelude.!!: negative index In-Reply-To: <047.11105fbd3a2250b4dd24d6c191fbb08d@haskell.org> References: <047.11105fbd3a2250b4dd24d6c191fbb08d@haskell.org> Message-ID: <062.65b906eb9bba54f0ebccaf4ce925f697@haskell.org> #15436: Compile-time panic, Prelude.!!: negative index -------------------------------------+------------------------------------- Reporter: pbrisbin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) Comment: This was probably caused by commit 193664d42dbceadaa1e4689dfa17ff1cf5a405a0 (`Re-engineer caseRules to add tagToEnum/dataToTag`), considering that this panic does not occur on GHC 8.2 or earlier (see also #14680). simonpj, do you know what is happening here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 12:33:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 12:33:48 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.b7ffbd40eae39436cb969f295f639b9a@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Yes, that's essentially what I have. Specifically: {{{#!haskell tcvs_of_type' :: Type -> TyCoVarSetNotClosed -> TyCoVarSetNotClosed tcvs_of_type' (TyVarTy v) = flip extendVarSet v tcvs_of_type' (TyConApp _ tys) = tcvs_of_types' tys tcvs_of_type' (LitTy {}) = id tcvs_of_type' (AppTy fun arg) = tcvs_of_type' fun . tcvs_of_type' arg tcvs_of_type' (FunTy arg res) = tcvs_of_type' arg . tcvs_of_type' res tcvs_of_type' (ForAllTy (TvBndr tv _) ty) = unionVarSet (delVarSet (tcvs_of_type ty) tv) . tcvs_of_type' (tyVarKind tv) tcvs_of_type' (CastTy ty co) = tcvs_of_type' ty . tcvs_of_co' co tcvs_of_type' (CoercionTy co) = tcvs_of_co' co tcvs_of_types :: [Type] -> TyCoVarSetNotClosed tcvs_of_types ts = tcvs_of_types' ts emptyVarSet tcvs_of_types' :: [Type] -> TyCoVarSetNotClosed -> TyCoVarSetNotClosed tcvs_of_types' [] = id tcvs_of_types' (t:ts) = tcvs_of_type' t . tcvs_of_types' ts tcvs_of_co :: Coercion -> TyCoVarSetNotClosed tcvs_of_co co = tcvs_of_co' co emptyVarSet tcvs_of_co' :: Coercion -> TyCoVarSetNotClosed -> TyCoVarSetNotClosed tcvs_of_co' (Refl _ ty) = tcvs_of_type' ty tcvs_of_co' (TyConAppCo _ _ cos) = tcvs_of_cos' cos tcvs_of_co' (AppCo co arg) = tcvs_of_co' co . tcvs_of_co' arg tcvs_of_co' (ForAllCo tv kind_co co) = unionVarSet (delVarSet (tcvs_of_co co) tv) . tcvs_of_co' kind_co tcvs_of_co' (FunCo _ co1 co2) = tcvs_of_co' co1 . tcvs_of_co' co2 tcvs_of_co' (CoVarCo v) = flip extendVarSet v tcvs_of_co' (HoleCo h) = flip extendVarSet (coHoleCoVar h) -- See Note [CoercionHoles and coercion free variables] tcvs_of_co' (AxiomInstCo _ _ cos) = tcvs_of_cos' cos tcvs_of_co' (UnivCo p _ t1 t2) = tcvs_of_prov' p . tcvs_of_type' t1 . tcvs_of_type' t2 tcvs_of_co' (SymCo co) = tcvs_of_co' co tcvs_of_co' (TransCo co1 co2) = tcvs_of_co' co1 . tcvs_of_co' co2 tcvs_of_co' (NthCo _ _ co) = tcvs_of_co' co tcvs_of_co' (LRCo _ co) = tcvs_of_co' co tcvs_of_co' (InstCo co arg) = tcvs_of_co' co . tcvs_of_co' arg tcvs_of_co' (CoherenceCo c1 c2) = tcvs_of_co' c1 . tcvs_of_co' c2 tcvs_of_co' (KindCo co) = tcvs_of_co' co tcvs_of_co' (SubCo co) = tcvs_of_co' co tcvs_of_co' (AxiomRuleCo _ cos) = tcvs_of_cos' cos tcvs_of_cos :: [Coercion] -> TyCoVarSetNotClosed tcvs_of_cos co = tcvs_of_cos' co emptyVarSet tcvs_of_cos' :: [Coercion] -> TyCoVarSetNotClosed -> TyCoVarSetNotClosed tcvs_of_cos' [] = id tcvs_of_cos' (co:cos) = tcvs_of_co' co . tcvs_of_cos' cos -- tcvs_of_prov :: UnivCoProvenance -> TyCoVarSetNotClosed -- tcvs_of_prov p = tcvs_of_prov' p emptyVarSet tcvs_of_prov' :: UnivCoProvenance -> TyCoVarSetNotClosed -> TyCoVarSetNotClosed tcvs_of_prov' UnsafeCoerceProv = id tcvs_of_prov' (PhantomProv co) = tcvs_of_co' co tcvs_of_prov' (ProofIrrelProv co) = tcvs_of_co' co tcvs_of_prov' (PluginProv _) = id }}} So the `'`-ed versions are the ones with an accumulator; I kept the original ones around but rewrote them in terms of the accumulator version so that other functions that depend on them keep working unchanged. Apart from the forall cases, everything goes through the accumulator version, and uses only single-var insertions and no unions. I also rewrote the plural ones (`tcvs_of_cos` / `tcvs_of_types`) to avoid unions there. The only real difference I can see here is that I used point-free style over parentheses, but that surely ought not to make a difference. There is a slight performance improvement over the union-based version, but not enough to explain the test failures, and it's still nowhere near the original numbers. To wit: Pre-patch: {{{ /home/tobias/well-typed/devel/ghc-phab/inplace/lib/bin/ghc-stage2 -B/home/tobias/well-typed/devel/ghc-phab/inplace/lib -c testsuite/tests/perf/compiler/T5631.hs -fforce-recomp +RTS -rlogs/old.ticky STACK USAGE: ENTERS: 51211603 of which 51211603 (100.0%) direct to the entry code [the rest indirected via Node's info ptr] 6192996 ( 12.1%) thunks 3676345 ( 7.2%) data values 0 ( 0.0%) normal indirections 0 ( 0.0%) permanent indirections FUNCTION ENTRIES: 41342262 TAIL CALLS: 33149658, of which 27886423 (84%) were to known functions SLOW APPLICATIONS: 0 evaluated, 0 unevaluated Too few args Correct args Too many args FUN 0 0 0 PAP 0 0 0 RETURNS: 23002648 11895484 ( 51.7%) from entering a new constructor [the rest from entering an existing constructor] RET_NEW: 11895484: 36.3% 13.5% 24.9% 4.5% 19.1% 0.9% 0.3% 0.2% 0.4% RET_OLD: 3676345: 11.6% 18.6% 18.8% 5.7% 6.3% 20.5% 0.3% 1.1% 17.1% RET_UNBOXED_TUP: 7430819: 0.0% 68.9% 29.7% 1.2% 0.1% 0.0% 0.1% 0.1% 0.0% }}} Post-patch: {{{ /home/tobias/well-typed/devel/ghc-phab/inplace/lib/bin/ghc-stage2 -B/home/tobias/well-typed/devel/ghc-phab/inplace/lib -c testsuite/tests/perf/compiler/T5631.hs -fforce-recomp +RTS -rlogs/new.ticky STACK USAGE: ENTERS: 54717036 of which 54717036 (100.0%) direct to the entry code [the rest indirected via Node's info ptr] 6198335 ( 11.3%) thunks 4824139 ( 8.8%) data values 0 ( 0.0%) normal indirections 0 ( 0.0%) permanent indirections FUNCTION ENTRIES: 43694562 TAIL CALLS: 35496964, of which 29883207 (84%) were to known functions SLOW APPLICATIONS: 0 evaluated, 0 unevaluated Too few args Correct args Too many args FUN 0 0 0 PAP 0 0 0 RETURNS: 24705888 13776908 ( 55.8%) from entering a new constructor [the rest from entering an existing constructor] RET_NEW: 13776908: 36.0% 11.6% 25.9% 3.9% 21.1% 0.8% 0.2% 0.1% 0.3% RET_OLD: 4824139: 23.8% 14.1% 20.4% 4.4% 7.6% 15.6% 0.3% 0.9% 13.0% RET_UNBOXED_TUP: 6104841: 0.0% 83.5% 14.8% 1.4% 0.1% 0.0% 0.1% 0.1% 0.0% }}} Post-patch with rewritten `tcvs...` functions: {{{ /home/tobias/well-typed/devel/ghc-phab/inplace/lib/bin/ghc-stage2 -B/home/tobias/well-typed/devel/ghc-phab/inplace/lib -c testsuite/tests/perf/compiler/T5631.hs -fforce-recomp +RTS -rlogs/new- accum.ticky STACK USAGE: ENTERS: 54394961 of which 54394961 (100.0%) direct to the entry code [the rest indirected via Node's info ptr] 6198336 ( 11.4%) thunks 4906771 ( 9.0%) data values 0 ( 0.0%) normal indirections 0 ( 0.0%) permanent indirections FUNCTION ENTRIES: 43289854 TAIL CALLS: 35075741, of which 29461984 (84%) were to known functions SLOW APPLICATIONS: 0 evaluated, 0 unevaluated Too few args Correct args Too many args FUN 0 0 0 PAP 0 0 0 RETURNS: 24431674 13420062 ( 54.9%) from entering a new constructor [the rest from entering an existing constructor] RET_NEW: 13420062: 32.7% 11.9% 25.9% 4.0% 24.0% 0.8% 0.2% 0.1% 0.4% RET_OLD: 4906771: 26.3% 13.9% 17.1% 4.3% 9.2% 15.3% 0.3% 0.9% 12.8% RET_UNBOXED_TUP: 6104841: 0.0% 83.5% 14.8% 1.4% 0.1% 0.0% 0.1% 0.1% 0.0% }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 12:34:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 12:34:14 -0000 Subject: [GHC] #15416: Higher rank types in pattern synonyms In-Reply-To: <044.53c8e12910c3cdd85f926a53a436c321@haskell.org> References: <044.53c8e12910c3cdd85f926a53a436c321@haskell.org> Message-ID: <059.506e01ba25f6afa0ce0b8fc29469745b@haskell.org> #15416: Higher rank types in pattern synonyms -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): You are treading on thin ice. Consider this {{{ f1 :: (forall a. a->a) -> Int f1 (x :: forall b. b->b) = x 3 f2 :: (forall a. a->a) -> Int f2 x = case x of (y :: forall b. b->b) -> y 3 }}} You might expect `f1` and `f2` to behave the same, because `f2` only replaces inline pattern matching with a case-expression. But `f1` as accepted and `f2` is rejected thus {{{ * Couldn't match expected type `a0 -> a0' with actual type `forall b. b -> b' * When checking that the pattern signature: forall b. b -> b fits the type of its context: a0 -> a0 In the pattern: y :: forall b. b -> b In a case alternative: (y :: forall b. b -> b) -> y 3 | 10 | (y :: forall b. b->b) -> y 3 }}} Very similar to the failure you see. Why? * In `f1` the higher-rank type inference machinery "pushes down" the type of the argument, from `f1`'s type signature, into the pattern `(x :: forall b. b->b)`. * But in `f2`, the variable `x` indeed gets type `forall b. b->b` (via this same push-down mechanism, but then ''that type gets instantiated at the call site of `x`''. So the scrutinee of the `case` has type `alpha -> alpha`, for some as-yet-unknown type `alpha`. And that, of course, is not polymorphic enough. * The type inference engine never generalises the scrutinee of a `case`. (I suppose one could revisit that, though I do not know how.) I hope that explains why your fourth example breaks. When we first did pattern synonyms I expected the types to always be of form {{{ K :: t1 -> ... -> tn -> T s1 .. sm }}} where `T` is a data type. We loosened that up a bit to allow arbitrary return types. (I forget what the motivation was; I wonder if anyone else remembers? There may be a ticket.) What you are doing is putting a `forall` in that return position. I never considered that! It would be interesting to see a compelling motivation for doing this. Eg why don't you say this? {{{ pattern N :: forall a r. () => () => r -> (a -> r) -> r pattern J :: forall a r. a -> r -> (a -> r) -> r }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 12:38:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 12:38:05 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.6ba1df32b0887a33ced9bb32f3d8d29b@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Let me urge you to try it with an explicit accumulator, exactly as I wrote it. I recall that this made a very big difference for Bartosz. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 12:41:16 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 12:41:16 -0000 Subject: [GHC] #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression In-Reply-To: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> References: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> Message-ID: <065.e98980271f40d19fb3001bc9be7851a1@haskell.org> #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | dependent/should_compile/T15346 Blocked By: | Blocking: Related Tickets: #15419 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Note to Ben: the commit in comment:11 depends on commit 55a3f8552c9dc9b84e204ec6623c698912795347 (`Refactor coercion rule`), which is not present in the GHC 8.6 branch. Moreover, it's a fairly hefty commit, so I'm not sure we'd want to backport it, either. If you don't want to backport that commit, the following patch should also work, without needing `GRefl`. (I've left out the test cases here for the sake of brevity.) {{{#!diff diff --git a/compiler/coreSyn/CoreOpt.hs b/compiler/coreSyn/CoreOpt.hs index 8684c84..11cbd1e 100644 --- a/compiler/coreSyn/CoreOpt.hs +++ b/compiler/coreSyn/CoreOpt.hs @@ -979,7 +979,7 @@ pushCoTyArg co ty | isForAllTy tyL = ASSERT2( isForAllTy tyR, ppr co $$ ppr ty ) - Just (ty `mkCastTy` mkSymCo co1, MCo co2) + Just (ty `mkCastTy` co1, MCo co2) | otherwise = Nothing @@ -989,8 +989,8 @@ pushCoTyArg co ty -- tyL = forall (a1 :: k1). ty1 -- tyR = forall (a2 :: k2). ty2 - co1 = mkNthCo Nominal 0 co - -- co1 :: k1 ~N k2 + co1 = mkSymCo (mkNthCo Nominal 0 co) + -- co1 :: k2 ~N k1 -- Note that NthCo can extract a Nominal equality between the -- kinds of the types related by a coercion between forall-types. -- See the NthCo case in CoreLint. diff --git a/compiler/types/Coercion.hs b/compiler/types/Coercion.hs index 2ca5151..1557ce0 100644 --- a/compiler/types/Coercion.hs +++ b/compiler/types/Coercion.hs @@ -1812,7 +1812,7 @@ liftCoSubstVarBndrUsing fun lc@(LC subst cenv) old_var Pair k1 _ = coercionKind eta new_var = uniqAway (getTCvInScope subst) (setVarType old_var k1) - lifted = Refl (TyVarTy new_var) + lifted = mkNomReflCo (TyVarTy new_var) `mkCoherenceRightCo` eta new_cenv = extendVarEnv cenv old_var lifted -- | Is a var in the domain of a lifting context? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 12:49:16 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 12:49:16 -0000 Subject: [GHC] #15437: Internal error when applying a scoped type variable inside a typed expression quotation In-Reply-To: <047.2c380fe49bc2106873d739da05bad0b7@haskell.org> References: <047.2c380fe49bc2106873d739da05bad0b7@haskell.org> Message-ID: <062.83dba020309878d285e63a2b404cf904@haskell.org> #15437: Internal error when applying a scoped type variable inside a typed expression quotation -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13587 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13587 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 12:49:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 12:49:27 -0000 Subject: [GHC] #13587: addTopDecls fails with typed Template Haskell In-Reply-To: <048.1e9cb82827e3acfaa8c4e1f0f4c12487@haskell.org> References: <048.1e9cb82827e3acfaa8c4e1f0f4c12487@haskell.org> Message-ID: <063.3a58711e7930fd8fe0f1b0dcc310881e@haskell.org> #13587: addTopDecls fails with typed Template Haskell -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15437 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15437 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 12:53:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 12:53:33 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.cd0c32b2c2764e6fc434d3a6784b8eae@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:53 simonpj]: > Let me urge you to try it with an explicit accumulator, exactly as I wrote it. > > I recall that this made a very big difference for Bartosz. Tried that, but it seems to make absolutely no difference (that is, allocations go down by less than 0.004%). Also worth noting that `VarSet` here is based on `IntMap`, not `Map` as you quoted. Not sure if that changes anything, but maybe `IntMap` doesn't have the same problem `Map` has. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 14:07:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 14:07:36 -0000 Subject: [GHC] #15436: Compile-time panic, Prelude.!!: negative index In-Reply-To: <047.11105fbd3a2250b4dd24d6c191fbb08d@haskell.org> References: <047.11105fbd3a2250b4dd24d6c191fbb08d@haskell.org> Message-ID: <062.2aba105badb9091dbf7d63e651291d6a@haskell.org> #15436: Compile-time panic, Prelude.!!: negative index -------------------------------------+------------------------------------- Reporter: pbrisbin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): Given this simpler code: {{{#!hs module Bug0 where import GHC.Enum data XXX = AL | AK | AZ | AR | CA | CO | CT | DE | FL deriving (Enum) data Z = Y | X XXX instance Enum Z where fromEnum (X s) = 1 + fromEnum s --fromEnum Y = 0 toEnum 0 = Y --toEnum i = X . toEnum $ i - 1 }}} We have the following sequence of transformations for `succ`: {{{#!hs toEnumZ :: Int -> Z toEnumZ 0 = Y toEnumZ x = ... fromEnumZ :: Z -> Int fromEnumZ Y = ... fromEnumZ (X x) = 1 + fromEnumX x succZ :: Z -> Z succZ = toEnumZ . (+1) . fromEnumZ ===> {inline toEnumZ} succZ z = case (fromEnumZ z) + 1 of 0 -> Y x -> ... ===> {case-folding} succZ z = case fromEnumZ z of -1 -> Y x -> ... }}} We could stop here: `fromEnumZ` is basically `dataToTag#` and we have a negative literal alternative. If we continue: {{{#!hs ===> {inline fromEnumZ} succZ z = case (case z of Y -> 0 (X x) -> 1 + fromEnumX x) of -1 -> Y x -> ... ===> {case-of-case} succZ z = case z of Y -> ... X x -> case 1 + fromEnumX x of -1 -> Y s -> ... }}} And this is what we get: {{{#!hs $csucc_a2vu :: Z -> Z $csucc_a2vu = \ (x_a2Km :: Z) -> case x_a2Km of { Y -> case lvl_s2RN of wild_00 { }; X s_aED -> case s_aED of x1_a2IA { __DEFAULT -> case GHC.Prim.dataToTag# @ XXX x1_a2IA of a#_aI4 { __DEFAULT -> case GHC.Prim.+# 1# a#_aI4 of lwild_s2St { __DEFAULT -> lvl_s2R2; -1# -> Bug0.Y } } } } }}} When we have fewer data constructors for XXX, `fromEnumX` is inlined as a case so there is no `dataToTag#` involved: {{{#!hs $csucc_a2vh :: Z -> Z $csucc_a2vh = \ (x_a2K7 :: Z) -> case x_a2K7 of { Y -> case lvl_s2Ry of wild_00 { }; X s_aEC -> join { $j_s2Sa :: GHC.Prim.Int# -> Z [LclId[JoinId(1)], Arity=1] $j_s2Sa (x1_a2Ka [OS=OneShot] :: GHC.Prim.Int#) = case x1_a2Ka of lwild_s2S9 { __DEFAULT -> lvl_s2QN; -1# -> Bug0.Y } } in case s_aEC of { AL -> jump $j_s2Sa 1#; AK -> jump $j_s2Sa 2#; AZ -> jump $j_s2Sa 3#; AR -> jump $j_s2Sa 4#; CA -> jump $j_s2Sa 5#; CO -> jump $j_s2Sa 6#; CT -> jump $j_s2Sa 7#; DE -> jump $j_s2Sa 8# } } }}} Perhaps we could simply discard negative literal alternatives when we match on `dataToTag#`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 14:37:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 14:37:20 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.682840e48505434b99dae4e4369a40a1@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I can confirm that my hypothesis in comment:46 did not yield fruit: it saved a whopping 400 bytes of allocation in `T5321Fun`, and that's it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 15:00:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 15:00:22 -0000 Subject: [GHC] #15439: Refactor `printMinimalImports` into two functions and reexport them Message-ID: <047.2af82a21a770553007c81fa29bcda40d@haskell.org> #15439: Refactor `printMinimalImports` into two functions and reexport them -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple imports,refactoring,source | plugins | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the `printMinimalImports` function finds set of minimal imports and prints them into file. * https://github.com/ghc/ghc/blob/0f5a63e3d763f18c683f076e0e96396166863f56/compiler/rename/RnNames.hs#L1469 But it's more convenient to have function that returns set of minimal imports that can later be used by external tools like source plugins without need to parse content of `.import` file. And without need to copy- paste existing function. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 15:06:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 15:06:56 -0000 Subject: [GHC] #15439: Refactor `printMinimalImports` into two functions and reexport them In-Reply-To: <047.2af82a21a770553007c81fa29bcda40d@haskell.org> References: <047.2af82a21a770553007c81fa29bcda40d@haskell.org> Message-ID: <062.7544fda501681b1e07e709381b1a5947@haskell.org> #15439: Refactor `printMinimalImports` into two functions and reexport them -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.3 Resolution: | Keywords: | imports,refactoring,source plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm all for it. Send a patch? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 15:20:17 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 15:20:17 -0000 Subject: [GHC] #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation In-Reply-To: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> References: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> Message-ID: <061.52bddd883bb8d921747ebead48207e3d@haskell.org> #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation -------------------------------------+------------------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research Component: Compiler (Type | needed checker) | Version: 8.4.3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.6.1 => Research needed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 15:24:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 15:24:29 -0000 Subject: [GHC] #15436: Compile-time panic, Prelude.!!: negative index In-Reply-To: <047.11105fbd3a2250b4dd24d6c191fbb08d@haskell.org> References: <047.11105fbd3a2250b4dd24d6c191fbb08d@haskell.org> Message-ID: <062.3e39627633b81efc84a9af681114d2df@haskell.org> #15436: Compile-time panic, Prelude.!!: negative index -------------------------------------+------------------------------------- Reporter: pbrisbin | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5008 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => patch * differential: => Phab:D5008 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 15:45:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 15:45:14 -0000 Subject: [GHC] #15433: Internal error with PartialTypeSignatures and TH In-Reply-To: <047.aaa61fb434c95ee87d6470832f02e171@haskell.org> References: <047.aaa61fb434c95ee87d6470832f02e171@haskell.org> Message-ID: <062.80bf8b43b24d5343b23fde2b33f495fb@haskell.org> #15433: Internal error with PartialTypeSignatures and TH -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: | PartialTypeSignatures Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PartialTypeSignatures -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 15:56:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 15:56:46 -0000 Subject: [GHC] #13786: GHCi linker is dependent upon object file order In-Reply-To: <047.0a99d83942bb8bb77d0420502e27819e@haskell.org> References: <047.0a99d83942bb8bb77d0420502e27819e@haskell.org> Message-ID: <062.f3694648ec27ff818467b5998fff2152@haskell.org> #13786: GHCi linker is dependent upon object file order -------------------------------------+------------------------------------- Reporter: ppelleti | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by recursion-ninja): Can we prioritize fixing this so I can use GHCi again. It's been years since I could use it with our project at work and I really miss the ability to test functions in the REPL environment rather than recompiling with `Debug.Trace` statements inserted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 16:07:58 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 16:07:58 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.978343b93e7ce83a19d3a2bc9b554703@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): I did some benchmarking of `Data.Map` and also `Data.IntMap` in isolation. For both, I implemented combining a large number of positive integers into a set and then testing for the presence of `-1` in the set, using two strategies: 1. the "unions" approach: `unions . map singleton` 2. the "insert" approach: `foldr insert empty` For `IntMap` (which is what we're using here), the "unions" approach is slightly faster (~14.5s vs. ~15s for 100 million elements); for `Map`, the "unions" approach is a lot faster (~6.5s vs. ~8.2s for 10 million elements). Note that this is the worst possible case for `union`, and it still outperforms individual insertions for some reason. So if that is accurate, then the idea that speeding things up by using lots of inserts instead of lots of set unions doesn't hold up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 16:21:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 16:21:24 -0000 Subject: [GHC] #15436: Compile-time panic, Prelude.!!: negative index In-Reply-To: <047.11105fbd3a2250b4dd24d6c191fbb08d@haskell.org> References: <047.11105fbd3a2250b4dd24d6c191fbb08d@haskell.org> Message-ID: <062.9e92983c405cdc600641bbfd2cafce24@haskell.org> #15436: Compile-time panic, Prelude.!!: negative index -------------------------------------+------------------------------------- Reporter: pbrisbin | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5008 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"9897f6783a58265d5eaef5fb06f04320c7737e87/ghc" 9897f678/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9897f6783a58265d5eaef5fb06f04320c7737e87" Fix PrelRules.caseRules to account for out-of-range tags As Trac #15436 points out, it is possible to get case dataToTag# (x :: T) of DEFAULT -> blah1 -1# -> blah2 0 -> blah3 The (-1#) alterantive is unreachable, because dataToTag# returns tags in the range [0..n-1] where n is the number of data constructors in type T. This actually made GHC crash; now we simply discard the unreachable alterantive. See Note [Unreachable caseRules alternatives] in PrelRules }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 16:45:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 16:45:42 -0000 Subject: [GHC] #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards In-Reply-To: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> References: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> Message-ID: <065.13c06805898900d2cd74bf86b7c6f04f@haskell.org> #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4968 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Gah. The deeper I dig the less happy I am. The `addDictsDs` is ok, but I'm worried about `genCaseTmCs1` and `genCaseTmCs2` The basic idea here is that when we see (in source Haskell) {{{ case x of { (a, Just b) -> blah } }}} we want to desugar `blah` in the knowledge that {{{ x ~ (a, Just b) }}} Reason: suppose that somewhere inside `blah` we see {{{ case x of { (a, Nothing) -> blah2 } }}} Then we want to declare this branch as unreachable. But what if the original expression was {{{ case x of (a, Just _) -> blah }}} Now what equality do we generate? Maybe we make a fresh variable? And maybe that is waht we want. This conversion from a pattern to a `PmExpr` is all hidden inside the cryptic line {{{ [e] <- map vaToPmExpr . coercePatVec <$> translatePat fam_insts p }}} I have very little idea of what this does. Returning to our case expression, we'll end up using `genCaseTmCs2` in `matchWrapper`. And that seems to generate ''two'' equalities {{{ v ~ (a, Just b) v ~ x }}} That seems terribly indirect, although perhaps not actually wrong. I suppose that it might work in cases like {{{ case (p,q) of (a, Just b) -> blah }}} but they probably never happen -- and at very least it could do with explanation. Bottom line so far: no actual bugs, but pretty tough going. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 16:47:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 16:47:47 -0000 Subject: [GHC] #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards In-Reply-To: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> References: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> Message-ID: <065.0c78c9c71c3b94bc2cfd0d2801a34ed2@haskell.org> #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4968 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To be clear, the problems you're describing in comment:3 aren't unique to pattern guards, but rather anything that generates term equalities for the coverage checker (which includes `case` expressions)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 16:52:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 16:52:18 -0000 Subject: [GHC] #15436: Compile-time panic, Prelude.!!: negative index In-Reply-To: <047.11105fbd3a2250b4dd24d6c191fbb08d@haskell.org> References: <047.11105fbd3a2250b4dd24d6c191fbb08d@haskell.org> Message-ID: <062.b01fd1865dbfbaf4e47520143dafa40e@haskell.org> #15436: Compile-time panic, Prelude.!!: negative index -------------------------------------+------------------------------------- Reporter: pbrisbin | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | simplCore/should_run/T15436 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5008 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: patch => merge * testcase: => simplCore/should_run/T15436 Comment: OK, done! Thanks hsyl20. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 16:53:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 16:53:08 -0000 Subject: [GHC] #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards In-Reply-To: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> References: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> Message-ID: <065.09719c20452dc5d2663867edaf61916c@haskell.org> #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4968 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > To be clear, the problems you're describing in comment:3 aren't unique to pattern guards, but rather anything that generates term equalities for the coverage checker (which includes case expressions)? Correct, yes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 17:24:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 17:24:51 -0000 Subject: [GHC] #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards In-Reply-To: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> References: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> Message-ID: <065.68dd901b408b2232bfbf83c410f1aac5@haskell.org> #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4968 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): OK. Well, I simply went along with the status quo (adapting from the code for `case` expressions in `matchWrapper`) when writing Phab:D4968. At the very least, I'd like to get that patch in to 8.6, and then perhaps we can revisit the design of term equalities later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 17:56:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 17:56:29 -0000 Subject: [GHC] #13786: GHCi linker is dependent upon object file order In-Reply-To: <047.0a99d83942bb8bb77d0420502e27819e@haskell.org> References: <047.0a99d83942bb8bb77d0420502e27819e@haskell.org> Message-ID: <062.6a608b949545d864f61668256749376c@haskell.org> #13786: GHCi linker is dependent upon object file order -------------------------------------+------------------------------------- Reporter: ppelleti | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Runtime System | Version: 8.0.2 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: Jaffacake (removed) * cc: simonmar (added) * priority: normal => high * milestone: => 8.8.1 Comment: We can try. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 18:53:41 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 18:53:41 -0000 Subject: [GHC] #15051: -split-objs generates excessively many files on Windows In-Reply-To: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> References: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> Message-ID: <060.0ea22778f80973ecbf09caf5ee6419b0@haskell.org> #15051: -split-objs generates excessively many files on Windows -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Phyx- Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (CodeGen) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4915 Wiki Page: | Phab:D4916 -------------------------------------+------------------------------------- Comment (by Zemyla): I've noticed this problem too, but I'm not sure getting rid of split-objs is the solution. The problem, it seems to me, is that it's (a) splitting with a Perl script, and (b) calling gcc with each and every single individual file produced. Is it possible to get rid of the Perl script, at least on Windows, by specializing the split-objects procedure for Windows x86/x64 builds and then using gcc to build many assembly files at a time? Actually, now that I think about it, why is it even using gcc to convert the assembly files into object files in the first place? Doesn't it convert the code directly into an object file when split-objs isn't used? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 19:56:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 19:56:18 -0000 Subject: [GHC] #14460: Symlink resolving fails against SMB mounts In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.3d6132af64935f520d75c6ba326ab466@haskell.org> #14460: Symlink resolving fails against SMB mounts -------------------------------------+------------------------------------- Reporter: astert | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4216 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): It's not looking for `Z:\\sandbox\\Vyse\\8.4.3\\bin\\` but `Z:\\sandbox\\Vyse\\8.4.3\\lib\\`. If that exists then download and run http://www.rohitab.com/download/api- monitor-v2r13-x86-x64.zip and go to `monitor new process` set process to `Z:\\sandbox\\Vyse\\8.4.3\\bin\\ghc.exe` and arguments to `--interactive`. let it run, then go to start -> save as and save the trace and upload the trace somewhere and link back here or attach it here. Note that the trace will contain some information about your computer like environment variable and possibly computer name. If you prefer not to upload the trace, then look in it for the call to `GetFinalPathNameByHandleW` If it's yellow then look for the `GetLastError` call following it. and paste the error. If it's not yellow continue down the log for what is trying to access the folder `sandbox\\Vyse\\8.4.3\\lib\\`. it should be yellow, paste the output of `GetLastError` after it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 20:06:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 20:06:43 -0000 Subject: [GHC] #14770: Allow static pointer expressions to have static pointer free variables In-Reply-To: <048.bed690b6ed6632ceb9361aef80b57ffb@haskell.org> References: <048.bed690b6ed6632ceb9361aef80b57ffb@haskell.org> Message-ID: <063.688d0265dda042e21ddf3f3d49275575@haskell.org> #14770: Allow static pointer expressions to have static pointer free variables -------------------------------------+------------------------------------- Reporter: TheKing01 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gershomb): No concrete use-case at the moment (in that I'm not working on a system that does cloud distribution). I wanted to track this ticket as I've been thinking a lot about questions related to this ticket, including possible other uses for `static` and how it relates to Contextual Modal Type Theory (and also the question of staging). I think the ticket has the right of it in terms of the problem. Semantically, the "correct" thing to do is, treating `StaticPtr` as a modality, allow computation _within_ the modality such that we have `StaticPtr (a -> b) -> StaticPtr a -> StaticPtr b` directly. Instead, we have the workaround the ticket points to, which makes use of an opaque GADT. So that means, as the ticket says, this gives (on its own) a potential efficiency gain, but not expressivity gain. I think we'll need more people using static pointers "at scale" to see if the efficiency cost becomes a genuine pain point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 20:42:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 20:42:40 -0000 Subject: [GHC] #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' In-Reply-To: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> References: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> Message-ID: <062.445061abf7f9f8b53081dba12092e432@haskell.org> #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' ---------------------------------+---------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by George): I can't reproduce in ghc alpha 8.6.1. I used to see this but I think it is fixed by the latest GHC or by MacOS 13.6 Here are the version details {{{ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.6.0.20180714 bash-3.2$ gcc -v Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include- dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1 Apple LLVM version 9.1.0 (clang-902.0.39.2) Target: x86_64-apple-darwin17.7.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jul 25 22:48:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 25 Jul 2018 22:48:11 -0000 Subject: [GHC] #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards In-Reply-To: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> References: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> Message-ID: <065.dcd0f82f926b0408aeddcd1dd169de99@haskell.org> #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4968 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes fine. I've commented on Phab. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 00:40:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 00:40:46 -0000 Subject: [GHC] #15418: Performance drop 60 times on non-profiling binary In-Reply-To: <045.a055029aec148ca416c29df30694b018@haskell.org> References: <045.a055029aec148ca416c29df30694b018@haskell.org> Message-ID: <060.d8ac29e808c335f1be62e199f35a4dee@haskell.org> #15418: Performance drop 60 times on non-profiling binary -------------------------------------+------------------------------------- Reporter: hth313 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14414, #9599 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): Comment 7 in 14414 says: "Note that the entirety of the anomalous time is in the garbage collector." Is this true in your case? Can you add " +RTS -s" to the end of your run command line and show us the output in the different cases? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 01:41:30 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 01:41:30 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.0fdc86767c6736ec633ac24ac731eb46@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7206 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): As this is now 4 years old, does it make sense to open a new issue and close this one? My problem of 3 years ago is basically fixed. In any case I have uploaded a fixed version, reprof.hs of repro,hs which was modifed per the comments in 49 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 01:44:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 01:44:08 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.f3aaf95c429d14093b27431dc0db78fd@haskell.org> #8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7206 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * Attachment "reprof.hs" added. fixed version of repro, modified per comment 49 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 02:50:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 02:50:44 -0000 Subject: [GHC] #15418: Performance drop 60 times on non-profiling binary In-Reply-To: <045.a055029aec148ca416c29df30694b018@haskell.org> References: <045.a055029aec148ca416c29df30694b018@haskell.org> Message-ID: <060.1a14a4cc8155ec8954ca78f20690a3f8@haskell.org> #15418: Performance drop 60 times on non-profiling binary -------------------------------------+------------------------------------- Reporter: hth313 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14414, #9599 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hth313): Built without profiling: {{{ 2,608,765,195,440 bytes allocated in the heap 6,315,679,080 bytes copied during GC 80,444,376 bytes maximum residency (62 sample(s)) 484,392 bytes maximum slop 234 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 1993101 colls, 0 par 44.791s 46.358s 0.0000s 0.0044s Gen 1 62 colls, 0 par 2.675s 2.983s 0.0481s 0.2165s INIT time 0.000s ( 0.002s elapsed) MUT time 792.519s (798.495s elapsed) GC time 47.466s ( 49.341s elapsed) EXIT time 0.000s ( 0.004s elapsed) Total time 839.985s (847.842s elapsed) %GC time 5.7% (5.8% elapsed) Alloc rate 3,291,739,430 bytes per MUT second Productivity 94.3% of total user, 94.2% of total elapsed real 14m42.573s user 13m59.992s sys 0m6.137s }}} Built with profiling: {{{ 31,046,636,816 bytes allocated in the heap 9,289,234,088 bytes copied during GC 204,185,744 bytes maximum residency (55 sample(s)) 958,320 bytes maximum slop 554 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 29674 colls, 0 par 3.982s 4.041s 0.0001s 0.0055s Gen 1 55 colls, 0 par 3.537s 3.785s 0.0688s 0.2521s INIT time 0.000s ( 0.002s elapsed) MUT time 20.312s ( 20.502s elapsed) GC time 7.518s ( 7.827s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 0.000s ( 0.000s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 27.830s ( 28.330s elapsed) %GC time 27.0% (27.6% elapsed) Alloc rate 1,528,524,987 bytes per MUT second Productivity 73.0% of total user, 72.4% of total elapsed real 0m28.442s user 0m27.839s sys 0m0.461s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 04:54:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 04:54:48 -0000 Subject: [GHC] #15434: DerivingVia (and perhaps even GND) works badly with DeriveGeneric In-Reply-To: <043.ff232ba9b1a1c824943c65988fdfafcf@haskell.org> References: <043.ff232ba9b1a1c824943c65988fdfafcf@haskell.org> Message-ID: <058.e1290367794370d5e914cceaddd225ea@haskell.org> #15434: DerivingVia (and perhaps even GND) works badly with DeriveGeneric -------------------------------------+------------------------------------- Reporter: konn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by konn): Replying to [comment:3 RyanGlScott]: > True, 90% of the time, this is what you want, but for the other 10%, having explicit control through `DerivingStrategies` is quite handy. I agree. In general, it is desirable to have the flexibility on the choice of a deriving strategy. > There are folks out there who write `Generic` instances which differ from what `stock` deriving would give you for various reasons. One reason is that some people like to define data types abstractly and only allow creating/matching on values of that data type through pattern synonyms. I've just taken a simple survey searching `instance Generic` in codes on GitHub and count how many custom instances for `Generic` are defined, using [https://github.com/konn/crawl-github this code]. It reported that there are 2 out of 892 modules with custom `Generic` instance and have 12 custom instances as a total; it turns out that `Generic` instances in one of the modules are not related to GHC's Generics. One instance is something like mapping the Rep of `Map k v` to that of `[(k, v)]`. Since there are some modules that cannot be parsed by `haskell-src-exts` and not counted in my survey, there might be more custom instances. Anyway, there is at least one use-case and there might be other custom instances doing the similar things. > I think what you want is for GHC to be able to verify that a particular `Generic` instance's structure actually matches the data type it was derived for. This is a reasonable desire, since there are certain properties about data types that can easily be discerned from a `Rep` instance, but only if you have confidence that the `Rep` instance isn't "lying". dfeuer (cc'd) has toyed with some ideas for how this could be achieved in GHC—perhaps he could chime in here. I find this option is reasonable. If GHC can warn that one can avoid unintended derived instance, and if one really wants to write custom instance, then one can turn off that warning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 07:51:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 07:51:09 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.aa317908a139de452f0d919d76760db4@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:53 simonpj]: > Let me urge you to try it with an explicit accumulator, exactly as I wrote it. > > I recall that this made a very big difference for Bartosz. Can you remember whether that situation involved raw `VarSet`s, or `FV`s? From what I see in the code, `FV` could, under the right circumstances, avoid hitting the underlying `IntSet` entirely, while after this patch, we're using `VarSet` directly, so maybe that's why those set operations are being hit harder now? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 08:07:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 08:07:59 -0000 Subject: [GHC] #15371: Eventlog framework outputs environment variables which may cause a security issue In-Reply-To: <043.e0598f3eff95a3e71b8c6103a2d86a17@haskell.org> References: <043.e0598f3eff95a3e71b8c6103a2d86a17@haskell.org> Message-ID: <058.3a57387ca41058f43776b9ef187742dd@haskell.org> #15371: Eventlog framework outputs environment variables which may cause a security issue -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by maoe): Fixed this in https://github.com/ghc/ghc/pull/169. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 08:21:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 08:21:34 -0000 Subject: [GHC] #15440: Flush eventlog in hs_init_ghc Message-ID: <043.a9a8394a5250a3fe2c866ddd9f27e645@haskell.org> #15440: Flush eventlog in hs_init_ghc -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.4.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently GHC RTS traces some basic information about the process in `hs_init_ghc` but the information is often flushed to the eventlog at the very end of the process lifetime. Or even worse, it's never written to it if the process terminates abnormally. This is very inconvenient because the information contains some useful stuff like EVENT_WALL_CLOCK_TIME, which is quite important if user wants to sync timestamps in the eventlog with clock. The simplest way to fix the issue is to flush the eventlog buffer in `hs_init_ghc`. This is implemented at https://github.com/maoe/ghc/commit/30e20e4e66adccc28c59c8876331918d30eacef2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 08:23:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 08:23:44 -0000 Subject: [GHC] #15440: Flush eventlog in hs_init_ghc In-Reply-To: <043.a9a8394a5250a3fe2c866ddd9f27e645@haskell.org> References: <043.a9a8394a5250a3fe2c866ddd9f27e645@haskell.org> Message-ID: <058.acfb1632451ab00e124cbddd41125d2c@haskell.org> #15440: Flush eventlog in hs_init_ghc -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by maoe: Old description: > Currently GHC RTS traces some basic information about the process in > `hs_init_ghc` but the information is often flushed to the eventlog at the > very end of the process lifetime. Or even worse, it's never written to it > if the process terminates abnormally. > > This is very inconvenient because the information contains some useful > stuff like EVENT_WALL_CLOCK_TIME, which is quite important if user wants > to sync timestamps in the eventlog with clock. > > The simplest way to fix the issue is to flush the eventlog buffer in > `hs_init_ghc`. > > This is implemented at > https://github.com/maoe/ghc/commit/30e20e4e66adccc28c59c8876331918d30eacef2. New description: Currently GHC RTS traces some basic information about the process in `hs_init_ghc` but the information is often flushed to the eventlog at the very end of the process lifetime. Or even worse, it's never written to it if the process terminates abnormally. This is very inconvenient because the information contains some useful stuff like `EVENT_WALL_CLOCK_TIME`, which is quite important if user wants to sync timestamps in the eventlog with clock. The simplest way to fix the issue is to flush the eventlog buffer in `hs_init_ghc`. This is implemented at https://github.com/maoe/ghc/commit/30e20e4e66adccc28c59c8876331918d30eacef2. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 08:31:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 08:31:43 -0000 Subject: [GHC] #15440: Flush eventlog in hs_init_ghc In-Reply-To: <043.a9a8394a5250a3fe2c866ddd9f27e645@haskell.org> References: <043.a9a8394a5250a3fe2c866ddd9f27e645@haskell.org> Message-ID: <058.1dff0246d6ceaed7d3cfb361ab782b0c@haskell.org> #15440: Flush eventlog in hs_init_ghc -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch Comment: https://github.com/ghc/ghc/pull/170 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 10:21:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 10:21:43 -0000 Subject: [GHC] #14770: Allow static pointer expressions to have static pointer free variables In-Reply-To: <048.bed690b6ed6632ceb9361aef80b57ffb@haskell.org> References: <048.bed690b6ed6632ceb9361aef80b57ffb@haskell.org> Message-ID: <063.ccc9e11841408499e4952f5b3f797364@haskell.org> #14770: Allow static pointer expressions to have static pointer free variables -------------------------------------+------------------------------------- Reporter: TheKing01 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I think the ticket has the right of it in terms of the problem. Semantically, the "correct" thing to do is,... I agree with the direction of travel. But I'm keen to see concrete use- cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 10:25:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 10:25:46 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.d98da3c61aacf263f4387d67f5fd5ca5@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > the "unions" approach: unions . map singleton That is essentially `foldr (union . singleton) empty`, which is really very close to `foldr insert empty`. What if you do a balanced tree of binary `union` operations? I suppose something like {{{ bigSet :: Int -> Int -> IntSet bigSet m n | m==n = singleton n | otherwise = bigSet m mid `union` bigSet (mid+1) n where mid = (n+m)/2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 10:48:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 10:48:34 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.4f63c64001ef656703f662c82574119f@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This is all very puzzling. But when we get to the bottom of it we may speed up a key piece of infrastructure! So I think it's worth persevering. Some other ideas 1. Is `poly_merge` still high on the list in `ticky` in the accumulator version? If so, why? 2. Can you post the accumulator version for types anyway? 3. Try switching back to FV. That is, take the currently-deleted code for `tyCoFVsOfType`, and re-instate it, but modify it not to take the kinds at the variable occurrences. Now use that instead of the new `fvs_of_type`. It "obviously" should be a lot slower -- is it? 4. In `unitFV` I see {{{ unitFV :: Id -> FV unitFV var fv_cand in_scope acc@(have, haveSet) | var `elemVarSet` in_scope = acc | var `elemVarSet` haveSet = acc | fv_cand var = (var:have, extendVarSet haveSet var) | otherwise = acc }}} Notice that ''before inserting we test for membership''. Could that possibly be a win? If so, we can use it in the `VarSet` version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 10:50:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 10:50:33 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.8e4611c8baff28ed48674a138aea4099@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Can you remember whether that situation involved raw VarSets, or FVs? The old code for `tyCoFVsOfType` looked like {{{ fvs_of_type (AppTy fun arg) a b c = (fvs_of_type fun `unionFV` fvs_of_type arg) a b c }}} I believe that if you eta reduce this to {{{ fvs_of_type (AppTy fun arg) = (fvs_of_type fun `unionFV` fvs_of_type arg) }}} it runs a lot slower. That should not happen, but I recall that it did. I don't understand what you mean about "avoiding hitting the underlying `IntSet` entirely". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 11:04:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 11:04:49 -0000 Subject: [GHC] #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation In-Reply-To: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> References: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> Message-ID: <061.a1967edf9d15ba9fd6983a24b6a00c0b@haskell.org> #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation -------------------------------------+------------------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research Component: Compiler (Type | needed checker) | Version: 8.4.3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): My strong instinct here is to go back to the paper. In rule [UConVar] and friends we split up 'x' into a union of constructors {K x1, K2 x2 x3, K3}. Each of those split constructors comes with an extended `Delta`, which describes the constraints in scope. If these constraints prove contradicatory we can drop the entire branch. So for a strict constructor, say {{{ data T a where MkT :: a -> !a -> T a }}} we want to add a constraint to `Delta` that says that the type of that second argument is non-void; that is, it contains at least one element that terminates. So maybe we need a constraint `NonVoid( tau )`. In the OP, `NonVoid( Bar A )` would be a contradiction. In the implementation we have a simple "term oracle" that works alongside the type oracle that is implemented by the constraint solver. Maybe we could add the new constraint to the term oracle? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 11:07:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 11:07:49 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.04ba4dc567f8eeb83e81648c5b0228e2@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:60 simonpj]: > > Can you remember whether that situation involved raw VarSets, or FVs? > > The old code for `tyCoFVsOfType` looked like > {{{ > fvs_of_type (AppTy fun arg) a b c = (fvs_of_type fun `unionFV` fvs_of_type arg) a b c > }}} > I believe that if you eta reduce this to > {{{ > fvs_of_type (AppTy fun arg) = (fvs_of_type fun `unionFV` fvs_of_type arg) > }}} > it runs a lot slower. That should not happen, but I recall that it did. I don't understand what you mean about "avoiding hitting the underlying `IntSet` entirely". Well, if you look at the definition of `FV`: {{{#!haskell type FV = InterestingVarFun -- Used for filtering sets as we build them -> VarSet -- Locally bound variables -> ([Var], VarSet) -- List to preserve ordering and set to check for membership, -- so that the list doesn't have duplicates -- For explanation of why using `VarSet` is not deterministic see -- Note [Deterministic UniqFM] in UniqDFM. -> ([Var], VarSet) }}} ...then it's not immediately obvious that code that manipulates `FV`s will always touch the `VarSet`s in there at all. Specifically, variables that are not "interesting" bypass the `VarSet` (i.e., `IntSet`) machinery entirely, if I'm not mistaken. Not sure if that has anything to do with the problem at hand though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 11:25:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 11:25:01 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.6f3ba803fb29e2fb4d242f49d75ada60@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:59 simonpj]: > This is all very puzzling. But when we get to the bottom of it we may speed up a key piece of infrastructure! So I think it's worth persevering. > > 1. Is `poly_merge` still high on the list in `ticky` in the accumulator version? If so, why? As a matter of fact, no it's not. So it looks like the allocations we're winning from not using `poly_merge` as much just end up being eaten up elsewhere. Top 15 entries for the accumulator version: {{{ Entries Alloc Alloc'd Non-void Arguments STG Name -------------------------------------------------------------------------------- 2539473 107917008 0 3 i.M containers-0.5.11.0:Data.IntMap.Internal.$winsert{v r7O} (fun) 172005 90819296 0 5 EMMMS ghc:TcUnify.promoteTcType2{v r3m} (fun) 2330347 86853624 0 2 >L base:GHC.Base.map{v 01X} (fun) 699656 37268264 0 1 L go4{v sNmj} (ghc:TcMType) (fun) in r1Y 448802 35904160 0 7 E>>>>.M ghc:TcMType.$s$wmapType{v r1Y} (fun) 367181 23499584 0 2 LS ghc:TcRnMonad.traceTc1{v rlu} (fun) 887399 22625616 0 1 M go28{v sNmi} (ghc:TcMType) (fun) in r1Y 283135 21931488 0 4 >SSM ghc:TcHsSyn.$wzonkTyVarOcc{v r1F} (fun) 269137 18194264 0 1 L go13{v sSI0} (ghc:TcHsSyn) (fun) in rN 95951 16510560 0 2 >L base:Data.OldList.sortBy{v rD} (fun) 302653 16395904 0 5 +>LLL ghc:MonadUtils.zipWith3M{v rp} (fun) 194400 15552000 0 7 E>>>>.M ghc:TcHsSyn.$s$wmapType{v rN} (fun) 559499 15509096 0 1 M ghc:TcMType.zonkTcTyVar{v r1l} (fun) 138823 13706576 0 1 S sat_sMLW{v} (ghc:TcMType) (fun) in r6P 440463 11089080 0 1 S sat_sNmS{v} (ghc:TcMType) (fun) in sNmi }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 11:25:12 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 11:25:12 -0000 Subject: [GHC] #15350: gcdExtInteger violates assertion In-Reply-To: <047.463f72a51535cf21b879b51cdb0841bf@haskell.org> References: <047.463f72a51535cf21b879b51cdb0841bf@haskell.org> Message-ID: <062.95a1a1827abf219f00aa19a40eb6eb11@haskell.org> #15350: gcdExtInteger violates assertion -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: Bodigrim Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): What's the status here? I see that the change was merged, but I don't see a test. I've tried adding a test, but it's still failing with the same error on my machine. Maybe I'm doing something wrong? Is the plan to release a new version of `integer-gmp`? {{{ diff --git a/testsuite/tests/lib/integer/integerGmpInternals.hs b/testsuite/tests/lib/integer/integerGmpInternals.hs index c90df5c90d..e1faf900c7 100644 --- a/testsuite/tests/lib/integer/integerGmpInternals.hs +++ b/testsuite/tests/lib/integer/integerGmpInternals.hs @@ -86,6 +86,7 @@ main = do print $ gcdExtInteger x (-y) print $ gcdExtInteger (-x) y print $ gcdExtInteger (-x) (-y) + print $ gcdExtInteger 2 (2^65 + 1) -- see Trac #15350 print $ powInteger 12345 0 print $ powInteger 12345 1 print $ powInteger 12345 30 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 12:42:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 12:42:00 -0000 Subject: [GHC] #15219: Implement UnliftedNewtypes proposal In-Reply-To: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> References: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> Message-ID: <064.fb20660c0968f587b9cf06eeac1fb05c@haskell.org> #15219: Implement UnliftedNewtypes proposal -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | UnliftedNewtypes, GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1311 | Differential Rev(s): Phab:D477 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * differential: => Phab:D477 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 12:55:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 12:55:15 -0000 Subject: [GHC] #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation In-Reply-To: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> References: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> Message-ID: <061.596aec03f8af618b256fb47cb15cfa44@haskell.org> #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation -------------------------------------+------------------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research Component: Compiler (Type | needed checker) | Version: 8.4.3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I think this would work fine for simple, non-recursive examples like the original program, but I fail to see how this would work for recursive examples like the program in comment:7. If you have the constraint `NonVoid(Abyss)`, how do you conclude that that is contradictory? Presumably, you'd need some sort of way to determine if there are any terminating inhabitants of `Abyss`. Unlike the `InL` example, where the type of its field alone (`Foo B`) is enough to conclude that it is uninhabitable, nothing about the type of `MkAbyss`'s field (`Abyss`) suggests that it is uninhabitable, so you'd have to check if its field satisfies the constraint `NonVoid(Abyss)`. But that brings us back to the infinite loop in comment:7. In short, I just don't see how this is possible to do in a way that's complete. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 12:58:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 12:58:17 -0000 Subject: [GHC] #13607: Panic when shared object file is missing: Dynamic linker not initialised In-Reply-To: <050.42a412821545515fa30e9fa080a5d0f2@haskell.org> References: <050.42a412821545515fa30e9fa080a5d0f2@haskell.org> Message-ID: <065.4a980dfdb7cb22c0764287f687c2fc16@haskell.org> #13607: Panic when shared object file is missing: Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): With a `quick` build of `ghc-8.4.3` I get: {{{ : error: : can't load .so/.DLL for: /Users/angerman/.cabal/lib/x86_64-osx-ghc-8.4.3/libHSrandom-1.1 -9LLJAJa4iQFLJiLXBOBXBV-ghc8.4.3.dylib (dlopen(/Users/angerman/.cabal/lib/x86_64-osx-ghc-8.4.3/libHSrandom-1.1 -9LLJAJa4iQFLJiLXBOBXBV-ghc8.4.3.dylib, 5): Symbol not found: _base_GHCziList_splitAtzuzdszdwsplitAtzq_info Referenced from: /Users/angerman/.cabal/lib/x86_64-osx- ghc-8.4.3/libHSrandom-1.1-9LLJAJa4iQFLJiLXBOBXBV-ghc8.4.3.dylib Expected in: /Users/angerman/Projects/zw3rk/ghc/libraries/base/dist- install/build/libHSbase-4.11.1.0-ghc8.4.3.dylib in /Users/angerman/.cabal/lib/x86_64-osx-ghc-8.4.3/libHSrandom-1.1 -9LLJAJa4iQFLJiLXBOBXBV-ghc8.4.3.dylib) [2 of 3] Compiling Foo2 ( Foo2.hs, Foo2.o ) : error: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-apple-darwin): Dynamic linker not initialised CallStack (from HasCallStack): panic, called at compiler/ghci/Linker.hs:106:53 in ghc:Linker Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} with `-j2` A tiny bit of `Debut.Trace.trace` on the functions gives us: {{{ [1 of 3] Compiling Foo ( Foo.hs, Foo.o ) linkExpr initDynLinker modifyPLS_ False ;; <- getOrSetLibHSghcInitLinkerDone reallyInitDynLinker linkExpr initDynLinker modifyPLS_ linkPackages' link link_one.2 link link_one.2 link link_one.1 link_one.2 link link_one.1 linkPackage link_one.2 link link_one.1 linkPackage linkPackage link_one.2 link link_one.1 link_one.2 link link_one.1 link_one.2 link link_one.1 linkPackage linkPackage linkPackage linkPackage True ;; <- getOrSetLibHSghcInitLinkerDone modifyPLS linkDependencies getLinkDeps linkPackages' linkPackages' link }}} prior to the crash. The `link_one.N` are the various branches of the `link_one` function. For completeness, here's the `-prof-auto-all -prof-cafs` output: {{{ : error: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-apple-darwin): Dynamic linker not initialised CallStack (from -prof): Panic.panic (compiler/utils/Panic.hs:(184,1)-(188,68)) Util.sharedGlobalM (compiler/utils/Util.hs:(1015,1)-(1016,47)) Linker.v_PersistentLinkerState (compiler/ghci/Linker.hs:(101,62)-(104,20)) Linker.CAF:lvl261_rHOo () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 12:58:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 12:58:24 -0000 Subject: [GHC] #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards In-Reply-To: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> References: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> Message-ID: <065.6ac0a8a411dc238f89de57503fc51bef@haskell.org> #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4968 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): And I've replied on Phab. (Unfortunately, Phab notifications appear to be dysfunctional at the moment...) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 14:32:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 14:32:07 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.ff6d8289828276ef737ea9cab4864f36@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:59 simonpj]: > 4. In `unitFV` I see > {{{ > unitFV :: Id -> FV > unitFV var fv_cand in_scope acc@(have, haveSet) > | var `elemVarSet` in_scope = acc > | var `elemVarSet` haveSet = acc > | fv_cand var = (var:have, extendVarSet haveSet var) > | otherwise = acc > }}} > Notice that ''before inserting we test for membership''. Could that possibly be a win? If so, we can use it in the `VarSet` version. I believe that the "test before insert" thing is needed because we're accumulating a set (`haveSet`) and a list (`have`) in parallel, instead of just the set, so in order to keep the two in sync, we cannot simply insert unconditionally, as that would produce duplicates in the list. I don't think it can possibly produce a performance advantage beyond skipping the list cons, *unless* we are in a special situation where: - `in_scope` is much smaller than `haveSet` (such that testing membership of `in_scope` is significantly faster than testing `haveSet` membership); AND: - `in_scope` is likely to match new entries (because when it doesn't match, the extra test just eats up clock cycles without gaining anything) One interesting thing might be to invert the `fv_cand` condition and change the ordering, so that the `fv_cand` test is done before the set membership tests, something like: {{{#!haskell unitFV :: Id -> FV unitFV var fv_cand in_scope acc@(have, haveSet) | not (fv_cand var) = acc | var `elemVarSet` in_scope = acc | var `elemVarSet` haveSet = acc | otherwise = (var:have, extendVarSet haveSet var) }}} But that won't change the performance of `VarSet` the slightest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 14:34:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 14:34:14 -0000 Subject: [GHC] #15219: Implement UnliftedNewtypes proposal In-Reply-To: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> References: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> Message-ID: <064.4f48cd4dcd12092088bc3d3cf6619419@haskell.org> #15219: Implement UnliftedNewtypes proposal -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | UnliftedNewtypes, GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1311 | Differential Rev(s): Phab:D4777 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * differential: Phab:D477 => Phab:D4777 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 14:40:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 14:40:55 -0000 Subject: [GHC] #13116: Allow Overloaded things in patterns In-Reply-To: <056.7ea17bf463b0a40944c50397bb450716@haskell.org> References: <056.7ea17bf463b0a40944c50397bb450716@haskell.org> Message-ID: <071.91ede4b006233dcd87964aba6b296344@haskell.org> #13116: Allow Overloaded things in patterns -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | OverloadedLabels, | OverloadedStrings, OverloadedLists Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11671 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mentheta): * cc: mentheta (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 14:46:12 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 14:46:12 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.3f66c0cdf5b0b0adf2997958c637986a@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:58 simonpj]: > > the "unions" approach: unions . map singleton > > That is essentially `foldr (union . singleton) empty`, which is really very close to `foldr insert empty`. > > What if you do a balanced tree of binary `union` operations? I suppose something like > {{{ > bigSet :: Int -> Int -> IntSet > bigSet m n > | m==n = singleton n > | otherwise = bigSet m mid `union` bigSet (mid+1) n > where > mid = (n+m)/2 > }}} Did exactly that, benchmark code attached. Results: {{{ ./intmapbench insert 1.32s user 0.05s system 99% cpu 1.370 total ./intmapbench union 1.01s user 0.01s system 99% cpu 1.029 total ./intmapbench balanced 0.24s user 0.01s system 98% cpu 0.260 total }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 14:47:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 14:47:40 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.d7a0f96723293dbf83993d65f7659ba4@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * Attachment "intmapbench.hs" added. IntMap mini-benchmark -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 14:54:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 14:54:08 -0000 Subject: [GHC] #13116: Allow Overloaded things in patterns In-Reply-To: <056.7ea17bf463b0a40944c50397bb450716@haskell.org> References: <056.7ea17bf463b0a40944c50397bb450716@haskell.org> Message-ID: <071.91fb13bda72808a08d6ace7036d8ef75@haskell.org> #13116: Allow Overloaded things in patterns -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | OverloadedLabels, | OverloadedStrings, OverloadedLists Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11671 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Note that this already works for `OverloadedStrings`: {{{ $ ghci GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> :set -XOverloadedStrings Prelude> import Data.Text Prelude Data.Text> let foo :: Text -> Text; foo "foo" = "bar" Prelude Data.Text> foo "foo" "bar" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 15:29:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 15:29:26 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.7e58c41cb6147c22bf1d3366c650fac1@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Maybe try (3) in comment:59? That makes before-and-after more similar. It might help to put it all on a branch... I'm not sure of the precise code you are measuring. (It's cool that balanced unions are actually faster. FOUR TIMES faster!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 15:31:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 15:31:55 -0000 Subject: [GHC] #12674: GHC doesn't handle ./ prefixed paths correctly In-Reply-To: <047.897ae5e9c5c47ed13f84034ccb7c5729@haskell.org> References: <047.897ae5e9c5c47ed13f84034ccb7c5729@haskell.org> Message-ID: <062.ea65b087741a60e595ef30256a3fd784@haskell.org> #12674: GHC doesn't handle ./ prefixed paths correctly -------------------------------------+------------------------------------- Reporter: dobenour | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: Component: Driver | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: T12674 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D5009 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * testcase: => T12674 * status: new => patch * differential: => Phab: D5009 Comment: Fix in https://phabricator.haskell.org/D5009 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 15:49:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 15:49:20 -0000 Subject: [GHC] #15441: Data type with phantoms using TypeInType isn't coercible Message-ID: <051.c0b9407ab0ec784876ce6e4509034b58@haskell.org> #15441: Data type with phantoms using TypeInType isn't coercible -------------------------------------+------------------------------------- Reporter: glittershark | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 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'm *pretty* sure this is a problem with TypeInType in particular. I'd expect the following to compile: {{{#!hs {-# LANGUAGE GADTs, TypeInType, TypeApplications #-} module Bug where import Prelude import Data.Coerce import Data.Kind data Foo a = Foo data Bar (a :: Type) (b :: Foo a) where Bar :: Bar a 'Foo x = coerce @(Bar Int 'Foo) @(Bar Bool 'Foo) }}} But it doesn't -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 16:02:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 16:02:07 -0000 Subject: [GHC] #15441: Data type with phantoms using TypeInType isn't coercible In-Reply-To: <051.c0b9407ab0ec784876ce6e4509034b58@haskell.org> References: <051.c0b9407ab0ec784876ce6e4509034b58@haskell.org> Message-ID: <066.a81f5425bf6407a1f6e14f27b4968819@haskell.org> #15441: Data type with phantoms using TypeInType isn't coercible -------------------------------------+------------------------------------- Reporter: glittershark | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): You're implicitly suggesting that the first parameter to `Bar` can be assigned a phantom role. Currently, all dependent parameters are assigned a nominal role. Perhaps you're right that a phantom role there would be sound, but we have not worked out the theory fully for this case. Inferring nominal there is safe, so that's what we do today. Perhaps tomorrow, we'll do better, but we'll need a big proof before we can do it with confidence. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 16:03:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 16:03:42 -0000 Subject: [GHC] #15441: Data type with phantoms using TypeInType isn't coercible In-Reply-To: <051.c0b9407ab0ec784876ce6e4509034b58@haskell.org> References: <051.c0b9407ab0ec784876ce6e4509034b58@haskell.org> Message-ID: <066.8d1d9d310762097ec166ce5a32ee6ebe@haskell.org> #15441: Data type with phantoms using TypeInType isn't coercible -------------------------------------+------------------------------------- Reporter: glittershark | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by glittershark): As a follow-up with further information, the code where I'm actually using this has Foo as a GADT, where the constructor I'm coercing has its parameter phantom, like so: {{{#!hs {-# LANGUAGE GADTs, TypeInType, TypeApplications #-} module Coerce where import Prelude import Data.Coerce import Data.Kind data Foo (a :: Type) where A :: Foo a C :: Foo Int data Bar (a :: Type) (b :: Foo a) where Bar :: Bar a 'A x = coerce @(Bar Int 'A) @(Bar Bool 'A) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 16:05:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 16:05:17 -0000 Subject: [GHC] #15441: Data type with phantoms using TypeInType isn't coercible In-Reply-To: <051.c0b9407ab0ec784876ce6e4509034b58@haskell.org> References: <051.c0b9407ab0ec784876ce6e4509034b58@haskell.org> Message-ID: <066.a7717d275d25272580ad88fa9c6eb5b1@haskell.org> #15441: Data type with phantoms using TypeInType isn't coercible -------------------------------------+------------------------------------- Reporter: glittershark | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by glittershark): Yeah, after discussing this a little in #haskell this looks more like a feature request than a bug report -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 18:40:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 18:40:31 -0000 Subject: [GHC] #14460: Symlink resolving fails against SMB mounts In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.5b1f18cd3fea1ad1c715b997b1048278@haskell.org> #14460: Symlink resolving fails against SMB mounts -------------------------------------+------------------------------------- Reporter: astert | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4216 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Vyse007): So for some strange weirdness with `autoconf` I can't actually test my fix, but sleuthing with APIMonitor as suggested by Phyx- leads me to the following conclusion: In the `getBaseDir` function in `BaseDir.hs`, the value of `GetModuleFileName` is indeed `Z:\sandbox\Vyse\8.4.3\bin\ghc.exe` - APIMonitor confirms this. This function then calls `getFinalPath` defined under it, which attempts to find the 'final' path of the executable. This function internally calls `GetFinalPathNameByHandleW`, and this function returns a slightly different value (after adding the backslashes): `\\\\?\\UNC\\vNetwork\\users\\sandbox\\Vyse\\8.4.3\\bin\\ghc.exe` - again, as reported by APIMonitor. Now calling `sanitize` and `takeDirectory` (twice) gets rid of the preceding `\\\\?\\`, but still leaves us with `UNC\\vNetworks\\users\\sandbox\\Vyse\\8.4.3`. This directory, according to `doesDirectoryExist`, does not exist. And that is correct in a way, as you cant `cd` to that location with that path, but you can use (without the extra slashes) `cd \\vNetwork\users\sandbox...` Anyway, API monitor reports that after the `GetFinalPathNameByHandleW` call, which returns the value with the `UNC` prefix, we end up calling `CreateFileW` again, but this time with the bizarre value of `\\?\Z:\sandbox\Vyse\8.4.3\bin\UNC\vNetwork\users\sandbox\Vyse\8.4.3\lib` - not sure where this came from, but at this point `NtCreateFile` errors out. I'll look into it a bit more when I get some time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 19:00:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 19:00:42 -0000 Subject: [GHC] #14460: Symlink resolving fails against SMB mounts In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.1585b3f488895ed5e5a69cde1cfde4eb@haskell.org> #14460: Symlink resolving fails against SMB mounts -------------------------------------+------------------------------------- Reporter: astert | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4216 Wiki Page: | Phab:D4229 Phab:D4227 -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: Phyx- => (none) * status: closed => new * differential: Phab:D4216 => Phab:D4216 Phab:D4229 Phab:D4227 * resolution: fixed => Comment: *sigh* it's because we only merged half of the patches required to fix this. Phab:D4229 was never merged. `UNC` paths were never meant to be resolved as they won't expand to anything useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 19:03:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 19:03:31 -0000 Subject: [GHC] #14460: Symlink resolving fails against SMB mounts In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.541046dfe70c0e9cf00b4ba3fc5c5e77@haskell.org> #14460: Symlink resolving fails against SMB mounts -------------------------------------+------------------------------------- Reporter: astert | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4216 Wiki Page: | Phab:D4229 Phab:D4227 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 19:07:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 19:07:37 -0000 Subject: [GHC] #14460: Symlink resolving fails against SMB mounts In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.5be426160dace95f6a7470192d54607c@haskell.org> #14460: Symlink resolving fails against SMB mounts -------------------------------------+------------------------------------- Reporter: astert | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4216 Wiki Page: | Phab:D4229 Phab:D4227 -------------------------------------+------------------------------------- Comment (by Vyse007): Great - many thanks Phyx-. Please let me know if I can be of any further assistance in debugging. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 19:39:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 19:39:03 -0000 Subject: [GHC] #15442: GhcStage3HcOpts passed to ghc-stage1 Message-ID: <046.95a723aa50c2e570df3f28b2b19c6980@haskell.org> #15442: GhcStage3HcOpts passed to ghc-stage1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Build System | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When building a stage3 compiler the build system passes `GhcStage3HcOpts` to `inplace/bin/ghc-stage1` while building dependency lists: {{{ $ make stage=3 GhcStage3HcOpts='+RTS -xn -RTS "inplace/bin/ghc-stage1" -M -fPIC -dynamic -H32m -O -Wall -hide-all- packages -i -ighc/. -ighc/stage3/build -Ighc/stage3/build -ighc/stage3/build/ghc/autogen -Ighc/stage3/build/ghc/autogen -optP- DGHCI -optP-include -optPghc/stage3/build/ghc/autogen/cabal_macros.h -package-id array-0.5.2.0 -package-id base-4.12.0.0 -package-id bytestring-0.10.8.2 -package-id containers-0.6.0.1 -package-id deepseq-1.4.4.0 -package-id directory-1.3.2.3 -package-id filepath-1.4.2 -package-id ghc-8.7 -package-id ghc-boot-8.7 -package-id ghci-8.7 -package-id haskeline-0.7.4.2 -package-id process-1.6.3.0 -package-id time-1.8.0.2 -package-id transformers-0.5.5.0 -package-id unix-2.8.0.0 -Wall -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -Wnoncanonical-monoid-instances -fno-warn-name-shadowing -XHaskell2010 -O2 +RTS -xn -RTS -no-hs-main -threaded -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir ghc/stage3/build -hidir ghc/stage3/build -stubdir ghc/stage3/build -dep-makefile ghc/stage3/build/.depend.haskell.tmp -dep-suffix "dyn_" -include-pkg-deps ghc/./Main.hs ghc/./GHCi/Leak.hs ghc/./GHCi/UI.hs ghc/./GHCi/UI/Info.hs ghc/./GHCi/UI/Monad.hs ghc/./GHCi/UI/Tags.hs ghc-stage1: unknown RTS option: -xn ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 21:55:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 21:55:21 -0000 Subject: [GHC] #15347: QuantifiedConstraints: Implication constraints with type families don't work In-Reply-To: <049.446b77184844bcadda01810c8c61d990@haskell.org> References: <049.446b77184844bcadda01810c8c61d990@haskell.org> Message-ID: <064.1fefb3be22c19efe3983abfb11bb77b7@haskell.org> #15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Third, working around this by manually floating out type families can be hugely painful, ''as it requires sacrificing one of the major benefits of type families, namely the ability to avoid passing around extra class parameters which are already determined by other parameters'' Would it be possible to distil the example into a smaller form that still illustrates your key point, in italics. My example in comment:10 did not substantiate this point. Can you give a small example that does? The `Category` example is so big that I lost the wood for the trees. That is, so far I do not understand why floating out type families (a straightforward source-to-source transformation that does not change the number of class parameters) would sacrifice a major benefit. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 22:19:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 22:19:56 -0000 Subject: [GHC] #15347: QuantifiedConstraints: Implication constraints with type families don't work In-Reply-To: <049.446b77184844bcadda01810c8c61d990@haskell.org> References: <049.446b77184844bcadda01810c8c61d990@haskell.org> Message-ID: <064.c923f41adca64afd2c4428b04fca17f7@haskell.org> #15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aaronvargo): Replying to [comment:14 simonpj]: Yes, sorry! > That is, so far I do not understand why floating out type families (a straightforward source-to-source transformation that does not change the number of class parameters) would sacrifice a major benefit. It requires changing the number of class parameters when the quantified constraint appears as a superclass. Suppose we would like to write: {{{#!hs class (forall a. Eq a => Eq (F t a)) => C t where type F t :: * -> * }}} where the type family `F t` in the quantified constraint is independent of the quantified `a`. In order to float this type family out, we need to add a new parameter to the class, `ft`, and make it equal to `F t`: {{{#!hs class (ft ~ F t, forall a. Eq a => Eq (ft a)) => C ft t where type F t :: * -> * }}} Furthermore, this parameter can never be instantiated with a type family without once again breaking the quantified constraint. E.g. if we write {{{#!hs class C (F t) t => D t }}} then the inherited quantified constraint will contain a type family, and will no longer work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 22:33:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 22:33:23 -0000 Subject: [GHC] #15361: Error message displays redundant equality constraint In-Reply-To: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> References: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> Message-ID: <065.0ec425a8facad8afec55eae82693a1dc@haskell.org> #15361: Error message displays redundant equality constraint -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14394 | Differential Rev(s): Phab:D5002 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I was puzzled about why redundant givens are sometimes reported and sometimes not. Here's the deal * For each implication GHC figures out, during constraint solving, whether the implication binds any equalities. This is used to guide equality float-out, and is recorded in the implication in the `ic_no_eqs` field. * The "whether binds any equalities" test is performed on the ''canonicalised, inert givens'', in `TcSMonad.getNoGivenEqs`. See `Note [When does an implication have given equalities?]`. * If an implication binds `* ~ *` only (call it situation (A)), we'll discard that Given, and mark the implication as `ic_no_eqs = True`. * But if an implication binds `* ~ *` ''and'' `a ~ b`, situation (B), the `ic_no_eqs` field will be set `False`. * When reporting an equality error, we report givens only from implications with `ic_no_eqs` = `False`. That makes sense. But it'll discard situation (A), and keep situation (B). * For the implications we keep, we report all original, user-written givens. Hence the reported `* ~ *`. So that explain the behavior you see. For example for `hoo` in comment:2, the `Int :~: Int` binds no equalities because when `Int ~ Int` is solved we get nothing. So it is not reported. I suppose, therefore, that the solution you suggest is no unreasonable, ''provided'' you write Note to explain. In particular * `mkMinimalBySCs` happens to eliminate reflexive equalities, as well as superclasses. (Why? See Note [Remove redundant provided dicts]` in `TcPatSyn`. * Explain how a given `* ~ *` can arise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 22:42:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 22:42:52 -0000 Subject: [GHC] #15347: QuantifiedConstraints: Implication constraints with type families don't work In-Reply-To: <049.446b77184844bcadda01810c8c61d990@haskell.org> References: <049.446b77184844bcadda01810c8c61d990@haskell.org> Message-ID: <064.429b5f5aa89580769440e5270bc06aca@haskell.org> #15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > In order to float this type family out, we need to add a new parameter to the class, Really? What wrong with this? {{{ class (ft ~ F t, forall a. Eq a => Eq (ft a)) => C t where }}} No extra parameter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 22:49:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 22:49:07 -0000 Subject: [GHC] #15347: QuantifiedConstraints: Implication constraints with type families don't work In-Reply-To: <049.446b77184844bcadda01810c8c61d990@haskell.org> References: <049.446b77184844bcadda01810c8c61d990@haskell.org> Message-ID: <064.cbcd2bc5a7df69848c2e0e9357c94053@haskell.org> #15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aaronvargo): Replying to [comment:16 simonpj]: > Really? What wrong with this? {{{ Not in scope: type variable ‘ft’ }}} The superclass isn't allowed to mention variables which don't appear in the head, even if they're already determined by other parameters. The solution to this limitation has been "use type families", which leads us to this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jul 26 23:11:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 26 Jul 2018 23:11:56 -0000 Subject: [GHC] #15347: QuantifiedConstraints: Implication constraints with type families don't work In-Reply-To: <049.446b77184844bcadda01810c8c61d990@haskell.org> References: <049.446b77184844bcadda01810c8c61d990@haskell.org> Message-ID: <064.66f54ad58d974e70223dcc76aeedb473@haskell.org> #15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aaronvargo): I don't see why that is though. Why can't `ft` be made an implicit parameter to the class? If it were possible to explicitly bind the implicit parameters of a class, perhaps we could write something like: {{{#!hs class forall ft. (ft ~ F t, forall a. Eq a => Eq (ft a)) => C t }}} Hmm, it is possible to make `ft` implicit using a proxy though: {{{#!hs class (ft ~ F t, forall a. Eq a => Eq (ft a)) => C (p :: Proxy ft) t where type F t :: * -> * -- this works foo :: forall t a. (C 'Proxy t, Eq a) => Dict (Eq (F t a)) foo = Dict }}} This still requires adding a parameter, but would only require adding one to each class rather than potentially several, as we can use a single proxy for all of the extra parameters. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 00:29:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 00:29:19 -0000 Subject: [GHC] #15443: ghc panic when running GI.init on intero REPL Message-ID: <050.29c9f5cf48c2b9e3ef9ab7db906ae6c7@haskell.org> #15443: ghc panic when running GI.init on intero REPL --------------------------------------+------------------------------- Reporter: esclerofilo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 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: --------------------------------------+------------------------------- I cloned the [https://github.com/haskell-gi/gi-gtk-examples] repo to learn to use gi-gtk, deleted all version numbers in the .cabal file to make it build with the latest stack resolver (lts-12.2) and then opened ButtonBox.hs in emacs (spacemacs) with intero, opened the intero repl (without actually loading the buffer into the repl*) and what happened follows: {{{ Starting: stack ghci --with-ghc ghci "--docker-run-args=--interactive=true --tty=false" --no-build --no-load gi-gtk-examples GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/vicente/Escritorio/gi-gtk-examples /.stack-work/intero/intero-scriptBbJ8Bq λ import qualified GI.Gtk as GI (main, init) λ GI.init Nothing ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): nameModule system $dShow_a8qH Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} the contents of {{{/home/vicente/Escritorio/gi-gtk-examples/.stack- work/intero/intero-scriptBbJ8Bq}}} are: {{{ :set prompt "" :set -fbyte-code :set -fdefer-type-errors :set -fdiagnostics-color=never :set prompt "\4 " }}} Note: It happens on a terminal ghci invocation too, given the same parameters and configuration. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 02:06:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 02:06:25 -0000 Subject: [GHC] #13607: Panic when shared object file is missing: Dynamic linker not initialised In-Reply-To: <050.42a412821545515fa30e9fa080a5d0f2@haskell.org> References: <050.42a412821545515fa30e9fa080a5d0f2@haskell.org> Message-ID: <065.e149dc843d0486a8deaf75e9cefa2653@haskell.org> #13607: Panic when shared object file is missing: Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): After making sure that command line errors get call stacks as well (why don't have have this by default? Legacy?) {{{ [1 of 3] Compiling Foo ( Foo.hs, Foo.o ) : error: : can't load .so/.DLL for: libHSrandom-1.1-9LLJAJa4iQFLJiLXBOBXBV.dylib (dlopen(libHSrandom-1.1-9LLJAJa4iQFLJiLXBOBXBV.dylib, 5): image not found) CallStack (from -prof): Panic.cmdLineErrorIO (compiler/utils/Panic.hs:(204,1)-(208,73)) Linker.load_dyn (compiler/ghci/Linker.hs:(1323,1)-(1327,89)) Linker.linkPackage (compiler/ghci/Linker.hs:(1240,1)-(1315,66)) Linker.linkPackages'.link_one (compiler/ghci/Linker.hs:(1224,6)-(1236,106)) Linker.linkPackages'.link (compiler/ghci/Linker.hs:(1221,6)-(1222,37)) Linker.linkPackages' (compiler/ghci/Linker.hs:(1214,1)-(1236,106)) Linker.reallyInitDynLinker (compiler/ghci/Linker.hs:(298,1)-(310,30)) Linker.initDynLinker.\ (compiler/ghci/Linker.hs:(291,25)-(295,47)) Linker.modifyPLS_ (compiler/ghci/Linker.hs:113:1-71) Linker.initDynLinker (compiler/ghci/Linker.hs:(290,1)-(295,47)) Linker.linkExpr (compiler/ghci/Linker.hs:(527,1)-(561,20)) HscMain.hscCompileCoreExpr' (compiler/main/HscMain.hs:(1774,1)-(1796,24)) HscMain.hscCompileCoreExpr (compiler/main/HscMain.hs:(1770,1)-(1771,84)) IOEnv.liftIO (compiler/utils/IOEnv.hs:183:5-33) IOEnv.tryIOEnvFailure (compiler/utils/IOEnv.hs:149:1-21) IOEnv.tryM.\ (compiler/utils/IOEnv.hs:146:38-64) IOEnv.tryM (compiler/utils/IOEnv.hs:146:1-65) TcSplice.runMeta' (compiler/typecheck/TcSplice.hs:(719,1)-(781,22)) TcSplice.defaultRunMeta (compiler/typecheck/TcSplice.hs:(678,1)-(687,74)) Hooks.lookupHook (compiler/main/Hooks.hs:104:1-50) Hooks.getHooked (compiler/main/Hooks.hs:101:1-59) HscTypes.metaRequestE (compiler/main/HscTypes.hs:747:1-53) TcSplice.runMeta (compiler/typecheck/TcSplice.hs:(673,1)-(675,21)) TcSplice.runMetaE (compiler/typecheck/TcSplice.hs:698:1-31) RnSplice.runRnSplice (compiler/rename/RnSplice.hs:(293,1)-(332,43)) RnSplice.rnSpliceExpr.run_expr_splice (compiler/rename/RnSplice.hs:(408,5)-(431,12)) RnSplice.rnSpliceGen (compiler/rename/RnSplice.hs:(247,1)-(279,31)) RnSplice.rnSpliceExpr (compiler/rename/RnSplice.hs:(400,1)-(431,12)) RnExpr.rnExpr (compiler/rename/RnExpr.hs:(116,1)-(420,67)) TcRnMonad.wrapLocFstM (compiler/typecheck/TcRnMonad.hs:(843,1)-(846,23)) RnBinds.rnGRHS (compiler/rename/RnBinds.hs:1201:1-54) RnBinds.rnGRHSs.\ (compiler/rename/RnBinds.hs:(1193,49)-(1195,47)) RnBinds.rnGRHSs (compiler/rename/RnBinds.hs:(1192,1)-(1195,47)) RnBinds.rnMatch'.\ (compiler/rename/RnBinds.hs:(1162,46)-(1169,58)) RnBinds.rnMatch' (compiler/rename/RnBinds.hs:(1160,1)-(1169,59)) RnBinds.rnMatch (compiler/rename/RnBinds.hs:1154:1-56) RnUtils.mapFvRn (compiler/rename/RnUtils.hs:(187,1)-(189,63)) RnBinds.rnMatchGroup (compiler/rename/RnBinds.hs:(1144,1)-(1148,54)) RnBinds.rnBind (compiler/rename/RnBinds.hs:(449,1)-(512,38)) RnBinds.rnLBind (compiler/rename/RnBinds.hs:(440,1)-(443,43)) Bag.mapBagM (compiler/utils/Bag.hs:(244,1)-(251,50)) RnBinds.rnValBindsRHS (compiler/rename/RnBinds.hs:(294,1)-(316,52)) RnSource.rnSrcDecls.\ (compiler/rename/RnSource.hs:(133,64)-(235,22)) RnSource.extendPatSynEnv (compiler/rename/RnSource.hs:(1950,1)-(1984,20)) RnSource.rnSrcDecls (compiler/rename/RnSource.hs:(93,1)-(235,24)) TcRnDriver.rnTopSrcDecls (compiler/typecheck/TcRnDriver.hs:(1299,1)-(1315,4)) IOEnv.thenM.\ (compiler/utils/IOEnv.hs:(78,37)-(79,60)) IOEnv.thenM (compiler/utils/IOEnv.hs:(78,1)-(79,61)) IOEnv.runIOEnv (compiler/utils/IOEnv.hs:122:1-30) TcRnMonad.initTcRnIf (compiler/typecheck/TcRnMonad.hs:(405,1)-(415,9)) TcRnMonad.initTcWithGbl (compiler/typecheck/TcRnMonad.hs:(319,1)-(361,35)) TcRnMonad.initTc (compiler/typecheck/TcRnMonad.hs:(206,1)-(311,5)) TcRnDriver.tcRnModule (compiler/typecheck/TcRnDriver.hs:(157,1)-(184,45)) HscTypes.liftIO.\ (compiler/main/HscTypes.hs:251:31-55) HscTypes.liftIO (compiler/main/HscTypes.hs:251:5-55) HscMain.ioMsgMaybe (compiler/main/HscMain.hs:(250,1)-(255,122)) HscMain.Typecheck-Rename (compiler/main/HscMain.hs:(463,16)-(464,73)) HscTypes.>>=.\ (compiler/main/HscTypes.hs:(246,33)-(248,56)) HscTypes.>>= (compiler/main/HscTypes.hs:(246,5)-(248,56)) HscMain.hscIncrementalFrontend (compiler/main/HscMain.hs:(583,1)-(645,81)) HscMain.hscIncrementalCompile (compiler/main/HscMain.hs:(671,1)-(717,52)) DriverPipeline.compileOne' (compiler/main/DriverPipeline.hs:(135,1)-(287,55)) GhcMake.upsweep_mod.compile_it_discard_iface (compiler/main/GhcMake.hs:(1463,13)-(1465,61)) GhcMake.upsweep_mod (compiler/main/GhcMake.hs:(1403,1)-(1559,49)) GhcMake.parUpsweep_one (compiler/main/GhcMake.hs:(1066,1)-(1229,65)) ErrUtils.prettyPrintGhcErrors (compiler/main/ErrUtils.hs:(681,1)-(690,44)) GhcMake.parUpsweep.\.spawnWorkers.\.\ (compiler/main/GhcMake.hs:(921,43)-(976,75)) GhcMake.parUpsweep.\.spawnWorkers.\ (compiler/main/GhcMake.hs:(921,13)-(976,75)) GhcMake.parUpsweep.\.spawnWorkers (compiler/main/GhcMake.hs:(920,11)-(976,75)) GhcMonad.liftIO (compiler/main/GhcMonad.hs:112:3-30) GhcMake.parUpsweep.\ (compiler/main/GhcMake.hs:(877,62)-(1006,44)) GhcMake.parUpsweep (compiler/main/GhcMake.hs:(844,1)-(1036,36)) GhcMake.load'.upsweep_fn (compiler/main/GhcMake.hs:(393,9)-(394,41)) GhcMake.load' (compiler/main/GhcMake.hs:(246,1)-(494,38)) GhcMake.load (compiler/main/GhcMake.hs:(238,1)-(240,44)) GhcMonad.>>=.\ (compiler/main/GhcMonad.hs:109:26-57) GhcMonad.>>= (compiler/main/GhcMonad.hs:109:3-57) Panic.withSignalHandlers (compiler/utils/Panic.hs:(255,1)-(313,37)) GHC.runGhc (compiler/main/GHC.hs:(441,1)-(446,26)) Exception.gcatch (compiler/utils/Exception.hs:65:3-37) Exception.ghandle (compiler/utils/Exception.hs:75:1-21) GHC.defaultErrorHandler (compiler/main/GHC.hs:(381,1)-(413,7)) Main.main (ghc/Main.hs:(90,1)-(150,64)) [2 of 3] Compiling Foo2 ( Foo2.hs, Foo2.o ) : error: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-apple-darwin): Dynamic linker not initialised CallStack (from -prof): Panic.panic (compiler/utils/Panic.hs:(186,1)-(190,68)) Util.sharedGlobalM (compiler/utils/Util.hs:(1015,1)-(1016,47)) Linker.v_PersistentLinkerState (compiler/ghci/Linker.hs:(101,62)-(104,20)) Linker.CAF:lvl261_rHOT () Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} From this I think we can assume that initializing the linker just failed. We put the panic back into the `MVar` and when the other thread got to read it we failed hard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 02:20:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 02:20:36 -0000 Subject: [GHC] #13607: Panic when shared object file is missing: Dynamic linker not initialised In-Reply-To: <050.42a412821545515fa30e9fa080a5d0f2@haskell.org> References: <050.42a412821545515fa30e9fa080a5d0f2@haskell.org> Message-ID: <065.00eea508c38c6e83b0a33aa48c017c91@haskell.org> #13607: Panic when shared object file is missing: Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): {{{ [1 of 3] Compiling Foo ( Foo.hs, Foo.o ) : error: : can't load .so/.DLL for: libHSrandom-1.1-9LLJAJa4iQFLJiLXBOBXBV.dylib (dlopen(libHSrandom-1.1-9LLJAJa4iQFLJiLXBOBXBV.dylib, 5): image not found) CallStack (from -prof): Panic.cmdLineErrorIO (compiler/utils/Panic.hs:(204,1)-(208,73)) Linker.load_dyn (compiler/ghci/Linker.hs:(1325,1)-(1329,89)) Linker.linkPackage (compiler/ghci/Linker.hs:(1242,1)-(1317,66)) Linker.linkPackages'.link_one (compiler/ghci/Linker.hs:(1226,6)-(1238,106)) Linker.linkPackages'.link (compiler/ghci/Linker.hs:(1223,6)-(1224,37)) Linker.linkPackages' (compiler/ghci/Linker.hs:(1216,1)-(1238,106)) Linker.reallyInitDynLinker (compiler/ghci/Linker.hs:(300,1)-(312,30)) Linker.initDynLinker.\.\ (compiler/ghci/Linker.hs:(295,26)-(297,58)) Linker.modifyILD (compiler/ghci/Linker.hs:119:1-62) Linker.initDynLinker.\ (compiler/ghci/Linker.hs:(294,25)-(297,58)) Linker.modifyPLS_ (compiler/ghci/Linker.hs:113:1-71) Linker.initDynLinker (compiler/ghci/Linker.hs:(293,1)-(297,58)) Linker.linkExpr (compiler/ghci/Linker.hs:(529,1)-(563,20)) HscMain.hscCompileCoreExpr' (compiler/main/HscMain.hs:(1774,1)-(1796,24)) HscMain.hscCompileCoreExpr (compiler/main/HscMain.hs:(1770,1)-(1771,84)) IOEnv.liftIO (compiler/utils/IOEnv.hs:183:5-33) IOEnv.tryIOEnvFailure (compiler/utils/IOEnv.hs:149:1-21) IOEnv.tryM.\ (compiler/utils/IOEnv.hs:146:38-64) IOEnv.tryM (compiler/utils/IOEnv.hs:146:1-65) TcSplice.runMeta' (compiler/typecheck/TcSplice.hs:(719,1)-(781,22)) TcSplice.defaultRunMeta (compiler/typecheck/TcSplice.hs:(678,1)-(687,74)) Hooks.lookupHook (compiler/main/Hooks.hs:104:1-50) Hooks.getHooked (compiler/main/Hooks.hs:101:1-59) HscTypes.metaRequestE (compiler/main/HscTypes.hs:747:1-53) TcSplice.runMeta (compiler/typecheck/TcSplice.hs:(673,1)-(675,21)) TcSplice.runMetaE (compiler/typecheck/TcSplice.hs:698:1-31) RnSplice.runRnSplice (compiler/rename/RnSplice.hs:(293,1)-(332,43)) RnSplice.rnSpliceExpr.run_expr_splice (compiler/rename/RnSplice.hs:(408,5)-(431,12)) RnSplice.rnSpliceGen (compiler/rename/RnSplice.hs:(247,1)-(279,31)) RnSplice.rnSpliceExpr (compiler/rename/RnSplice.hs:(400,1)-(431,12)) RnExpr.rnExpr (compiler/rename/RnExpr.hs:(116,1)-(420,67)) TcRnMonad.wrapLocFstM (compiler/typecheck/TcRnMonad.hs:(843,1)-(846,23)) RnBinds.rnGRHS (compiler/rename/RnBinds.hs:1201:1-54) RnBinds.rnGRHSs.\ (compiler/rename/RnBinds.hs:(1193,49)-(1195,47)) RnBinds.rnGRHSs (compiler/rename/RnBinds.hs:(1192,1)-(1195,47)) RnBinds.rnMatch'.\ (compiler/rename/RnBinds.hs:(1162,46)-(1169,58)) RnBinds.rnMatch' (compiler/rename/RnBinds.hs:(1160,1)-(1169,59)) RnBinds.rnMatch (compiler/rename/RnBinds.hs:1154:1-56) RnUtils.mapFvRn (compiler/rename/RnUtils.hs:(187,1)-(189,63)) RnBinds.rnMatchGroup (compiler/rename/RnBinds.hs:(1144,1)-(1148,54)) RnBinds.rnBind (compiler/rename/RnBinds.hs:(449,1)-(512,38)) RnBinds.rnLBind (compiler/rename/RnBinds.hs:(440,1)-(443,43)) Bag.mapBagM (compiler/utils/Bag.hs:(244,1)-(251,50)) RnBinds.rnValBindsRHS (compiler/rename/RnBinds.hs:(294,1)-(316,52)) RnSource.rnSrcDecls.\ (compiler/rename/RnSource.hs:(133,64)-(235,22)) RnSource.extendPatSynEnv (compiler/rename/RnSource.hs:(1950,1)-(1984,20)) RnSource.rnSrcDecls (compiler/rename/RnSource.hs:(93,1)-(235,24)) TcRnDriver.rnTopSrcDecls (compiler/typecheck/TcRnDriver.hs:(1299,1)-(1315,4)) IOEnv.thenM.\ (compiler/utils/IOEnv.hs:(78,37)-(79,60)) IOEnv.thenM (compiler/utils/IOEnv.hs:(78,1)-(79,61)) IOEnv.runIOEnv (compiler/utils/IOEnv.hs:122:1-30) TcRnMonad.initTcRnIf (compiler/typecheck/TcRnMonad.hs:(405,1)-(415,9)) TcRnMonad.initTcWithGbl (compiler/typecheck/TcRnMonad.hs:(319,1)-(361,35)) TcRnMonad.initTc (compiler/typecheck/TcRnMonad.hs:(206,1)-(311,5)) TcRnDriver.tcRnModule (compiler/typecheck/TcRnDriver.hs:(157,1)-(184,45)) HscTypes.liftIO.\ (compiler/main/HscTypes.hs:251:31-55) HscTypes.liftIO (compiler/main/HscTypes.hs:251:5-55) HscMain.ioMsgMaybe (compiler/main/HscMain.hs:(250,1)-(255,122)) HscMain.Typecheck-Rename (compiler/main/HscMain.hs:(463,16)-(464,73)) HscTypes.>>=.\ (compiler/main/HscTypes.hs:(246,33)-(248,56)) HscTypes.>>= (compiler/main/HscTypes.hs:(246,5)-(248,56)) HscMain.hscIncrementalFrontend (compiler/main/HscMain.hs:(583,1)-(645,81)) HscMain.hscIncrementalCompile (compiler/main/HscMain.hs:(671,1)-(717,52)) DriverPipeline.compileOne' (compiler/main/DriverPipeline.hs:(135,1)-(287,55)) GhcMake.upsweep_mod.compile_it_discard_iface (compiler/main/GhcMake.hs:(1463,13)-(1465,61)) GhcMake.upsweep_mod (compiler/main/GhcMake.hs:(1403,1)-(1559,49)) GhcMake.parUpsweep_one (compiler/main/GhcMake.hs:(1066,1)-(1229,65)) ErrUtils.prettyPrintGhcErrors (compiler/main/ErrUtils.hs:(681,1)-(690,44)) GhcMake.parUpsweep.\.spawnWorkers.\.\ (compiler/main/GhcMake.hs:(921,43)-(976,75)) GhcMake.parUpsweep.\.spawnWorkers.\ (compiler/main/GhcMake.hs:(921,13)-(976,75)) GhcMake.parUpsweep.\.spawnWorkers (compiler/main/GhcMake.hs:(920,11)-(976,75)) GhcMonad.liftIO (compiler/main/GhcMonad.hs:112:3-30) GhcMake.parUpsweep.\ (compiler/main/GhcMake.hs:(877,62)-(1006,44)) GhcMake.parUpsweep (compiler/main/GhcMake.hs:(844,1)-(1036,36)) GhcMake.load'.upsweep_fn (compiler/main/GhcMake.hs:(393,9)-(394,41)) GhcMake.load' (compiler/main/GhcMake.hs:(246,1)-(494,38)) GhcMake.load (compiler/main/GhcMake.hs:(238,1)-(240,44)) GhcMonad.>>=.\ (compiler/main/GhcMonad.hs:109:26-57) GhcMonad.>>= (compiler/main/GhcMonad.hs:109:3-57) Panic.withSignalHandlers (compiler/utils/Panic.hs:(255,1)-(313,37)) GHC.runGhc (compiler/main/GHC.hs:(441,1)-(446,26)) Exception.gcatch (compiler/utils/Exception.hs:65:3-37) Exception.ghandle (compiler/utils/Exception.hs:75:1-21) GHC.defaultErrorHandler (compiler/main/GHC.hs:(381,1)-(413,7)) Main.main (ghc/Main.hs:(90,1)-(150,64)) [2 of 3] Compiling Foo2 ( Foo2.hs, Foo2.o ) : error: : can't load .so/.DLL for: libHSrandom-1.1-9LLJAJa4iQFLJiLXBOBXBV.dylib (dlopen(libHSrandom-1.1-9LLJAJa4iQFLJiLXBOBXBV.dylib, 5): image not found) CallStack (from -prof): Panic.cmdLineErrorIO (compiler/utils/Panic.hs:(204,1)-(208,73)) Linker.load_dyn (compiler/ghci/Linker.hs:(1325,1)-(1329,89)) Linker.linkPackage (compiler/ghci/Linker.hs:(1242,1)-(1317,66)) Linker.linkPackages'.link_one (compiler/ghci/Linker.hs:(1226,6)-(1238,106)) Linker.linkPackages'.link (compiler/ghci/Linker.hs:(1223,6)-(1224,37)) Linker.linkPackages' (compiler/ghci/Linker.hs:(1216,1)-(1238,106)) Linker.reallyInitDynLinker (compiler/ghci/Linker.hs:(300,1)-(312,30)) Linker.initDynLinker.\.\ (compiler/ghci/Linker.hs:(295,26)-(297,58)) Linker.modifyILD (compiler/ghci/Linker.hs:119:1-62) Linker.initDynLinker.\ (compiler/ghci/Linker.hs:(294,25)-(297,58)) Linker.modifyPLS_ (compiler/ghci/Linker.hs:113:1-71) Linker.initDynLinker (compiler/ghci/Linker.hs:(293,1)-(297,58)) Linker.linkExpr (compiler/ghci/Linker.hs:(529,1)-(563,20)) HscMain.hscCompileCoreExpr' (compiler/main/HscMain.hs:(1774,1)-(1796,24)) HscMain.hscCompileCoreExpr (compiler/main/HscMain.hs:(1770,1)-(1771,84)) IOEnv.liftIO (compiler/utils/IOEnv.hs:183:5-33) IOEnv.tryIOEnvFailure (compiler/utils/IOEnv.hs:149:1-21) IOEnv.tryM.\ (compiler/utils/IOEnv.hs:146:38-64) IOEnv.tryM (compiler/utils/IOEnv.hs:146:1-65) TcSplice.runMeta' (compiler/typecheck/TcSplice.hs:(719,1)-(781,22)) TcSplice.defaultRunMeta (compiler/typecheck/TcSplice.hs:(678,1)-(687,74)) Hooks.lookupHook (compiler/main/Hooks.hs:104:1-50) Hooks.getHooked (compiler/main/Hooks.hs:101:1-59) HscTypes.metaRequestE (compiler/main/HscTypes.hs:747:1-53) TcSplice.runMeta (compiler/typecheck/TcSplice.hs:(673,1)-(675,21)) TcSplice.runMetaE (compiler/typecheck/TcSplice.hs:698:1-31) RnSplice.runRnSplice (compiler/rename/RnSplice.hs:(293,1)-(332,43)) RnSplice.rnSpliceExpr.run_expr_splice (compiler/rename/RnSplice.hs:(408,5)-(431,12)) RnSplice.rnSpliceGen (compiler/rename/RnSplice.hs:(247,1)-(279,31)) RnSplice.rnSpliceExpr (compiler/rename/RnSplice.hs:(400,1)-(431,12)) RnExpr.rnExpr (compiler/rename/RnExpr.hs:(116,1)-(420,67)) TcRnMonad.wrapLocFstM (compiler/typecheck/TcRnMonad.hs:(843,1)-(846,23)) RnBinds.rnGRHS (compiler/rename/RnBinds.hs:1201:1-54) RnBinds.rnGRHSs.\ (compiler/rename/RnBinds.hs:(1193,49)-(1195,47)) RnBinds.rnGRHSs (compiler/rename/RnBinds.hs:(1192,1)-(1195,47)) RnBinds.rnMatch'.\ (compiler/rename/RnBinds.hs:(1162,46)-(1169,58)) RnBinds.rnMatch' (compiler/rename/RnBinds.hs:(1160,1)-(1169,59)) RnBinds.rnMatch (compiler/rename/RnBinds.hs:1154:1-56) RnUtils.mapFvRn (compiler/rename/RnUtils.hs:(187,1)-(189,63)) RnBinds.rnMatchGroup (compiler/rename/RnBinds.hs:(1144,1)-(1148,54)) RnBinds.rnBind (compiler/rename/RnBinds.hs:(449,1)-(512,38)) RnBinds.rnLBind (compiler/rename/RnBinds.hs:(440,1)-(443,43)) Bag.mapBagM (compiler/utils/Bag.hs:(244,1)-(251,50)) RnBinds.rnValBindsRHS (compiler/rename/RnBinds.hs:(294,1)-(316,52)) RnSource.rnSrcDecls.\ (compiler/rename/RnSource.hs:(133,64)-(235,22)) RnSource.extendPatSynEnv (compiler/rename/RnSource.hs:(1950,1)-(1984,20)) RnSource.rnSrcDecls (compiler/rename/RnSource.hs:(93,1)-(235,24)) TcRnDriver.rnTopSrcDecls (compiler/typecheck/TcRnDriver.hs:(1299,1)-(1315,4)) IOEnv.thenM.\ (compiler/utils/IOEnv.hs:(78,37)-(79,60)) IOEnv.thenM (compiler/utils/IOEnv.hs:(78,1)-(79,61)) IOEnv.runIOEnv (compiler/utils/IOEnv.hs:122:1-30) TcRnMonad.initTcRnIf (compiler/typecheck/TcRnMonad.hs:(405,1)-(415,9)) TcRnMonad.initTcWithGbl (compiler/typecheck/TcRnMonad.hs:(319,1)-(361,35)) TcRnMonad.initTc (compiler/typecheck/TcRnMonad.hs:(206,1)-(311,5)) TcRnDriver.tcRnModule (compiler/typecheck/TcRnDriver.hs:(157,1)-(184,45)) HscTypes.liftIO.\ (compiler/main/HscTypes.hs:251:31-55) HscTypes.liftIO (compiler/main/HscTypes.hs:251:5-55) HscMain.ioMsgMaybe (compiler/main/HscMain.hs:(250,1)-(255,122)) HscMain.Typecheck-Rename (compiler/main/HscMain.hs:(463,16)-(464,73)) HscTypes.>>=.\ (compiler/main/HscTypes.hs:(246,33)-(248,56)) HscTypes.>>= (compiler/main/HscTypes.hs:(246,5)-(248,56)) HscMain.hscIncrementalFrontend (compiler/main/HscMain.hs:(583,1)-(645,81)) HscMain.hscIncrementalCompile (compiler/main/HscMain.hs:(671,1)-(717,52)) DriverPipeline.compileOne' (compiler/main/DriverPipeline.hs:(135,1)-(287,55)) GhcMake.upsweep_mod.compile_it_discard_iface (compiler/main/GhcMake.hs:(1463,13)-(1465,61)) GhcMake.upsweep_mod (compiler/main/GhcMake.hs:(1403,1)-(1559,49)) GhcMake.parUpsweep_one (compiler/main/GhcMake.hs:(1066,1)-(1229,65)) ErrUtils.prettyPrintGhcErrors (compiler/main/ErrUtils.hs:(681,1)-(690,44)) GhcMake.parUpsweep.\.spawnWorkers.\.\ (compiler/main/GhcMake.hs:(921,43)-(976,75)) GhcMake.parUpsweep.\.spawnWorkers.\ (compiler/main/GhcMake.hs:(921,13)-(976,75)) GhcMake.parUpsweep.\.spawnWorkers (compiler/main/GhcMake.hs:(920,11)-(976,75)) GhcMonad.liftIO (compiler/main/GhcMonad.hs:112:3-30) GhcMake.parUpsweep.\ (compiler/main/GhcMake.hs:(877,62)-(1006,44)) GhcMake.parUpsweep (compiler/main/GhcMake.hs:(844,1)-(1036,36)) GhcMake.load'.upsweep_fn (compiler/main/GhcMake.hs:(393,9)-(394,41)) GhcMake.load' (compiler/main/GhcMake.hs:(246,1)-(494,38)) GhcMake.load (compiler/main/GhcMake.hs:(238,1)-(240,44)) GhcMonad.>>=.\ (compiler/main/GhcMonad.hs:109:26-57) GhcMonad.>>= (compiler/main/GhcMonad.hs:109:3-57) Panic.withSignalHandlers (compiler/utils/Panic.hs:(255,1)-(313,37)) GHC.runGhc (compiler/main/GHC.hs:(441,1)-(446,26)) Exception.gcatch (compiler/utils/Exception.hs:65:3-37) Exception.ghandle (compiler/utils/Exception.hs:75:1-21) GHC.defaultErrorHandler (compiler/main/GHC.hs:(381,1)-(413,7)) Main.main (ghc/Main.hs:(90,1)-(150,64)) }}} this looks more the the proper error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 04:23:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 04:23:09 -0000 Subject: [GHC] #15411: urk! lookup local fingerprint In-Reply-To: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> References: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> Message-ID: <060.0c3e5ebbc5cdcc84cd5d6a4bd7abeb2b@haskell.org> #15411: urk! lookup local fingerprint -------------------------------------+------------------------------------- Reporter: admock | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15399 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by admock): I bisected containers and the bad commit is cfb136731bc5c182e005b21a2dd857fd8c9694df. I looked at the diff but I don't see how it could cause this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 06:18:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 06:18:11 -0000 Subject: [GHC] #15411: urk! lookup local fingerprint In-Reply-To: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> References: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> Message-ID: <060.4fa6bb54c4100731b76e036bed3eeb0e@haskell.org> #15411: urk! lookup local fingerprint -------------------------------------+------------------------------------- Reporter: admock | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15399 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:10 admock]: > I bisected containers and the bad commit is cfb136731bc5c182e005b21a2dd857fd8c9694df. I looked at the diff but I don't see how it could cause this. Thanks. I had started bisection as well, but my PowerMac is quite slow :-( I suspected that commit could be the culprit. Something in the implementation of an unboxed array could be endian sensitive. I think I saw some changes regarding unboxed arrays happen recently. But first I will have a look at changeset:ec22f7dd again, which is the commit that caused #15399 and that is only partially fixed. My plan is to cherry-pick cfb126 in containers and build at changeset:ec22f7dd and the previous commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 06:39:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 06:39:23 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.4aca2985f790e5763642afcbbe4ab6c1@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:65 simonpj]: > Maybe try (3) in comment:59? That makes before-and-after more similar. Yes, will do that. > It might help to put it all on a branch... I'm not sure of the precise code you are measuring. I took the patch from phabricator and rebased it onto what I figured must be the last commit before Richard started working on it. I'll push my branch to git.haskell.org. > (It's cool that balanced unions are actually faster. FOUR TIMES faster!) It is, although it would have been easier for us if that had turned out to be the problem. Then again, one of the fundamental libraries out there not being broken is kind of a comforting thought... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 09:06:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 09:06:53 -0000 Subject: [GHC] #15421: Refactor (~) to reduce the superclass stack In-Reply-To: <046.7da112720f7a39139593aa39e2475ff2@haskell.org> References: <046.7da112720f7a39139593aa39e2475ff2@haskell.org> Message-ID: <061.203d554c66f214901b370f36a22f9b33@haskell.org> #15421: Refactor (~) to reduce the superclass stack -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f265008fb6f70830e7e92ce563f6d83833cef071/ghc" f265008f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f265008fb6f70830e7e92ce563f6d83833cef071" Refactor (~) to reduce the suerpclass stack The constraint (~) used to be (effectively): class a ~~ b => (a :: k) ~ (b :: k) but, with this patch, it is now defined uniformly with (~~) and Coercible like this: class a ~# b => (a :: k) ~ (b :: k) Result: * One less superclass selection when goinng from (~) to (~#) Better for compile time and better for debugging with -ddump-simpl * The code for (~), (~~), and Coercible looks uniform, and appears together, e.g. in TysWiredIn and ClsInst.matchGlobalInst. Previously the code for (~) was different, and unique. Not only is this simpler, but it also makes the compiler a bit faster; T12227: 9% less allocation T12545: 7% less allocation This patch fixes Trac #15421 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 09:06:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 09:06:53 -0000 Subject: [GHC] #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards In-Reply-To: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> References: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> Message-ID: <065.a0ae6eb2d0a2c78a442f370b0120e114@haskell.org> #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4968 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"45cfe6514afb47c26883687e25ff7eb1e40c5a52/ghc" 45cfe651/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="45cfe6514afb47c26883687e25ff7eb1e40c5a52" Small refactor in desugar of pattern matching In reviewing Phab:D4968 for Trac #15385 I saw a small but simple refactor to avoid unnecessary work in the desugarer. This patch just arranges to call matchSinglePatVar v ... rather than matchSinglePat (Var v) ... The more specialised function already existed, as match_single_pat_var I also added more comments about decideBangHood }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 09:09:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 09:09:13 -0000 Subject: [GHC] #15421: Refactor (~) to reduce the superclass stack In-Reply-To: <046.7da112720f7a39139593aa39e2475ff2@haskell.org> References: <046.7da112720f7a39139593aa39e2475ff2@haskell.org> Message-ID: <061.23267a3e48843a977f9bd2235dc184ec@haskell.org> #15421: Refactor (~) to reduce the superclass stack -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 09:18:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 09:18:34 -0000 Subject: [GHC] #15444: 8.4.3 has an undocumented dependency on libnuma. Message-ID: <047.a9be0b30ca9742d4a5738899e0757af8@haskell.org> #15444: 8.4.3 has an undocumented dependency on libnuma. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See also https://github.com/haskell/network/issues/328 for some discussion. The issue seems to be that the rts "package" depends on libnuma. See below for build log and rts package info. {{{ The Glorious Glasgow Haskell Compilation System, version 8.4.3 cabal-install version 2.2.0.0 compiled using version 2.2.0.0 of the Cabal library - network-2.6.3.5 (lib:network) (requires build) }}} {{{ checking for netdb.h... yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking netinet/tcp.h usability... yes checking netinet/tcp.h presence... yes checking for netinet/tcp.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking sys/uio.h usability... yes checking sys/uio.h presence... yes checking for sys/uio.h... yes checking sys/un.h usability... yes checking sys/un.h presence... yes checking for sys/un.h... yes checking linux/can.h usability... yes checking linux/can.h presence... yes checking for linux/can.h... yes checking linux/tcp.h usability... yes checking linux/tcp.h presence... yes checking for linux/tcp.h... yes checking net/if.h usability... yes checking net/if.h presence... yes checking for net/if.h... yes checking for readlink... yes checking for symlink... yes checking for if_nametoindex... yes checking for struct msghdr.msg_control... yes checking for struct msghdr.msg_accrights... no checking for struct sockaddr.sa_len... no checking for in_addr_t in netinet/in.h... yes checking for SO_PEERCRED and struct ucred in sys/socket.h... yes checking for getpeereid in unistd.h... checking for getpeereid... no checking for _head_libws2_32_a in -lws2_32... no checking for getaddrinfo... yes checking for gai_strerror... yes checking whether AI_ADDRCONFIG is declared... yes checking whether AI_ALL is declared... yes checking whether AI_NUMERICSERV is declared... yes checking whether AI_V4MAPPED is declared... yes checking whether IPV6_V6ONLY is declared... yes checking whether IPPROTO_IP is declared... yes checking whether IPPROTO_TCP is declared... yes checking whether IPPROTO_IPV6 is declared... yes checking for sendfile in sys/sendfile.h... yes checking for sendfile in sys/socket.h... no checking for gethostent... yes checking for accept4... yes configure: creating ./config.status config.status: creating network.buildinfo config.status: creating include/HsNetworkConfig.h configure: WARNING: unrecognized options: --with-compiler Preprocessing library for network-2.6.3.5.. /usr/bin/ld.gold: error: cannot find -lnuma collect2: error: ld returned 1 exit status linking dist/build/Network/BSD_hsc_make.o failed (exit code 1) command was: /usr/bin/gcc dist/build/Network/BSD_hsc_make.o dist/build/Network/BSD_hsc_utils.o -o dist/build/Network/BSD_hsc_make -fuse-ld=gold -fno-stack-protector -fuse-ld=gold -L/usr/local/lib/ghc-8.4.3/unix-2.7.2.2 -Wl,-R,/usr/local/lib/ghc-8.4.3/unix-2.7.2.2 -lrt -lutil -ldl -lpthread -L/usr/local/lib/ghc-8.4.3/time-1.8.0.2 -Wl,-R,/usr/local/lib/ghc-8.4.3/time-1.8.0.2 -L/usr/local/lib/ghc-8.4.3/bytestring-0.10.8.2 -Wl,-R,/usr/local/lib/ghc-8.4.3/bytestring-0.10.8.2 -L/usr/local/lib/ghc-8.4.3/deepseq-1.4.3.0 -Wl,-R,/usr/local/lib/ghc-8.4.3/deepseq-1.4.3.0 -L/usr/local/lib/ghc-8.4.3/array-0.5.2.0 -Wl,-R,/usr/local/lib/ghc-8.4.3/array-0.5.2.0 -L/usr/local/lib/ghc-8.4.3/base-4.11.1.0 -Wl,-R,/usr/local/lib/ghc-8.4.3/base-4.11.1.0 -L/usr/local/lib/ghc-8.4.3 /integer-gmp-1.0.2.0 -Wl,-R,/usr/local/lib/ghc-8.4.3/integer-gmp-1.0.2.0 -lgmp -L/usr/local/lib/ghc-8.4.3/ghc-prim-0.5.2.0 -Wl,-R,/usr/local/lib/ghc-8.4.3/ghc-prim-0.5.2.0 -L/usr/local/lib/ghc-8.4.3/rts -Wl,-R,/usr/local/lib/ghc-8.4.3/rts -lm -lrt -ldl -lnuma -lpthread cabal: Failed to build exe:hsc2hs from hsc2hs-0.68.3 (which is required by cabal-install-2.2.0.0). See the build log above for details. Failed to build network-2.6.3.5 (which is required by cabal- install-2.2.0.0). See the build log above for details. }}} {{{ name: rts version: 1.0 id: rts key: rts license: BSD-3-Clause maintainer: glasgow-haskell-users at haskell.org exposed: True library-dirs: /usr/local/lib/ghc-8.4.3/rts hs-libraries: HSrts Cffi extra-libraries: m rt dl numa pthread include-dirs: /usr/local/lib/ghc-8.4.3/include includes: Stg.h ld-options: "-Wl,-u,base_GHCziTopHandler_runIO_closure" "-Wl,-u,base_GHCziTopHandler_runNonIO_closure" "-Wl,-u,ghczmprim_GHCziTuple_Z0T_closure" "-Wl,-u,ghczmprim_GHCziTypes_True_closure" "-Wl,-u,ghczmprim_GHCziTypes_False_closure" "-Wl,-u,base_GHCziPack_unpackCString_closure" "-Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure" "-Wl,-u,base_GHCziIOziException_stackOverflow_closure" "-Wl,-u,base_GHCziIOziException_heapOverflow_closure" "-Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure" "-Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure" "-Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure" "-Wl,-u,base_GHCziIOziException_cannotCompactFunction_closure" "-Wl,-u,base_GHCziIOziException_cannotCompactPinned_closure" "-Wl,-u,base_GHCziIOziException_cannotCompactMutable_closure" "-Wl,-u,base_ControlziExceptionziBase_absentSumFieldError_closure" "-Wl,-u,base_ControlziExceptionziBase_nonTermination_closure" "-Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure" "-Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure" "-Wl,-u,base_GHCziConcziSync_runSparks_closure" "-Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure" "-Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure" "-Wl,-u,base_GHCziConcziSignal_runHandlersPtr_closure" "-Wl,-u,base_GHCziTopHandler_flushStdHandles_closure" "-Wl,-u,base_GHCziTopHandler_runMainIO_closure" "-Wl,-u,ghczmprim_GHCziTypes_Czh_con_info" "-Wl,-u,ghczmprim_GHCziTypes_Izh_con_info" "-Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info" "-Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info" "-Wl,-u,ghczmprim_GHCziTypes_Wzh_con_info" "-Wl,-u,base_GHCziPtr_Ptr_con_info" "-Wl,-u,base_GHCziPtr_FunPtr_con_info" "-Wl,-u,base_GHCziInt_I8zh_con_info" "-Wl,-u,base_GHCziInt_I16zh_con_info" "-Wl,-u,base_GHCziInt_I32zh_con_info" "-Wl,-u,base_GHCziInt_I64zh_con_info" "-Wl,-u,base_GHCziWord_W8zh_con_info" "-Wl,-u,base_GHCziWord_W16zh_con_info" "-Wl,-u,base_GHCziWord_W32zh_con_info" "-Wl,-u,base_GHCziWord_W64zh_con_info" "-Wl,-u,base_GHCziStable_StablePtr_con_info" "-Wl,-u,hs_atomic_add8" "-Wl,-u,hs_atomic_add16" "-Wl,-u,hs_atomic_add32" "-Wl,-u,hs_atomic_add64" "-Wl,-u,hs_atomic_sub8" "-Wl,-u,hs_atomic_sub16" "-Wl,-u,hs_atomic_sub32" "-Wl,-u,hs_atomic_sub64" "-Wl,-u,hs_atomic_and8" "-Wl,-u,hs_atomic_and16" "-Wl,-u,hs_atomic_and32" "-Wl,-u,hs_atomic_and64" "-Wl,-u,hs_atomic_nand8" "-Wl,-u,hs_atomic_nand16" "-Wl,-u,hs_atomic_nand32" "-Wl,-u,hs_atomic_nand64" "-Wl,-u,hs_atomic_or8" "-Wl,-u,hs_atomic_or16" "-Wl,-u,hs_atomic_or32" "-Wl,-u,hs_atomic_or64" "-Wl,-u,hs_atomic_xor8" "-Wl,-u,hs_atomic_xor16" "-Wl,-u,hs_atomic_xor32" "-Wl,-u,hs_atomic_xor64" "-Wl,-u,hs_cmpxchg8" "-Wl,-u,hs_cmpxchg16" "-Wl,-u,hs_cmpxchg32" "-Wl,-u,hs_cmpxchg64" "-Wl,-u,hs_atomicread8" "-Wl,-u,hs_atomicread16" "-Wl,-u,hs_atomicread32" "-Wl,-u,hs_atomicread64" "-Wl,-u,hs_atomicwrite8" "-Wl,-u,hs_atomicwrite16" "-Wl,-u,hs_atomicwrite32" "-Wl,-u,hs_atomicwrite64" pkgroot: "/usr/local/lib/ghc-8.4.3" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 09:31:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 09:31:12 -0000 Subject: [GHC] #15416: Higher rank types in pattern synonyms In-Reply-To: <044.53c8e12910c3cdd85f926a53a436c321@haskell.org> References: <044.53c8e12910c3cdd85f926a53a436c321@haskell.org> Message-ID: <059.e5cadf78643b482955ebd316035cdcde@haskell.org> #15416: Higher rank types in pattern synonyms -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mniip): Replying to [comment:1 simonpj]: > > You are treading on thin ice. Consider this > {{{ > f1 :: (forall a. a->a) -> Int > f1 (x :: forall b. b->b) = x 3 > > f2 :: (forall a. a->a) -> Int > f2 x = case x of > (y :: forall b. b->b) -> y 3 > }}} > You might expect `f1` and `f2` to behave the same, because `f2` only replaces > inline pattern matching with a case-expression. > > But `f1` as accepted and `f2` is rejected thus > {{{ > * Couldn't match expected type `a0 -> a0' > with actual type `forall b. b -> b' > * When checking that the pattern signature: forall b. b -> b > fits the type of its context: a0 -> a0 > In the pattern: y :: forall b. b -> b > In a case alternative: (y :: forall b. b -> b) -> y 3 > | > 10 | (y :: forall b. b->b) -> y 3 > }}} > Very similar to the failure you see. Why? > > * In `f1` the higher-rank type inference machinery "pushes down" the type of the argument, from `f1`'s type signature, into the pattern `(x :: forall b. b->b)`. > > * But in `f2`, the variable `x` indeed gets type `forall b. b->b` (via this same push-down mechanism, but then ''that type gets instantiated at the call site of `x`''. So the scrutinee of the `case` has type `alpha -> alpha`, for some as-yet-unknown type `alpha`. > And that, of course, is not polymorphic enough. Wouldn't `alpha` be a unification variable in this case and therefore be polymorphic just enough? > * The type inference engine never generalises the scrutinee of a `case`. (I suppose one could revisit that, though I do not know how.) Consider if desugaring came before typechecking. This wouldn't be a problem because this isn't a case-of in the Core sense. Can't say I have a solution but maybe it's worth taking a look at typechecking a ''haskell'' case-of based on what ''Core'' constructs it desugars into? > I hope that explains why your fourth example breaks. > > When we first did pattern synonyms I expected the types to always be of form > {{{ > K :: t1 -> ... -> tn -> T s1 .. sm > }}} > > where `T` is a data type. We loosened that up a bit to allow > arbitrary return types. (I forget what the motivation was; I wonder if anyone else remembers? There > may be a ticket.) That does indeed explain the extreme awkwardness of the current syntax. The part where `P => Q => A -> B -> C` bizzarely stands for `P => ((Q *> (A, B)) <-> C)`. > What you are doing is putting a `forall` in that return position. I never considered that! > It would be interesting to see a compelling motivation for doing this. Eg why don't you say this? > {{{ > pattern N :: forall a r. () => () => r -> (a -> r) -> r > pattern J :: forall a r. a -> r -> (a -> r) -> r > }}} Because then reversing the equations gets you `forall a r` I can match on a scrutinee of type `r -> (a -> r) -> r` and bind a variable of type `a`. This is clearly not what we want here (`r` is rigid, but we demand `r ~ Maybe`), and the definition of `J` doens't typecheck under that signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 09:37:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 09:37:04 -0000 Subject: [GHC] #15260: Xmobar crashes with segmentation fault In-Reply-To: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> References: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> Message-ID: <061.370b43506726a75fe72895a06552900f@haskell.org> #15260: Xmobar crashes with segmentation fault ----------------------------------+-------------------------------------- Reporter: Voronwe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by hsyl20): I get the same kind of segfault with GHC 8.4.3 in another program unrelated to xmobar. Sadly it's not simpler as it's a standalone static program that runs directly on top of Linux in a ramdisk (using [http://haskus.org/system haskus-system])... Hence I can't use any tool like valgrind or gdb. Anyway one good thing is that it fails invariably within a few seconds and here is what I've found: 1) The segfault occurs [https://phabricator.haskell.org/diffusion/GHC/browse/ghc-8.4/rts/sm/Evac.c$659 here] because `info` is garbage (sometimes 0). 2) Recompiling with `-debug -with-rtsopts=-DS`, I get: {{{ Clock2: internal error: checkClosure (closure type 62) (GHC version 8.4.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} because of a bug [https://phabricator.haskell.org/rGHC9976bed24dda9449ac2e3e95fb4bf8b379114a28 fixed in 8.6]. After cherry-picking this commit into ghc-8.4.3, `-DS` doesn't report anything useful (nor do the other `-D*` flags). 3) Using `-V0` or `-C0` delays the segfault. 4) Same bug with GHC 8.4.2 I'll try to find the commit introducing the regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 09:49:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 09:49:48 -0000 Subject: [GHC] #15347: QuantifiedConstraints: Implication constraints with type families don't work In-Reply-To: <049.446b77184844bcadda01810c8c61d990@haskell.org> References: <049.446b77184844bcadda01810c8c61d990@haskell.org> Message-ID: <064.e226deb4ca1c379c402656d6aea2af73@haskell.org> #15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aaronvargo): Replying to [comment:16 simonpj]: I thought I'd once seen a ticket for this, and I've managed to find it: see #3490, where you write: > The easiest way forward is to re-express your program using type functions Also, on second thought, what I said in comment:18 won't work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 09:58:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 09:58:14 -0000 Subject: [GHC] #15443: ghc panic when running GI.init on intero REPL In-Reply-To: <050.29c9f5cf48c2b9e3ef9ab7db906ae6c7@haskell.org> References: <050.29c9f5cf48c2b9e3ef9ab7db906ae6c7@haskell.org> Message-ID: <065.49dfc82a855cfd6f15bf6ce9dab8548b@haskell.org> #15443: ghc panic when running GI.init on intero REPL --------------------------------+-------------------------------------- Reporter: esclerofilo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------+-------------------------------------- Comment (by mr.schyte): Hi! I've hit the same bug with intero. If I try calling a function from the emacs repl I receive the panic message, but the same call works fine from the terminal. {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): nameModule system $dShow_a4FZ Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This is the program I'm using; I'm trying to call "readBlock s 10", which fails. I can call both blockPath and print blocks using show without errors. {{{ module Lib where import Control.Exception (try, catch, IOException) import qualified Data.ByteString as B import System.FilePath import Text.Printf (printf) data Block = Block { offset :: Int, -- Padding length at the front bytes :: B.ByteString -- The contents of the block } deriving Show data Store = Store { dirs :: [FilePath], bsize :: Int, count :: Int } s = Store ["/tmp/1", "/tmp/2"] 10 10 blockPath :: Store -> Int -> FilePath blockPath (Store d _ _) i = dir (printf "%016x.dat" i) where dir = d !! (mod i (length d)) readBlock :: Store -> Int -> IO (Block) readBlock s i = catch (B.readFile path >>= (return . (Block i))) handler where handler :: IOException -> IO (Block) handler _ = return $ Block 0 (B.replicate (bsize s) 0) path = blockPath s i }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 10:45:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 10:45:52 -0000 Subject: [GHC] #15347: QuantifiedConstraints: Implication constraints with type families don't work In-Reply-To: <049.446b77184844bcadda01810c8c61d990@haskell.org> References: <049.446b77184844bcadda01810c8c61d990@haskell.org> Message-ID: <064.646765629ffa982551cad0faa72f8451@haskell.org> #15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > The superclass isn't allowed to mention variables which don't appear in the head, Ah, I was thinking "instance decl" but actually we have a class decl. My mistake. Not allowing functions in the instance head not to do with ''ambiguity''; it's to do with ''coherence'. Consider, at the term level {{{ f [x] = x-1 f (reverse [x]) = x+1 }}} `reverse` is perfectly injective, but we don't want `(f e)` to return different answers depending on the evaluated-ness of `e`. Can you distil a small example that shows the utility of having a function in the head? ------------- Guessing, maybe what you want is this: {{{ class (forall a. Eq a => Eq (F t a)) => C t where type F t :: * -> * instance C Int where F Int = Maybe f1 :: C t => ... f1 = e1 f2 :: C Int => ... f2 = e2 }}} In `f1` we have the quantified constraint available but with a function in the head, so it's unusuable. But in `f2` the quantified constraint becomes {{{ forall a. Eq a => Eq (F Int a) }}} which rewrites (via the type instance) to {{{ forall a. Eq a => Eq (Maybe a) }}} and this ''is'' usable. So, maybe a quantified constraints with a function in the head is just "parked", but it wakes up if the function can be reduced. This all seems complicated to specify, let alone implement, but it's the closest I can get. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 12:12:29 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 12:12:29 -0000 Subject: [GHC] #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation In-Reply-To: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> References: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> Message-ID: <061.f24c073b30a4aac897c9c8c4d568bf04@haskell.org> #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation -------------------------------------+------------------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research Component: Compiler (Type | needed checker) | Version: 8.4.3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I fail to see how this would work for recursive examples like the program in comment:7 Correct. Computing `NonVoid( tau )` is an open-ended question. For some `tau`s (lke `Bar A`) it's easy; for others we could be more ambitious. It's probably undecidable in general. So we could start with something simple and become more ambitious later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 12:48:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 12:48:54 -0000 Subject: [GHC] #15415: GHCi's :kind doesn't work with wildcards In-Reply-To: <047.9324d649243992c743ffcce486b06b5a@haskell.org> References: <047.9324d649243992c743ffcce486b06b5a@haskell.org> Message-ID: <062.07e7b50dcc530a54d0387edc3afce92d@haskell.org> #15415: GHCi's :kind doesn't work with wildcards -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I would just fix this myself, but it smells intentional. Does anyone know why we have all this? I've had a look. Just fix it yourself... I have no idea why `tcRnType` should use a subtly-different interface for `tcWildCardBinders`. I suspect it's accidental. I note also that * All the other calls to `tcWildCardBindersX` pass in `newWildTyVar`. If that's what we want in `tcRnType` (and I bet it is) we can just remove the parameter from `tcWildCardBindersX` and use `newWildTyVar` directly. * There is another subtle difference: only the call from `tcRnType` passes in some skolem-info, and the effect of that is to use `scopeTyVars2` which builds an implication etc. I bet this is accidental (and wrong) too. We probably don't need that skolem-info at all. Over to you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 13:17:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 13:17:02 -0000 Subject: [GHC] #15361: Error message displays redundant equality constraint In-Reply-To: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> References: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> Message-ID: <065.3a8c3f6e6d9d0a01c58aec8f028cf7c7@haskell.org> #15361: Error message displays redundant equality constraint -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14394 | Differential Rev(s): Phab:D5002 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:7 simonpj]: > I suppose, therefore, that the solution you suggest is no unreasonable, ''provided'' you write Note to explain. Sure thing. I've updated Phab:D5002. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 13:33:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 13:33:07 -0000 Subject: [GHC] #15347: QuantifiedConstraints: Implication constraints with type families don't work In-Reply-To: <049.446b77184844bcadda01810c8c61d990@haskell.org> References: <049.446b77184844bcadda01810c8c61d990@haskell.org> Message-ID: <064.e6edb44f7b610ec02f4fff79ae0d0ed1@haskell.org> #15347: QuantifiedConstraints: Implication constraints with type families don't work -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aaronvargo): Replying to [comment:20 simonpj]: > Not allowing functions in the instance head not to do with ambiguity; it's to do with coherence But is this an issue for QCs, which can't introduce incoherence? Does it matter if two QCs might overlap, as long as locally we can't tell that they do? Suppose we had: {{{#!hs type family F a = r | r -> a type family G a = r | r -> a foo :: forall b. (forall a. Eq (F a), forall a. Eq (G a)) => Dict (Eq (F b)) foo = Dict }}} While `F b` and `G b` might overlap for some particular `b`, locally only one instance can be used to solve `Eq (F b)`, since we don't know whether `G b ~ F b`. Since the two instances are guaranteed to be coherent, wouldn't it be fine to simply pick the one that matches? (If both were to match then the program would still be rejected). Likewise for the case with non-injective independent type families: {{{#!hs foo :: forall b. (forall t. C (F b) [t], forall t. C (G b) [t]) => Dict (C (F b) [Int]) }}} The first instance should just be used, since it's the only one that matches given the knowledge available locally. How does the compiler currently deal with type families in non-quantified constraints? What makes it more difficult to allow them in QCs? > Can you distil a small example that shows the utility of having a function in the head? For now I have no use case for the injective type family case, and only really care about the independent family case. I'll try and come up with a simpler example than the category one. > So, maybe a quantified constraint with a function in the head is just "parked", but it wakes up if the function can be reduced. This is much less useful than what I want, though I suppose it might help in some small minority of cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 13:43:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 13:43:47 -0000 Subject: [GHC] #15415: GHCi's :kind doesn't work with wildcards In-Reply-To: <047.9324d649243992c743ffcce486b06b5a@haskell.org> References: <047.9324d649243992c743ffcce486b06b5a@haskell.org> Message-ID: <062.ea1e6c6cf9be4f55dc01cdb3c4dd304b@haskell.org> #15415: GHCi's :kind doesn't work with wildcards -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): Thanks for looking into, good to know it's not intentional. Richard, have you started implementing a fix? If not, I think I understand this part of code enough to do it myself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 14:12:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 14:12:26 -0000 Subject: [GHC] #12625: Bad error message for flags with required but missing arguments In-Reply-To: <050.552ad6bb3a020bd4f5961b4cb97a9c89@haskell.org> References: <050.552ad6bb3a020bd4f5961b4cb97a9c89@haskell.org> Message-ID: <065.6e2bbc41ca427718e0ce218e1ff2fb60@haskell.org> #12625: Bad error message for flags with required but missing arguments -------------------------------------+------------------------------------- Reporter: dramforever | Owner: RolandSenn Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn Comment: I'll work on this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 16:28:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 16:28:48 -0000 Subject: [GHC] #14627: qAddTopDecls: can't convert top-level declarations In-Reply-To: <049.485d47f57c339e482133548d02dc333a@haskell.org> References: <049.485d47f57c339e482133548d02dc333a@haskell.org> Message-ID: <064.74d62d5b1086f69536e4d4f716580d60@haskell.org> #14627: qAddTopDecls: can't convert top-level declarations -------------------------------------+------------------------------------- Reporter: tianxiaogu | Owner: mgsloan Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: th/T14627 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4914 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"774f366ebe58023fc50ba346894227b14816fe67/ghc" 774f366/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="774f366ebe58023fc50ba346894227b14816fe67" Fail instead of panic-ing when qAddTopDecls has conversion error See https://ghc.haskell.org/trac/ghc/ticket/14627 for an example where GHC panics when using qAddTopDecls on [d| f = Bool |]. Instead, it should be a normal error message, and that's what this change is for. It does not entirely resolve Trac#14627, since "Illegal variable name: 'bool'" isn't a very good error for this cirumstance. Test Plan: Manually tested. Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4914 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 16:28:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 16:28:48 -0000 Subject: [GHC] #15440: Flush eventlog in hs_init_ghc In-Reply-To: <043.a9a8394a5250a3fe2c866ddd9f27e645@haskell.org> References: <043.a9a8394a5250a3fe2c866ddd9f27e645@haskell.org> Message-ID: <058.1e525a8b90e4151d481f06557ae56ba6@haskell.org> #15440: Flush eventlog in hs_init_ghc -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7a3e1b25ff9a570851a59c4cf3600daa49867b9b/ghc" 7a3e1b2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7a3e1b25ff9a570851a59c4cf3600daa49867b9b" rts: Flush eventlog in hs_init_ghc (fixes #15440) Without this change RTS typically doesn't flush some important events until the process terminates or it doesn't write them at all in case it terminates abnormally. Here is a list of such events: * EVENT_WALL_CLOCK_TIME * EVENT_OS_PROCESS_PID * EVENT_OS_PROCESS_PPID * EVENT_RTS_IDENTIFIER * EVENT_PROGRAM_ARGS * EVENT_PROGRAM_ENV }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 16:42:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 16:42:50 -0000 Subject: [GHC] #15440: Flush eventlog in hs_init_ghc In-Reply-To: <043.a9a8394a5250a3fe2c866ddd9f27e645@haskell.org> References: <043.a9a8394a5250a3fe2c866ddd9f27e645@haskell.org> Message-ID: <058.e3b5936f780d38519f808e7de366d777@haskell.org> #15440: Flush eventlog in hs_init_ghc -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: feature request | Status: merge Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 16:43:18 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 16:43:18 -0000 Subject: [GHC] #15445: SPCIALIZE one of two identical functions does not fire well Message-ID: <047.c1676aaf78d977670954b9a4dbdf798e@haskell.org> #15445: SPCIALIZE one of two identical functions does not fire well --------------------------------------+--------------------------------- Reporter: nobrakal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- Hi, I am playing with `SPECIALIZE` pragma: {{{#!hs module Todo where {-# SPECIALIZE plusTwoRec :: [Int] -> [Int] #-} plusTwoRec :: Num a => [a] -> [a] plusTwoRec [] = [] plusTwoRec (x:xs) = x+2:plusTwoRec xs plusTwoRec' :: Num a => [a] -> [a] plusTwoRec' [] = [] plusTwoRec' (x:xs) = x+2:plusTwoRec' xs }}} And wanted to benchmark it with (in `Main.hs`): {{{#!hs import Todo import Criterion.Main aListOfInt :: [Int] aListOfInt = [1..10000] main :: IO () main = defaultMain [ bench "plusTwoRec" $ nf plusTwoRec aListOfInt , bench "plusTwoRec'" $ nf plusTwoRec' aListOfInt ] }}} Sadly, the rule of specialization of `plusTwoRec` does not fire in Main.hs (I compiled with: `ghc Main.hs -O -dynamic -ddump-rule-firings` (the `-dynamic` part is due to my ArchLinux installaltion)). The result is: {{{ [1 of 2] Compiling Todo ( Todo.hs, Todo.o ) Rule fired: Class op + (BUILTIN) Rule fired: Class op fromInteger (BUILTIN) Rule fired: integerToInt (BUILTIN) Rule fired: SPEC plusTwoRec (Todo) [2 of 2] Compiling Main ( Main.hs, Main.o ) Rule fired: Class op enumFromTo (BUILTIN) Rule fired: unpack (GHC.Base) Rule fired: unpack (GHC.Base) Rule fired: eftIntList (GHC.Enum) Rule fired: unpack-list (GHC.Base) Rule fired: unpack-list (GHC.Base) Linking Main ... }}} I have inspected a bit the code produced after the simplifications passes (with `-ddump-simpl`) and here is the suspicious part: {{{ plusTwoRec :: forall a. Num a => [a] -> [a] [GblId, Arity=2, Caf=NoCafRefs, Str=, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] plusTwoRec = plusTwoRec' }}} I believe that `plusTwoRec` is inlined before the specialization has a chance to fire, but I am not sure at all ! Separating the two functions definitions in two different files works. So I don't know if this is a GHC bug, myself that does not read the right part of the GHC manual, if it is only a lack of documentation, or anything else. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 16:43:31 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 16:43:31 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.ba4eef3562b218415c6f492c3bbdf4b1@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: osa1 Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4962 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 16:44:08 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 16:44:08 -0000 Subject: [GHC] #15445: SPECIALIZE one of two identical functions does not fire well (was: SPCIALIZE one of two identical functions does not fire well) In-Reply-To: <047.c1676aaf78d977670954b9a4dbdf798e@haskell.org> References: <047.c1676aaf78d977670954b9a4dbdf798e@haskell.org> Message-ID: <062.5460de5db1f9bc3c119869be9c9ae604@haskell.org> #15445: SPECIALIZE one of two identical functions does not fire well ---------------------------------+-------------------------------------- Reporter: nobrakal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 16:45:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 16:45:14 -0000 Subject: [GHC] #15399: Build failure on PowerPC 64-bit big endian In-Reply-To: <047.59eacae05c8ce75e039f0bbb218e3836@haskell.org> References: <047.59eacae05c8ce75e039f0bbb218e3836@haskell.org> Message-ID: <062.0d225044f51e40968f38523385f24599@haskell.org> #15399: Build failure on PowerPC 64-bit big endian ----------------------------------------+---------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5001 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by bgamari): * status: new => merge * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 17:12:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 17:12:40 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.680bb18e5fc5145bac14505ad9fe2072@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: osa1 Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4962 Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): When the next GHC alpha (or beta or release candidate) comes out, I'll give this a try. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 17:43:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 17:43:26 -0000 Subject: [GHC] #14185: Non-local bug reporting around levity polymorphism In-Reply-To: <047.b7b54b9f6935b8234dc0884836db560a@haskell.org> References: <047.b7b54b9f6935b8234dc0884836db560a@haskell.org> Message-ID: <062.037d9004987f3a9497d8f9ede4526f11@haskell.org> #14185: Non-local bug reporting around levity polymorphism -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: | LevityPolymorphism, | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3581212e3a5ba42114f47ed83a96322e0e8028ab/ghc" 3581212/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3581212e3a5ba42114f47ed83a96322e0e8028ab" Add an expect_broken test for #14185 Test Plan: validate Reviewers: goldfire, bgamari, alpmestan Reviewed By: alpmestan Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14185 Differential Revision: https://phabricator.haskell.org/D4981 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 17:43:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 17:43:26 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.dd8cf44740b6751bbcb86a6d9a83a691@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: osa1 Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4962 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3c311e50e760c3ba00dc9692ad1536c79820598d/ghc" 3c311e50/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3c311e50e760c3ba00dc9692ad1536c79820598d" Run StgCse after unarise, fixes #15300 Given two unboxed sum terms: (# 1 | #) :: (# Int | Int# #) (# 1 | #) :: (# Int | Int #) These two terms are not equal as they unarise to different unboxed tuples. However StgCse was thinking that these are equal, and replacing one of these with a binder to the other. To not deal with unboxed sums in StgCse we now do it after unarise. For StgCse to maintain post-unarise invariants we factor-out case binder in-scopeness check to `stgCaseBndrInScope` and use it in StgCse. Also did some refactoring in SimplStg. Another way to fix this would be adding a special case in StgCse to not bring unboxed sum binders in scope: diff --git a/compiler/simplStg/StgCse.hs b/compiler/simplStg/StgCse.hs index 6c740ca4cb..93a0f8f6ad 100644 --- a/compiler/simplStg/StgCse.hs +++ b/compiler/simplStg/StgCse.hs @@ -332,7 +332,11 @@ stgCseExpr env (StgLetNoEscape binds body) stgCseAlt :: CseEnv -> OutId -> InStgAlt -> OutStgAlt stgCseAlt env case_bndr (DataAlt dataCon, args, rhs) = let (env1, args') = substBndrs env args - env2 = addDataCon case_bndr dataCon (map StgVarArg args') env1 + env2 + | isUnboxedSumCon dataCon + = env1 + | otherwise + = addDataCon case_bndr dataCon (map StgVarArg args') env1 -- see note [Case 2: CSEing case binders] rhs' = stgCseExpr env2 rhs in (DataAlt dataCon, args', rhs') I think this patch seems better in that it doesn't add a special case to StgCse. Test Plan: Validate. I tried to come up with a minimal example but failed. I thought a simple program like data T = T (# Int | Int #) (# Int# | Int #) case T (# 1 | #) (# 1 | #) of ... should be enough to trigger this bug, but for some reason StgCse doesn't do anything on this program. Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15300 Differential Revision: https://phabricator.haskell.org/D4962 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 17:43:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 17:43:26 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.1cabc510129cdf5840b7018b438ab4db@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e5f3de2cf2f52e7079cbee624ae91beecf663f87/ghc" e5f3de2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e5f3de2cf2f52e7079cbee624ae91beecf663f87" update core-spec for GRefl and re-factored Refl Ticket #15192 introduced the generalized reflexive coercion `GRefl` and nominal reflexive `Refl`, and removed `CoherenceCo`. Update core-spec accordingly. Not sure about notations though; suggestions on more concise notations would be great. Test Plan: Read core-spec.pdf Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4984 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 17:43:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 17:43:26 -0000 Subject: [GHC] #15399: Build failure on PowerPC 64-bit big endian In-Reply-To: <047.59eacae05c8ce75e039f0bbb218e3836@haskell.org> References: <047.59eacae05c8ce75e039f0bbb218e3836@haskell.org> Message-ID: <062.8d4cdedfa2a5ab36060618a47922b4fe@haskell.org> #15399: Build failure on PowerPC 64-bit big endian ----------------------------------------+---------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5001 Wiki Page: | ----------------------------------------+---------------------------------- Comment (by Ben Gamari ): In [changeset:"d7cb1bbc26719cf6082abe0d91d80be466e25bfc/ghc" d7cb1bbc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d7cb1bbc26719cf6082abe0d91d80be466e25bfc" Fix endian issues in ghc-heap In test heap_all arity and n_args were swapped on big endian systems. Take care of endianness when reading parts of a machine word from a `Word`. This fixes one out of 36 failing tests reported in #15399. Test Plan: validate Reviewers: simonmar, bgamari, hvr, erikd Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15399 Differential Revision: https://phabricator.haskell.org/D5001 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 17:53:41 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 17:53:41 -0000 Subject: [GHC] #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 Message-ID: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 --------------------------------------+------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.4.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- compiling files in ghci on MacOS eventually results in a panic with error: {{{ malformed mach-o: load commands size (32800) > 32768 }}} I can reproduce this problem by repeatedly compiling (and loading) a file and then deleting the .o file. I understand that this an OS limitation but why does repeatedly doing the same thing results in this? i.e. why don't I get it on the first compile (and load). It seems that successive loads are being appended to something eventually resulting in the error. To duplicate: ghci -ignore-dot-ghci -fobject-code < ghci.sh >& ghci.out & If you look for the first "panic" in the .out file you'll see {{{ Prelude Main> ghc: panic! (the 'impossible' happened) (GHC version 8.6.0.20180714 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc55569_0/libghc_2084.dylib, 5): no suitable image found. Did find: /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc55569_0/libghc_2084.dylib: malformed mach-o: load commands size (32800) > 32768 /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc55569_0/libghc_2084.dylib: stat() failed with errno=25 }}} The critical part being {{{ malformed mach-o: load commands size (32800) > 32768 }}} My understanding from https://stackoverflow.com/questions/44902695/too- many-commands-dyld-message-malformed-mach-o-load-commands-size is that this has to do with sizeofcmds but if I understand the output of otool 0l this is only 512 so I don't understand what is causing the errror. {{{ otool -l c.o|head c.o: Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags 0xfeedfacf 16777223 3 0x00 1 4 512 0x00002000 }}} This is irritating but perhaps the priority should be low rather than normal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 17:55:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 17:55:56 -0000 Subject: [GHC] #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 In-Reply-To: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> References: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> Message-ID: <060.9f792889a0420e11cf423e15b843bce8@haskell.org> #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 -------------------------------+-------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by George): * Attachment "c.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 17:56:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 17:56:48 -0000 Subject: [GHC] #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 In-Reply-To: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> References: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> Message-ID: <060.0cc60f6c5c3e7b3750bb5473613782b8@haskell.org> #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 -------------------------------+-------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by George): * Attachment "ghci.sh" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 18:00:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 18:00:27 -0000 Subject: [GHC] #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 In-Reply-To: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> References: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> Message-ID: <060.ae68569f5bcc56aa5d7170c008d41069@haskell.org> #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 -------------------------------+-------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Description changed by George: Old description: > compiling files in ghci on MacOS eventually results in a panic with > error: > > {{{ > malformed mach-o: load commands size (32800) > 32768 > }}} > > I can reproduce this problem by repeatedly compiling (and loading) a file > and then deleting the .o file. I understand that this an OS limitation > but why does repeatedly doing the same thing results in this? i.e. why > don't I get it on the first compile (and load). It seems that successive > loads are being appended to something eventually resulting in the error. > > To duplicate: > > ghci -ignore-dot-ghci -fobject-code < ghci.sh >& ghci.out & > > If you look for the first "panic" in the .out file you'll see > > {{{ > Prelude Main> ghc: panic! (the 'impossible' happened) > (GHC version 8.6.0.20180714 for x86_64-apple-darwin): > Loading temp shared object failed: > dlopen(/var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc55569_0/libghc_2084.dylib, > 5): no suitable image found. Did find: > /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc55569_0/libghc_2084.dylib: > malformed mach-o: load commands size (32800) > 32768 > /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc55569_0/libghc_2084.dylib: > stat() failed with errno=25 > }}} > > The critical part being > {{{ > malformed mach-o: load commands size (32800) > 32768 > }}} > > My understanding from https://stackoverflow.com/questions/44902695/too- > many-commands-dyld-message-malformed-mach-o-load-commands-size is that > this has to do with sizeofcmds but if I understand the output of otool 0l > this is only 512 so I don't understand what is causing the errror. > > {{{ > otool -l c.o|head > c.o: > Mach header > magic cputype cpusubtype caps filetype ncmds sizeofcmds > flags > 0xfeedfacf 16777223 3 0x00 1 4 512 > 0x00002000 > }}} > > This is irritating but perhaps the priority should be low rather than > normal. New description: compiling files in ghci on MacOS eventually results in a panic with error: {{{ malformed mach-o: load commands size (32800) > 32768 }}} I can reproduce this problem by repeatedly compiling (and loading) a file and then deleting the .o file. I understand that this an OS limitation but why does repeatedly doing the same thing results in this? i.e. why don't I get it on the first compile (and load). It seems that successive loads are being appended to something eventually resulting in the error. To duplicate: ghci -ignore-dot-ghci -fobject-code < ghci.sh >& ghci.out & If you look for the first "panic" in the .out file you'll see {{{ Prelude Main> ghc: panic! (the 'impossible' happened) (GHC version 8.6.0.20180714 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc55569_0/libghc_2084.dylib, 5): no suitable image found. Did find: /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc55569_0/libghc_2084.dylib: malformed mach-o: load commands size (32800) > 32768 /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc55569_0/libghc_2084.dylib: stat() failed with errno=25 }}} The critical part being {{{ malformed mach-o: load commands size (32800) > 32768 }}} My understanding from https://stackoverflow.com/questions/44902695/too- many-commands-dyld-message-malformed-mach-o-load-commands-size is that this has to do with sizeofcmds but if I understand the output of otool -l this is only 512 so I don't understand what is causing the errror. {{{ otool -l c.o|head c.o: Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags 0xfeedfacf 16777223 3 0x00 1 4 512 0x00002000 }}} This is irritating but perhaps the priority should be low rather than normal. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 18:02:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 18:02:45 -0000 Subject: [GHC] #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 In-Reply-To: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> References: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> Message-ID: <060.2d9d79f32d8fc787f14799a00a35a24a@haskell.org> #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 -------------------------------+-------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by George): * milestone: 8.8.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 18:29:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 18:29:09 -0000 Subject: [GHC] #15447: Mark the core libraries' internal modules "not-home" instead of "hide" Message-ID: <046.a98aa20d9b2d7592ee4ae25a27876473@haskell.org> #15447: Mark the core libraries' internal modules "not-home" instead of "hide" -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Core | Version: 8.4.3 Libraries | Keywords: haddock | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm often a bit annoyed that I cannot browse the haddocks for internal libraries. It would be nice if `base`, `ghc-prim`, `integer-gmp` and `integer-simple` could follow the example of `containers` and other libraries and offer docs for internal libraries too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 18:32:51 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 18:32:51 -0000 Subject: [GHC] #15275: AArch64 validation fails with many invalid relocations In-Reply-To: <046.09db5dc304d31321bf750c17c4d53c7c@haskell.org> References: <046.09db5dc304d31321bf750c17c4d53c7c@haskell.org> Message-ID: <061.0fa70ebcf870d2d318e6c77e6734b45e@haskell.org> #15275: AArch64 validation fails with many invalid relocations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tmobile): Is there any workaround for this? I'm hitting this while cross-compiling to aarch64 running iserv in qemu. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 18:34:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 18:34:07 -0000 Subject: [GHC] #15275: AArch64 validation fails with many invalid relocations In-Reply-To: <046.09db5dc304d31321bf750c17c4d53c7c@haskell.org> References: <046.09db5dc304d31321bf750c17c4d53c7c@haskell.org> Message-ID: <061.c9e48a064f334e1ee7ae278c2aafaf51@haskell.org> #15275: AArch64 validation fails with many invalid relocations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tmobile): * cc: tmobile (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 19:18:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 19:18:36 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.2b0b186972a1144787511b422b6f328f@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Pinging vdukhovni. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 19:22:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 19:22:43 -0000 Subject: [GHC] #15448: Allow execution of stage2 compiler to happen later Message-ID: <046.bd85e8817bc05231fb5e46624aaf2bd9@haskell.org> #15448: Allow execution of stage2 compiler to happen later -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14949 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently cross-compiled bindists are rather incomplete since we can't run the stage2 compiler to build various utilities (e.g. `hp2ps` and `haddock`). Ideally we would be able to run a build up to the point where we need to run host code, package up the build tree, and finish the build on the host. There are a number of challenges that this brings, but it will ultimately make it far easier to build proper non-Linux/amd64 bindists on CircleCI (#14949). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 19:23:08 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 19:23:08 -0000 Subject: [GHC] #14949: Perform builds on non-Debian-based systems on Circle CI In-Reply-To: <045.268e746ab76f9908ab62816b8881cd4a@haskell.org> References: <045.268e746ab76f9908ab62816b8881cd4a@haskell.org> Message-ID: <060.dd2d37ec4289982827810259d73f78dc@haskell.org> #14949: Perform builds on non-Debian-based systems on Circle CI -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: mrkkrp Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.2 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15448 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #15448 Comment: #15448 is relevant to this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 20:14:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 20:14:54 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 Message-ID: <046.a39037510433715ab5f0873fb73e977c@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: aarch64 | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC releases 8.2.1 through 8.4.3 exhibit various crashes when invoked with '-jn' where n > 1. GHCHQ's binary releases have this behavior, as well as GHCs I've cross-built on my own. In order to reproduce this issue there must be some parallelism in the module dependency graph; I've attached a test package for easily reproducing this. Use of deriving in the test modules isn't necessary to trigger this; it merely gives the compiler some work to do. The 'hscolour' package also triggers this issue reliably. To trigger the bad behavior, simply run: ghc --make -jn Main.hs -o test with n > 1 in the test-package. Running this repeatedly (removing .hi and .o files in between runs, of course), I've observed these outcomes with varying frequencies: - Segmentation fault. - Bus fault. - Compiler process sleeps indefinitely. - {{{ : error: ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for aarch64-unknown-linux): Binary.UserData: no put_binding_name }}} - {{{ ghc: internal error: MUT_VAR_CLEAN object entered! (GHC version 8.4.3 for aarch64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} - And most strangely: {{{ A.hs:3:1: error: • Kind signature on data type declaration has non-* return kind * • In the data declaration for ‘A’ | 3 | data A = A | ^^^^^^^^^^... }}} I have not noticed issues with any other concurrent Haskell programs on aarch64. I'm using the NVIDIA Jetson TX2 for these tests. I have not yet tried GHC 8.0.x, 8.6.x, or HEAD. I'm having trouble reproducing this in GDB; I'll report back when I've got that working. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 20:17:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 20:17:10 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.93fe6d88c0ace2514af94a2d4139d77e@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tmobile): * Attachment "test-package.tar.bz2" added. Test source files -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 20:22:51 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 20:22:51 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.48b87d912c639bb7fa6f9bdd316324c7@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tmobile): Attaching GDB to a hung GHC, looks like it's just stuck on a futex: {{{ #0 0x0000007fa5459100 in futex_wait_cancelable (private=, expected=0, futex_word=0x60939c) at ../sysdeps/unix/sysv/linux/futex- internal.h:88 #1 __pthread_cond_wait_common (abstime=0x0, mutex=0x6093a0, cond=0x609370) at pthread_cond_wait.c:502 #2 __pthread_cond_wait (cond=0x609370, mutex=0x6093a0) at pthread_cond_wait.c:655 #3 0x0000007fa56815e8 in waitCondition () from /nix/store /dcwj7hvxgzqj7kbmfklqh4kg635ra7pk-ghc-8.4.3-binary-aarch64/lib/aarch64 -unknown-linux-gnu-ghc-8.4.3/bin/../rts/libHSrts_thr-ghc8.4.3.so Backtrace stopped: previous frame identical to this frame (corrupt stack?) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 20:55:17 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 20:55:17 -0000 Subject: [GHC] #13766: Confusing "redundant pattern match" in 8.0, no warning at all in 8.2 In-Reply-To: <044.a0d4ddde4ac467954a614a3fdf55fb65@haskell.org> References: <044.a0d4ddde4ac467954a614a3fdf55fb65@haskell.org> Message-ID: <059.9b5362fdbe6fcbe0c1eb88ef718d80e2@haskell.org> #13766: Confusing "redundant pattern match" in 8.0, no warning at all in 8.2 -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12466, #11066, | Differential Rev(s): #12694 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => PatternMatchWarnings * related: => #12466, #11066, #12694 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 20:55:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 20:55:38 -0000 Subject: [GHC] #12694: GHC HEAD no longer reports inaccessible code In-Reply-To: <045.5b8927bc68b32eb0c009890144074b13@haskell.org> References: <045.5b8927bc68b32eb0c009890144074b13@haskell.org> Message-ID: <060.5029ab5295ce3b5e1caf063bf25b6a79@haskell.org> #12694: GHC HEAD no longer reports inaccessible code -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12466, #11066, | Differential Rev(s): #13766 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => PatternMatchWarnings * related: => #12466, #11066, #13766 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 20:57:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 20:57:50 -0000 Subject: [GHC] #12694: GHC HEAD no longer reports inaccessible code In-Reply-To: <045.5b8927bc68b32eb0c009890144074b13@haskell.org> References: <045.5b8927bc68b32eb0c009890144074b13@haskell.org> Message-ID: <060.af654dd7c899b4d8a08a291e3f562fc5@haskell.org> #12694: GHC HEAD no longer reports inaccessible code -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12466, #11066, | Differential Rev(s): #13766 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It seems that GHC 8.2 and later report this as inaccessible code again: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs [1 of 1] Compiling A ( Bug.hs, Bug.o ) Bug.hs:4:7: error: • Could not deduce: a ~ b from the context: Bool ~ Int bound by the type signature for: f :: forall a b. (Bool ~ Int) => a -> b at Bug.hs:3:1-25 ‘a’ is a rigid type variable bound by the type signature for: f :: forall a b. (Bool ~ Int) => a -> b at Bug.hs:3:1-25 ‘b’ is a rigid type variable bound by the type signature for: f :: forall a b. (Bool ~ Int) => a -> b at Bug.hs:3:1-25 • In the expression: x In an equation for ‘f’: f x = x • Relevant bindings include x :: a (bound at Bug.hs:4:3) f :: a -> b (bound at Bug.hs:4:1) | 4 | f x = x | ^ }}} Perhaps this can be closed, then? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 21:02:30 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 21:02:30 -0000 Subject: [GHC] #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 In-Reply-To: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> References: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> Message-ID: <060.aa8821b98b99f87c83f47ed5c6aaf00b@haskell.org> #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 -------------------------------+-------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by bgamari): * cc: angerman (added) Comment: I suspect that the reason this happens after repeated loads is that we probably link every object compiled so far in the session into each new object. Afterall, the user's entered expression may refer to anything the user previously entered. CCing angerman who has thought more about how to deal with this limitation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 21:25:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 21:25:06 -0000 Subject: [GHC] #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions In-Reply-To: <050.6a9e69a1ab3df132884705211545628c@haskell.org> References: <050.6a9e69a1ab3df132884705211545628c@haskell.org> Message-ID: <065.ec56ae9fb9838fef25e4f704abdbd969@haskell.org> #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"754c3a55a603b155fa5d9a282de73d41a4694ffc/ghc" 754c3a5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="754c3a55a603b155fa5d9a282de73d41a4694ffc" Fix Ar crashing on odd-sized object files (Trac #15396) Summary: All the work was done by Moritz Angermann. Test Plan: validate Reviewers: angerman, RyanGlScott, bgamari Reviewed By: angerman Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15396 Differential Revision: https://phabricator.haskell.org/D5013 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 21:49:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 21:49:10 -0000 Subject: [GHC] #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions In-Reply-To: <050.6a9e69a1ab3df132884705211545628c@haskell.org> References: <050.6a9e69a1ab3df132884705211545628c@haskell.org> Message-ID: <065.6ac5197741539924e1f8cbba3f84f63f@haskell.org> #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 22:24:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 22:24:16 -0000 Subject: [GHC] #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 In-Reply-To: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> References: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> Message-ID: <060.ba8922d31fd6a7d6d387d4f5e6f07390@haskell.org> #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 -------------------------------+-------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by George): In that case, it sounds like this would be an issue for any language with a repl (read eval print loop) that allows you to load dynamic libraries.e.g. Lisp and maybe even Swift? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jul 27 23:18:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 27 Jul 2018 23:18:13 -0000 Subject: [GHC] #15340: Investigate using Ward on RTS In-Reply-To: <046.17517c0d14ed055045d9c0a9bfaad364@haskell.org> References: <046.17517c0d14ed055045d9c0a9bfaad364@haskell.org> Message-ID: <061.1642ddd60b1f60c76be74c146716961f@haskell.org> #15340: Investigate using Ward on RTS -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): There are many many things which I would like to have statically checked that in principle Ward is capable of: * Verifying that callers into the GC have a valid `gc_thread` declaration in scope (since it may be a `register` variable) * `SM_LOCK` checking * `linker_lock` checking * Capability possession checking -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 00:28:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 00:28:14 -0000 Subject: [GHC] #15415: GHCi's :kind doesn't work with wildcards In-Reply-To: <047.9324d649243992c743ffcce486b06b5a@haskell.org> References: <047.9324d649243992c743ffcce486b06b5a@haskell.org> Message-ID: <062.1da62544389578ec5c52c4a4741651d4@haskell.org> #15415: GHCi's :kind doesn't work with wildcards -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): No, I haven't started this implementation. I'd be grateful to turn it over to you. It shouldn't be hard -- it's essentially just removing code. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 00:46:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 00:46:25 -0000 Subject: [GHC] #15441: Data type with phantoms using TypeInType isn't coercible In-Reply-To: <051.c0b9407ab0ec784876ce6e4509034b58@haskell.org> References: <051.c0b9407ab0ec784876ce6e4509034b58@haskell.org> Message-ID: <066.71c272b3bc50dd3b1d0afc0d6ff5d4ac@haskell.org> #15441: Data type with phantoms using TypeInType isn't coercible -------------------------------------+------------------------------------- Reporter: glittershark | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Roles Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => Roles Comment: That looks even more suspect -- my guess is that inferring a phantom there wouldn't be sound. Hopefully we'll have a worked out theory for roles and dependency in the next few months (there's active work going on here), but we're not there yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 06:31:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 06:31:50 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.90604102b75ee7c6688b9290643f9907@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Changes (by vdukhovni): * Attachment "0001-Enable-two-step-allocator-on-FreeBSD.patch" added. FreeBSD patch for master (git am format) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 06:34:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 06:34:31 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.cb67947c138417f1151c174a33ddb90b@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Comment (by vdukhovni): Updated patch attached. (Further questions/comments would be best via direct email, I don't seem to have notifications enabled here) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 08:27:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 08:27:15 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.51a72c87539ee8ed2de6af8ae480ca08@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): At some point Aarch64 was switched over from the C backend to the LLVM backend. A quick glance at the LLVM backend showed the following suspicious code in `compiler/llvmGen/LlvmCodeGen`: {{{ genCall (PrimTarget (MO_AtomicRead _)) [dst] [addr] = runStmtsDecls $ do dstV <- getCmmRegW (CmmLocal dst) v1 <- genLoadW True addr (localRegType dst) statement $ Store v1 dstV }}} A full barrier is required here but no barrier at all is present. Remark: I have similar issues on PowerPC and putting the appropriate barrier into atomic reads improved the situation (fewer crashes of the sort described above) but did not solve the issue completely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 12:01:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 12:01:03 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.5909238873e667744f692bb987d2060e@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 12:33:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 12:33:17 -0000 Subject: [GHC] #14887: Explicitly quantifying a kind variable causes a telescope to fail to kind-check In-Reply-To: <050.26e9faa4d4a29b625c8bfcdef0d31364@haskell.org> References: <050.26e9faa4d4a29b625c8bfcdef0d31364@haskell.org> Message-ID: <065.efbd258d70f35c24568ede689769902d@haskell.org> #14887: Explicitly quantifying a kind variable causes a telescope to fail to kind- check -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 12:34:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 12:34:09 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.3903d79f38d87cf8fb7a90f85d459607@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 12:36:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 12:36:43 -0000 Subject: [GHC] #13607: Panic when shared object file is missing: Dynamic linker not initialised In-Reply-To: <050.42a412821545515fa30e9fa080a5d0f2@haskell.org> References: <050.42a412821545515fa30e9fa080a5d0f2@haskell.org> Message-ID: <065.1710bc4078389027036e5587c6899f4e@haskell.org> #13607: Panic when shared object file is missing: Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #9868, #10355, | Differential Rev(s): Phab:D5012 #10919, #13137, #13531 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5012 * related: => #9868, #10355, #10919, #13137, #13531 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 12:37:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 12:37:37 -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.bfae5411b187fc9148844f604886c489@haskell.org> #10919: ghc: panic! (the 'impossible' happened) ... Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: recursion-ninja | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: worksforme | 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: #9868, #10355, | Differential Rev(s): #13137, #13531, #13607 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #9868, #10355, #13137, #13531, #13607 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 12:38:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 12:38:56 -0000 Subject: [GHC] #13531: GHC fails with "Dynamic linker not initialised" when -j is on and trying to load nonexistent .so file In-Reply-To: <042.f97bf302ed95b0f9a174910a7d6a0986@haskell.org> References: <042.f97bf302ed95b0f9a174910a7d6a0986@haskell.org> Message-ID: <057.fa0555569c812bea0f3967d299be3556@haskell.org> #13531: GHC fails with "Dynamic linker not initialised" when -j is on and trying to load nonexistent .so file -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13137, #9868, | Differential Rev(s): Phab:D5012 #10355, #13607, #10919 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5012 * related: #13137, #9868, #10355, #13607 => #13137, #9868, #10355, #13607, #10919 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 12:39:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 12:39:52 -0000 Subject: [GHC] #13137: Dynamic linker not initialised. In-Reply-To: <045.40f0726ebefc735f7ea0c8f42d81dbc6@haskell.org> References: <045.40f0726ebefc735f7ea0c8f42d81dbc6@haskell.org> Message-ID: <060.360427c6736e31949bc266dab180e333@haskell.org> #13137: Dynamic linker not initialised. -------------------------------------+------------------------------------- Reporter: djduke | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9868, #10355, | Differential Rev(s): Phab:D5012 #10919, #13531, #13607 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5012 * related: => #9868, #10355, #10919, #13531, #13607 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 12:41:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 12:41:16 -0000 Subject: [GHC] #10355: Dynamic linker not initialised In-Reply-To: <046.b020405a0b5eb69acc1047433b42d151@haskell.org> References: <046.b020405a0b5eb69acc1047433b42d151@haskell.org> Message-ID: <061.1b8623ba733dfe96dfb9a77ecca3ce3b@haskell.org> #10355: Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: dpiponi | Owner: (none) Type: bug | Status: patch 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, #10919, | Differential Rev(s): Phab:D5012 #13137, #13531, #13607 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: infoneeded => patch * differential: => Phab:D5012 * related: #9868, #10919 => #9868, #10919, #13137, #13531, #13607 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 12:41:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 12:41:51 -0000 Subject: [GHC] #9868: ghc: panic! Dynamic linker not initialised In-Reply-To: <046.5f3f9e960e287bc6e82a07e7ce17a8b6@haskell.org> References: <046.5f3f9e960e287bc6e82a07e7ce17a8b6@haskell.org> Message-ID: <061.bbb0040a467a1a57ee86ff0d53a35fa3@haskell.org> #9868: ghc: panic! Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: Jamedjo | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #10355, #10919, | Differential Rev(s): Phab:D5012 #13137, #13531, #13607 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5012 * related: => #10355, #10919, #13137, #13531, #13607 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 13:08:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 13:08:31 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.99d0ee7d5b3ffd3a918556fa0981146e@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059, #10431, | Differential Rev(s): Phab:D4876 #14316 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): An update on this ticket. It seems that the only remaining thing here is to wire in an appropriately low fixity for `(~)` (and `(~~)`, which GHC introduced after the creation of this ticket). As it turns out, this part is way, way easier than I originally thought. This patch suffices, in fact: {{{#!diff diff --git a/compiler/rename/RnFixity.hs b/compiler/rename/RnFixity.hs index f1bfb38..05d1b89 100644 --- a/compiler/rename/RnFixity.hs +++ b/compiler/rename/RnFixity.hs @@ -27,6 +27,8 @@ import Maybes import Data.List import Data.Function ( on ) import RnUnbound +import PrelNames ( eqTyConKey, heqTyConKey ) +import Unique {- ********************************************************* @@ -124,6 +126,9 @@ lookupFixityRn_help' name occ -- a>0 `foo` b>0 -- where 'foo' is not in scope, should not give an error (Trac #7937) + | name `hasKey` eqTyConKey || name `hasKey` heqTyConKey + = pure (True, Fixity NoSourceText (-2) InfixN) + | otherwise = do { local_fix_env <- getFixityEnv ; case lookupNameEnv local_fix_env name of { diff --git a/testsuite/tests/ghci/scripts/T10059.stdout b/testsuite/tests/ghci/scripts/T10059.stdo index 92fbb45..854f52a 100644 --- a/testsuite/tests/ghci/scripts/T10059.stdout +++ b/testsuite/tests/ghci/scripts/T10059.stdout @@ -1,4 +1,6 @@ class (a ~ b) => (~) (a :: k0) (b :: k0) -- Defined in ‘GHC.Types’ +infix -2 ~ (~) :: k0 -> k0 -> Constraint class (a GHC.Prim.~# b) => (~) (a :: k0) (b :: k0) -- Defined in ‘GHC.Types’ +infix -2 ~ }}} I'm giving this a precedence of -2, since in #15235, we decided to give `(->)` a precedence of -1, and the consensus in this ticket is that `(~)`/`(~~)` should have a lower precedence than everything else. Unfortunately, things are never as simple as they appear. Even with this patch, `(->)` will //still// have a lower precedence than `(~)` in practice. Why? Because saying that `(->)` has a precedence of -1 is a bit of a lie; in reality, it has a precedence closer to -∞, since `(->)` has special treatment in the parser, which causes it to bind more tightly than it ought to. Note that `(~)` is also treated specially in the parser, but there is a post-parsing pass which flattens uses of `(~)` to appear as ordinary type operators. Perhaps we should extend this treatment to `(->)` as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 15:11:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 15:11:30 -0000 Subject: [GHC] #15450: Inconsistency w.r.t. coverage checking warnings for EmptyCase under unsatisfiable constraints Message-ID: <050.a778e3d607f09b5ab14f992506aa831f@haskell.org> #15450: Inconsistency w.r.t. coverage checking warnings for EmptyCase under unsatisfiable constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple PatternMatchWarnings | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: #12957 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs {-# LANGUAGE EmptyCase #-} {-# LANGUAGE GADTs #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Bug where f :: (Int ~ Bool) => Bool -> a f x = case x of {} g :: (Int ~ Bool) => Bool -> a g x = case x of True -> undefined }}} {{{ $ /opt/ghc/8.4.3/bin/ghci Bug.hs GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:10:7: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: False | 10 | g x = case x of True -> undefined | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Observe that we get a non-exhaustivity warning for the `case` expression in `g` (thanks to commit adb565aa74582969bbcc3b411d6d518b1c76c3cf), but not for the one in `f`. The difference is that `f` uses `EmptyCase`, whereas `g` does not, and the codepath for `EmptyCase` is unfortunately incongruous with the codepath for other coverage checking. I know how to fix this. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 15:18:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 15:18:35 -0000 Subject: [GHC] #15450: Inconsistency w.r.t. coverage checking warnings for EmptyCase under unsatisfiable constraints In-Reply-To: <050.a778e3d607f09b5ab14f992506aa831f@haskell.org> References: <050.a778e3d607f09b5ab14f992506aa831f@haskell.org> Message-ID: <065.ace95edeb01402e1bd3ee413965b033c@haskell.org> #15450: Inconsistency w.r.t. coverage checking warnings for EmptyCase under unsatisfiable constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #12957 | Differential Rev(s): Phab:D5017 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5017 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 15:47:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 15:47:10 -0000 Subject: [GHC] #15451: Fix Git commit ID detection in worktrees Message-ID: <045.784f11b7dc6e141f133275a8c4f2c98c@haskell.org> #15451: Fix Git commit ID detection in worktrees -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D5016 | Wiki Page: -------------------------------------+------------------------------------- When using a Git worktree, ".git" is a file, not a directory, hence "configure" doesn't detect it correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 15:47:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 15:47:51 -0000 Subject: [GHC] #15451: Fix Git commit ID detection in worktrees In-Reply-To: <045.784f11b7dc6e141f133275a8c4f2c98c@haskell.org> References: <045.784f11b7dc6e141f133275a8c4f2c98c@haskell.org> Message-ID: <060.20d18ea6b05b40c9e022c5d0887f1b00@haskell.org> #15451: Fix Git commit ID detection in worktrees -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5016 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 15:49:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 15:49:58 -0000 Subject: [GHC] #15451: Fix Git commit ID detection in worktrees In-Reply-To: <045.784f11b7dc6e141f133275a8c4f2c98c@haskell.org> References: <045.784f11b7dc6e141f133275a8c4f2c98c@haskell.org> Message-ID: <060.eefd6e36e6ff7c30c00f4692dc26b978@haskell.org> #15451: Fix Git commit ID detection in worktrees -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5016 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 16:18:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 16:18:16 -0000 Subject: [GHC] #9936: Data.Fixed truncates 5.17 to 5.16 In-Reply-To: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> References: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> Message-ID: <064.b047a2590cf203ba64fe22449e123e0a@haskell.org> #9936: Data.Fixed truncates 5.17 to 5.16 -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9231, #9240 | Differential Rev(s): Phab:D1693 Wiki Page: | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 16:27:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 16:27:37 -0000 Subject: [GHC] #11261: Implement DWARF debugging on powerpc64 In-Reply-To: <047.fcb308b656617448e39264eeafa29658@haskell.org> References: <047.fcb308b656617448e39264eeafa29658@haskell.org> Message-ID: <062.097e2692a3cdfaf167d0162c31c43821@haskell.org> #11261: Implement DWARF debugging on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: debug, at runtime | T10667, | simplCore/should_compile/T13658 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by admock): What's required to add this? I'd like to get this working to make the other powerpc64 issues easier to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 16:36:33 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 16:36:33 -0000 Subject: [GHC] #11261: Implement DWARF debugging on powerpc64 In-Reply-To: <047.fcb308b656617448e39264eeafa29658@haskell.org> References: <047.fcb308b656617448e39264eeafa29658@haskell.org> Message-ID: <062.63c14ca7dd276e891989be07bd7dbefc@haskell.org> #11261: Implement DWARF debugging on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: debug, at runtime | T10667, | simplCore/should_compile/T13658 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by admock): * cc: admock (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 19:02:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 19:02:57 -0000 Subject: [GHC] #15452: [GHCi] Add an option to make tab completion case-insensitive Message-ID: <042.e19bc5965f01d3bb604f52b64d092670@haskell.org> #15452: [GHCi] Add an option to make tab completion case-insensitive -------------------------------------+------------------------------------- Reporter: f-a | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There should be a ghci-option to have {{{ λ> readf }}} (notice the lowercase `f`) complete to {{{ λ> readFile }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 19:05:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 19:05:17 -0000 Subject: [GHC] #15452: [GHCi] Add an option to make tab completion case-insensitive In-Reply-To: <042.e19bc5965f01d3bb604f52b64d092670@haskell.org> References: <042.e19bc5965f01d3bb604f52b64d092670@haskell.org> Message-ID: <057.9f28b75e05d3ff748e9ea7064f050824@haskell.org> #15452: [GHCi] Add an option to make tab completion case-insensitive -------------------------------------+------------------------------------- Reporter: f-a | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by f-a): I have sent a patch to the maintainer of `haskeline` which would allow this (ci-autocomplete) to be implemented in ghci, but I still have to hear from him. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 19:48:41 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 19:48:41 -0000 Subject: [GHC] #15453: Bug in opt_trans_rule in OptCoercion Message-ID: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> #15453: Bug in opt_trans_rule in OptCoercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The ForAllCo case in the definition of opt_trans_rule in OptCoercion is not right: {{{#!hs push_trans tv1 eta1 r1 tv2 eta2 r2 = fireTransRule "EtaAllTy" co1 co2 $ mkForAllCo tv1 (opt_trans is eta1 eta2) (opt_trans is' r1 r2') where is' = is `extendInScopeSet` tv1 r2' = substCoWithUnchecked [tv2] [TyVarTy tv1] r2 -- ill-kinded! }}} Given {{{co1;co2}}}, where {{{#!hs co1 = \/ tv1 : eta1. r1 co2 = \/ tv2 : eta2. r2 }}} We would like optimize the transitivity coercion. I think what we want is {{{#!hs \/tv1 : (eta1;eta2). (r1; r2[tv2 |-> tv1 |> eta1]) }}} Namely it should be {{{#!hs r2' = substCoWithUnchecked [tv2] [mkCastTy (TyVarTy tv1) eta1] r2 }}} If there is any program that could hit the bug it would be better, as we can add it to test cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 19:50:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 19:50:19 -0000 Subject: [GHC] #15453: Bug in opt_trans_rule in OptCoercion In-Reply-To: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> References: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> Message-ID: <062.d38c3e1e6524f64d6725c363f16d592f@haskell.org> #15453: Bug in opt_trans_rule in OptCoercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ningning): * owner: (none) => ningning -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 20:06:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 20:06:35 -0000 Subject: [GHC] #15453: Bug in opt_trans_rule in OptCoercion In-Reply-To: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> References: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> Message-ID: <062.c0c959d97047111123465537b8f0f0b2@haskell.org> #15453: Bug in opt_trans_rule in OptCoercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ningning): * milestone: 8.6.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 21:05:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 21:05:23 -0000 Subject: [GHC] #15454: Have GHCi automatically use -fobject-code for modules that use UnboxedTuples Message-ID: <046.9b666c82251616f1d78d961f028abb97@haskell.org> #15454: Have GHCi automatically use -fobject-code for modules that use UnboxedTuples -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is related to a relatively old issue, that the bytecode interpreter cannot handle UnboxedTuples: https://ghc.haskell.org/trac/ghc/ticket/1257 . Rather than fix that issue, which sounds quite challenging, how about adding some automagic to GHCi which builds object code for modules that use UnboxedTuples? This is a bit trickier than just compiling those modules to object code, because object code cannot be linked against byte code (see https://ghc.haskell.org/trac/ghc/ticket/10965). A potential solution to this is to also build all of the dependencies of modules that use UnboxedTuples using object code. This idea has some precedent, though as an external script - see https://ghc.haskell.org/trac/ghc/ticket/13101 and https://gist.github.com/bgamari/bd53e4fd6f3323599387ffc7b11d1a1e . I think it would be best to put the solution to this directly in GHCi. What do you think? If y'all think it is a good idea, then I can volunteer to try to make it happen. As described in that ticket, this would be particularly helpful for loading GHC into GHCi, because GHC's code uses UnboxedTuples. Currently, `-fobject-code` must be used, which means that the speedup from using GHCi isn't quite as much as it could be. It is possible to get around this by first loading it with object code and then doing another load without object code, but that's rather inconvenient. Since this may be a surprising behavior change (the user may not have specified -odir and -hidir), it could possibly be enabled via a flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 21:27:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 21:27:50 -0000 Subject: [GHC] #15453: Bug in opt_trans_rule in OptCoercion In-Reply-To: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> References: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> Message-ID: <062.28e377e4a4336c561e223c64507603c0@haskell.org> #15453: Bug in opt_trans_rule in OptCoercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I managed to construct program which throws a Core Lint error that (I believe) is caused by this bug: {{{#!hs {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Kind import Data.Proxy import Data.Type.Equality type family S :: Type where S = T type family T :: Type where T = Int f :: (forall (x :: S). Proxy x) :~: (forall (x :: T). Proxy x) f = Refl g :: (forall (x :: T). Proxy x) :~: (forall (x :: Int). Proxy x) g = Refl h :: (forall (x :: S). Proxy x) :~: (forall (x :: Int). Proxy x) h = f `trans` g }}} {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 Bug.hs -dcore-lint -O1 -fforce- recomp [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of Simplifier *** Bug.hs:25:1: warning: [RHS of h :: (forall (x :: S). Proxy (x |> D:R:S[0] ; D:R:T[0])) :~: (forall (x :: Int). Proxy x)] From-kind of Cast differs from kind of enclosed type From-kind: T Kind of enclosed type: S Actual enclosed type: x_a1i3 Coercion used in cast: D:R:T[0] *** Offending Program *** f :: (forall (x :: S). Proxy (x |> D:R:S[0] ; D:R:T[0])) :~: (forall (x :: T). Proxy (x |> D:R:T[0])) [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] f = ($WRefl @ * @ (forall (x :: S). Proxy (x |> D:R:S[0] ; D:R:T[0]))) `cast` (((:~:) <*>_N D:R:S[0] ; D:R:T[0])>_N (forall (x :: (D:R:S[0] ; D:R:T[0]) ; Sym (D:R:T[0])). D:R:S[0] ; D:R:T[0])>_N))_R :: ((forall (x :: S). Proxy (x |> D:R:S[0] ; D:R:T[0])) :~: (forall (x :: S). Proxy (x |> D:R:S[0] ; D:R:T[0]))) ~R# ((forall (x :: S). Proxy (x |> D:R:S[0] ; D:R:T[0])) :~: (forall (x :: T). Proxy (x |> Sym ((D:R:S[0] ; D:R:T[0]) ; Sym (D:R:T[0])) ; (D:R:S[0] ; D:R:T[0]))))) g :: (forall (x :: T). Proxy (x |> D:R:T[0])) :~: (forall (x :: Int). Proxy x) [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] g = ($WRefl @ * @ (forall (x :: T). Proxy (x |> D:R:T[0]))) `cast` (((:~:) <*>_N D:R:T[0])>_N (forall (x :: D:R:T[0]). D:R:T[0])>_N))_R :: ((forall (x :: T). Proxy (x |> D:R:T[0])) :~: (forall (x :: T). Proxy (x |> D:R:T[0]))) ~R# ((forall (x :: T). Proxy (x |> D:R:T[0])) :~: (forall (x :: Int). Proxy x))) h :: (forall (x :: S). Proxy (x |> D:R:S[0] ; D:R:T[0])) :~: (forall (x :: Int). Proxy x) [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] h = ($WRefl @ * @ (forall (x :: S). Proxy (x |> D:R:S[0] ; D:R:T[0]))) `cast` (((:~:) <*>_N D:R:S[0] ; D:R:T[0])>_N (forall (x :: D:R:S[0] ; D:R:T[0]). D:R:T[0])>_N))_R :: ((forall (x :: S). Proxy (x |> D:R:S[0] ; D:R:T[0])) :~: (forall (x :: S). Proxy (x |> D:R:T[0]))) ~R# ((forall (x :: S). Proxy (x |> D:R:S[0] ; D:R:T[0])) :~: (forall (x :: Int). Proxy x))) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 21:37:41 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 21:37:41 -0000 Subject: [GHC] #15189: Avoid word "transformer" in the documentation of ST In-Reply-To: <051.babfb617b882c0b638e02ac50b14cd85@haskell.org> References: <051.babfb617b882c0b638e02ac50b14cd85@haskell.org> Message-ID: <066.2c3819b8df874de56774186a464220c7@haskell.org> #15189: Avoid word "transformer" in the documentation of ST -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: ulysses4ever Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Documentation | Version: 8.2.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 ulysses4ever): Sorry for being so slow. Please, review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 21:38:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 21:38:39 -0000 Subject: [GHC] #15189: Avoid word "transformer" in the documentation of ST In-Reply-To: <051.babfb617b882c0b638e02ac50b14cd85@haskell.org> References: <051.babfb617b882c0b638e02ac50b14cd85@haskell.org> Message-ID: <066.8d50cee7d3e6c68e78c3844b516aca32@haskell.org> #15189: Avoid word "transformer" in the documentation of ST -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: ulysses4ever Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Documentation | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5019 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ulysses4ever): * differential: => Phab:D5019 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 21:39:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 21:39:16 -0000 Subject: [GHC] #15455: Memory usage when compiling jsaddle-dom exploded in 8.4.3 Message-ID: <046.e653d9fec09649e1b4a200e6da1c2507@haskell.org> #15455: Memory usage when compiling jsaddle-dom exploded in 8.4.3 -------------------------------------+------------------------------------- Reporter: eskimor | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling jsaddle-dom (the JSDOM.Types module in particular) requires quite a lot of memory on 8.2.2 already, but with 8.4.3 I am no longer able to compile it at all with 8 GB of RAM. At first I thought it could be related to https://ghc.haskell.org/trac/ghc/ticket/15304 but passing "-fno-worker-wrapper" does not seem to make much of a difference, therefore it might me a different cause here. Reproduce: git clone git at github.com:ghcjs/jsaddle-dom.git cd jsaddle-dom sed -i 's/? "default"/? "ghc843"/1' shell.nix nix-shell cabal new-build -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 21:39:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 21:39:53 -0000 Subject: [GHC] #15455: Memory usage when compiling jsaddle-dom exploded in 8.4.3 In-Reply-To: <046.e653d9fec09649e1b4a200e6da1c2507@haskell.org> References: <046.e653d9fec09649e1b4a200e6da1c2507@haskell.org> Message-ID: <061.8b60f2c09bbe8a62ac276242cc18f943@haskell.org> #15455: Memory usage when compiling jsaddle-dom exploded in 8.4.3 -------------------------------------+------------------------------------- Reporter: eskimor | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by eskimor: Old description: > Compiling jsaddle-dom (the JSDOM.Types module in particular) requires > quite a lot of memory on 8.2.2 already, but with 8.4.3 I am no longer > able to compile it at all with 8 GB of RAM. At first I thought it could > be related to > > https://ghc.haskell.org/trac/ghc/ticket/15304 > > but passing "-fno-worker-wrapper" does not seem to make much of a > difference, therefore it might me a different cause here. > > Reproduce: > > git clone git at github.com:ghcjs/jsaddle-dom.git > cd jsaddle-dom > sed -i 's/? "default"/? "ghc843"/1' shell.nix > nix-shell > cabal new-build New description: Compiling jsaddle-dom (the JSDOM.Types module in particular) requires quite a lot of memory on 8.2.2 already, but with 8.4.3 I am no longer able to compile it at all with 8 GB of RAM. At first I thought it could be related to https://ghc.haskell.org/trac/ghc/ticket/15304 but passing "-fno-worker-wrapper" does not seem to make much of a difference, therefore it might me a different cause here. Reproduce: git clone git at github.com:ghcjs/jsaddle-dom.git cd jsaddle-dom sed -i 's/? "default"/? "ghc843"/1' shell.nix nix-shell cabal new-build -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 22:01:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 22:01:08 -0000 Subject: [GHC] #14794: -Weverything should not enable -Wmissing-exported-signatures In-Reply-To: <049.1806d387ab94f5c229447f9562a2a543@haskell.org> References: <049.1806d387ab94f5c229447f9562a2a543@haskell.org> Message-ID: <064.30bc4ea7bacb292c3b9cc525b2a5db51@haskell.org> #14794: -Weverything should not enable -Wmissing-exported-signatures -------------------------------------+------------------------------------- Reporter: MaxGabriel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MaxGabriel): Ah, this is totally unrelated, but to get rid of those safe warnings I believe I just would need `-Wno-safe`. I was trying `-Wno-unsafe` by mistake, before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 22:12:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 22:12:45 -0000 Subject: [GHC] #15453: Bug in opt_trans_rule in OptCoercion In-Reply-To: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> References: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> Message-ID: <062.de688f36ba2070c6fcbbb69c7976bdba@haskell.org> #15453: Bug in opt_trans_rule in OptCoercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ningning): Replying to [comment:3 RyanGlScott]: > I managed to construct program which throws a Core Lint error that (I believe) is caused by this bug: Thanks Ryan! Indeed this is a good example. I will add it to the test cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 22:26:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 22:26:10 -0000 Subject: [GHC] #15453: Bug in opt_trans_rule in OptCoercion In-Reply-To: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> References: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> Message-ID: <062.2a3d116db8f129e999a669101f0c80f2@haskell.org> #15453: Bug in opt_trans_rule in OptCoercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D5018 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ningning): * differential: => D5018 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jul 28 22:26:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 28 Jul 2018 22:26:43 -0000 Subject: [GHC] #15453: Bug in opt_trans_rule in OptCoercion In-Reply-To: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> References: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> Message-ID: <062.eb8f436b7a6d5b4ac6395adfae501597@haskell.org> #15453: Bug in opt_trans_rule in OptCoercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5018 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ningning): * differential: D5018 => Phab:D5018 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 02:40:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 02:40:23 -0000 Subject: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls In-Reply-To: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> References: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> Message-ID: <064.d913fb0ddbf54837a7c1e6e6fa6d5c7d@haskell.org> #14346: 8.2.1 regression: heap corruption after safe foreign calls -------------------------------------+------------------------------------- Reporter: andrewchen | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.4 Component: Compiler | Version: 8.4.3 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:D5020 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: closed => new * differential: => Phab:D5020 * component: Runtime System => Compiler * version: 8.2.1 => 8.4.3 * milestone: 8.4.1 => 8.4.4 * owner: bgamari => (none) * resolution: fixed => Comment: Sadly 404bf05ed3193e918875cd2f6c95ae0da5989be2 never made into HEAD nor GHC 8.4 branch and #14375 hasn't been completed before GHC 8.4 release. Hence HEAD and 8.4.* suffer from this bug (see #15260). I've made a new diff reintroducing the workaround and adding a regression test: Phab:D5020. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 02:45:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 02:45:30 -0000 Subject: [GHC] #15260: Xmobar crashes with segmentation fault In-Reply-To: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> References: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> Message-ID: <061.44b956dbeb22464468ce3050337e0fe3@haskell.org> #15260: Xmobar crashes with segmentation fault ----------------------------------+-------------------------------------- Reporter: Voronwe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by hsyl20): Finally I think this is a duplicate of #14346 because fixing it (again) solves the issue I had in comment:11. Voronwe: You should check if it fixes it for you too. We can close this ticket if it does. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 02:50:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 02:50:42 -0000 Subject: [GHC] #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 In-Reply-To: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> References: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> Message-ID: <060.d0586e0026a6242391c5b78321742de0@haskell.org> #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 -------------------------------+-------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D5021 Wiki Page: | -------------------------------+-------------------------------------- Changes (by angerman): * status: new => patch * differential: => D5021 * milestone: => 8.6.1 Comment: If we modify ghc a bit we essentially get: {{{ *** Linker: gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -Wl,-dead_strip_dylibs -dynamiclib -o /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc28007_0/libghc_4109.dylib c.o -undefined dynamic_lookup -single_module -install_name '@rpath/libghc_4109.dylib' -lghc_4104 -lghc_4099 -lghc_4094 -lghc_4089 -lghc_4084 -lghc_4079 -lghc_4074 -lghc_4069 -lghc_4064 -lghc_4059 -lghc_4054 -lghc_4049 -lghc_4044 -lghc_4039 -lghc_4034 -lghc_4029 -lghc_4024 -lghc_4019 -lghc_4014 -lghc_4009 -lghc_4004 -lghc_3999 -lghc_3994 -lghc_3989 -lghc_3984 -lghc_3979 -lghc_3974 -lghc_3969 -lghc_3964 -lghc_3959 -lghc_3954 -lghc_3949 -lghc_3944 -lghc_3939 -lghc_3934 -lghc_3929 -lghc_3924 -lghc_3919 -lghc_3914 -lghc_3909 -lghc_3904 -lghc_3899 -lghc_3894 -lghc_3889 -lghc_3884 -lghc_3879 -lghc_3874 -lghc_3869 -lghc_3864 -lghc_3859 -lghc_3854 -lghc_3849 -lghc_3844 -lghc_3839 -lghc_3834 -lghc_3829 -lghc_3824 -lghc_3819 -lghc_3814 -lghc_3809 -lghc_3804 -lghc_3799 -lghc_3794 -lghc_3789 -lghc_3784 -lghc_3779 -lghc_3774 -lghc_3769 -lghc_3764 -lghc_3759 -lghc_3754 -lghc_3749 -lghc_3744 -lghc_3739 -lghc_3734 -lghc_3729 -lghc_3724 -lghc_3719 -lghc_3714 -lghc_3709 -lghc_3704 -lghc_3699 -lghc_3694 -lghc_3689 -lghc_3684 -lghc_3679 -lghc_3674 -lghc_3669 -lghc_3664 -lghc_3659 -lghc_3654 -lghc_3649 -lghc_3644 -lghc_3639 -lghc_3634 -lghc_3629 -lghc_3624 -lghc_3619 -lghc_3614 -lghc_3609 -lghc_3604 -lghc_3599 -lghc_3594 -lghc_3589 -lghc_3584 -lghc_3579 -lghc_3574 -lghc_3569 -lghc_3564 -lghc_3559 -lghc_3554 -lghc_3549 -lghc_3544 -lghc_3539 -lghc_3534 -lghc_3529 -lghc_3524 -lghc_3519 -lghc_3514 -lghc_3509 -lghc_3504 -lghc_3499 -lghc_3494 -lghc_3489 -lghc_3484 -lghc_3479 -lghc_3474 -lghc_3469 -lghc_3464 -lghc_3459 -lghc_3454 -lghc_3449 -lghc_3444 -lghc_3439 -lghc_3434 -lghc_3429 -lghc_3424 -lghc_3419 -lghc_3414 -lghc_3409 -lghc_3404 -lghc_3399 -lghc_3394 -lghc_3389 -lghc_3384 -lghc_3379 -lghc_3374 -lghc_3369 -lghc_3364 -lghc_3359 -lghc_3354 -lghc_3349 -lghc_3344 -lghc_3339 -lghc_3334 -lghc_3329 -lghc_3324 -lghc_3319 -lghc_3314 -lghc_3309 -lghc_3304 -lghc_3299 -lghc_3294 -lghc_3289 -lghc_3284 -lghc_3279 -lghc_3274 -lghc_3269 -lghc_3264 -lghc_3259 -lghc_3254 -lghc_3249 -lghc_3244 -lghc_3239 -lghc_3234 -lghc_3229 -lghc_3224 -lghc_3219 -lghc_3214 -lghc_3209 -lghc_3204 -lghc_3199 -lghc_3194 -lghc_3189 -lghc_3184 -lghc_3179 -lghc_3174 -lghc_3169 -lghc_3164 -lghc_3159 -lghc_3154 -lghc_3149 -lghc_3144 -lghc_3139 -lghc_3134 -lghc_3129 -lghc_3124 -lghc_3119 -lghc_3114 -lghc_3109 -lghc_3104 -lghc_3099 -lghc_3094 -lghc_3089 -lghc_3084 -lghc_3079 -lghc_3074 -lghc_3069 -lghc_3064 -lghc_3059 -lghc_3054 -lghc_3049 -lghc_3044 -lghc_3039 -lghc_3034 -lghc_3029 -lghc_3024 -lghc_3019 -lghc_3014 -lghc_3009 -lghc_3004 -lghc_2999 -lghc_2994 -lghc_2989 -lghc_2984 -lghc_2979 -lghc_2974 -lghc_2969 -lghc_2964 -lghc_2959 -lghc_2954 -lghc_2949 -lghc_2944 -lghc_2939 -lghc_2934 -lghc_2929 -lghc_2924 -lghc_2919 -lghc_2914 -lghc_2909 -lghc_2904 -lghc_2899 -lghc_2894 -lghc_2889 -lghc_2884 -lghc_2879 -lghc_2874 -lghc_2869 -lghc_2864 -lghc_2859 -lghc_2854 -lghc_2849 -lghc_2844 -lghc_2839 -lghc_2834 -lghc_2829 -lghc_2824 -lghc_2819 -lghc_2814 -lghc_2809 -lghc_2804 -lghc_2799 -lghc_2794 -lghc_2789 -lghc_2784 -lghc_2779 -lghc_2774 -lghc_2769 -lghc_2764 -lghc_2759 -lghc_2754 -lghc_2749 -lghc_2744 -lghc_2739 -lghc_2734 -lghc_2729 -lghc_2724 -lghc_2719 -lghc_2714 -lghc_2709 -lghc_2704 -lghc_2699 -lghc_2694 -lghc_2689 -lghc_2684 -lghc_2679 -lghc_2674 -lghc_2669 -lghc_2664 -lghc_2659 -lghc_2654 -lghc_2649 -lghc_2644 -lghc_2639 -lghc_2634 -lghc_2629 -lghc_2624 -lghc_2619 -lghc_2614 -lghc_2609 -lghc_2604 -lghc_2599 -lghc_2594 -lghc_2589 -lghc_2584 -lghc_2579 -lghc_2574 -lghc_2569 -lghc_2564 -lghc_2559 -lghc_2554 -lghc_2549 -lghc_2544 -lghc_2539 -lghc_2534 -lghc_2529 -lghc_2524 -lghc_2519 -lghc_2514 -lghc_2509 -lghc_2504 -lghc_2499 -lghc_2494 -lghc_2489 -lghc_2484 -lghc_2479 -lghc_2474 -lghc_2469 -lghc_2464 -lghc_2459 -lghc_2454 -lghc_2449 -lghc_2444 -lghc_2439 -lghc_2434 -lghc_2429 -lghc_2424 -lghc_2419 -lghc_2414 -lghc_2409 -lghc_2404 -lghc_2399 -lghc_2394 -lghc_2389 -lghc_2384 -lghc_2379 -lghc_2374 -lghc_2369 -lghc_2364 -lghc_2359 -lghc_2354 -lghc_2349 -lghc_2344 -lghc_2339 -lghc_2334 -lghc_2329 -lghc_2324 -lghc_2319 -lghc_2314 -lghc_2309 -lghc_2304 -lghc_2299 -lghc_2294 -lghc_2289 -lghc_2284 -lghc_2279 -lghc_2274 -lghc_2269 -lghc_2264 -lghc_2259 -lghc_2254 -lghc_2249 -lghc_2244 -lghc_2239 -lghc_2234 -lghc_2229 -lghc_2224 -lghc_2219 -lghc_2214 -lghc_2209 -lghc_2204 -lghc_2199 -lghc_2194 -lghc_2189 -lghc_2184 -lghc_2179 -lghc_2174 -lghc_2169 -lghc_2164 -lghc_2159 -lghc_2154 -lghc_2149 -lghc_2144 -lghc_2139 -lghc_2134 -lghc_2129 -lghc_2124 -lghc_2119 -lghc_2114 -lghc_2109 -lghc_2104 -lghc_2099 -lghc_2094 -lghc_2089 -lghc_2084 -lghc_2079 -lghc_2074 -lghc_2069 -lghc_2064 -lghc_2059 -lghc_2054 -lghc_2049 -lghc_2044 -lghc_2039 -lghc_2034 -lghc_2029 -lghc_2024 -lghc_2019 -lghc_2014 -lghc_2009 -lghc_2004 -lghc_1999 -lghc_1994 -lghc_1989 -lghc_1984 -lghc_1979 -lghc_1974 -lghc_1969 -lghc_1964 -lghc_1959 -lghc_1954 -lghc_1949 -lghc_1944 -lghc_1939 -lghc_1934 -lghc_1929 -lghc_1924 -lghc_1919 -lghc_1914 -lghc_1909 -lghc_1904 -lghc_1899 -lghc_1894 -lghc_1889 -lghc_1884 -lghc_1879 -lghc_1874 -lghc_1869 -lghc_1864 -lghc_1859 -lghc_1854 -lghc_1849 -lghc_1844 -lghc_1839 -lghc_1834 -lghc_1829 -lghc_1824 -lghc_1819 -lghc_1814 -lghc_1809 -lghc_1804 -lghc_1799 -lghc_1794 -lghc_1789 -lghc_1784 -lghc_1779 -lghc_1774 -lghc_1769 -lghc_1764 -lghc_1759 -lghc_1754 -lghc_1749 -lghc_1744 -lghc_1739 -lghc_1734 -lghc_1729 -lghc_1724 -lghc_1719 -lghc_1714 -lghc_1709 -lghc_1704 -lghc_1699 -lghc_1694 -lghc_1689 -lghc_1684 -lghc_1679 -lghc_1674 -lghc_1669 -lghc_1664 -lghc_1659 -lghc_1654 -lghc_1649 -lghc_1644 -lghc_1639 -lghc_1634 -lghc_1629 -lghc_1624 -lghc_1619 -lghc_1614 -lghc_1609 -lghc_1604 -lghc_1599 -lghc_1594 -lghc_1589 -lghc_1584 -lghc_1579 -lghc_1574 -lghc_1569 -lghc_1564 -lghc_1559 -lghc_1554 -lghc_1549 -lghc_1544 -lghc_1539 -lghc_1534 -lghc_1529 -lghc_1524 -lghc_1519 -lghc_1514 -lghc_1509 -lghc_1504 -lghc_1499 -lghc_1494 -lghc_1489 -lghc_1484 -lghc_1479 -lghc_1474 -lghc_1469 -lghc_1464 -lghc_1459 -lghc_1454 -lghc_1449 -lghc_1444 -lghc_1439 -lghc_1434 -lghc_1429 -lghc_1424 -lghc_1419 -lghc_1414 -lghc_1409 -lghc_1404 -lghc_1399 -lghc_1394 -lghc_1389 -lghc_1384 -lghc_1379 -lghc_1374 -lghc_1369 -lghc_1364 -lghc_1359 -lghc_1354 -lghc_1349 -lghc_1344 -lghc_1339 -lghc_1334 -lghc_1329 -lghc_1324 -lghc_1319 -lghc_1314 -lghc_1309 -lghc_1304 -lghc_1299 -lghc_1294 -lghc_1289 -lghc_1284 -lghc_1279 -lghc_1274 -lghc_1269 -lghc_1264 -lghc_1259 -lghc_1254 -lghc_1249 -lghc_1244 -lghc_1239 -lghc_1234 -lghc_1229 -lghc_1224 -lghc_1219 -lghc_1214 -lghc_1209 -lghc_1204 -lghc_1199 -lghc_1194 -lghc_1189 -lghc_1184 -lghc_1179 -lghc_1174 -lghc_1169 -lghc_1164 -lghc_1159 -lghc_1154 -lghc_1149 -lghc_1144 -lghc_1139 -lghc_1134 -lghc_1129 -lghc_1124 -lghc_1119 -lghc_1114 -lghc_1109 -lghc_1104 -lghc_1099 -lghc_1094 -lghc_1089 -lghc_1084 -lghc_1079 -lghc_1074 -lghc_1069 -lghc_1064 -lghc_1059 -lghc_1054 -lghc_1049 -lghc_1044 -lghc_1039 -lghc_1034 -lghc_1029 -lghc_1024 -lghc_1019 -lghc_1014 -lghc_1009 -lghc_1004 -lghc_999 -lghc_994 -lghc_989 -lghc_984 -lghc_979 -lghc_974 -lghc_969 -lghc_964 -lghc_959 -lghc_954 -lghc_949 -lghc_944 -lghc_939 -lghc_934 -lghc_929 -lghc_924 -lghc_919 -lghc_914 -lghc_909 -lghc_904 -lghc_899 -lghc_894 -lghc_889 -lghc_884 -lghc_879 -lghc_874 -lghc_869 -lghc_864 -lghc_859 -lghc_854 -lghc_849 -lghc_844 -lghc_839 -lghc_834 -lghc_829 -lghc_824 -lghc_819 -lghc_814 -lghc_809 -lghc_804 -lghc_799 -lghc_794 -lghc_789 -lghc_784 -lghc_779 -lghc_774 -lghc_769 -lghc_764 -lghc_759 -lghc_754 -lghc_749 -lghc_744 -lghc_739 -lghc_734 -lghc_729 -lghc_724 -lghc_719 -lghc_714 -lghc_709 -lghc_704 -lghc_699 -lghc_694 -lghc_689 -lghc_684 -lghc_679 -lghc_674 -lghc_669 -lghc_664 -lghc_659 -lghc_654 -lghc_649 -lghc_644 -lghc_639 -lghc_634 -lghc_629 -lghc_624 -lghc_619 -lghc_614 -lghc_609 -lghc_604 -lghc_599 -lghc_594 -lghc_589 -lghc_584 -lghc_579 -lghc_574 -lghc_569 -lghc_564 -lghc_559 -lghc_554 -lghc_549 -lghc_544 -lghc_539 -lghc_534 -lghc_529 -lghc_524 -lghc_519 -lghc_514 -lghc_509 -lghc_504 -lghc_499 -lghc_494 -lghc_489 -lghc_484 -lghc_479 -lghc_474 -lghc_469 -lghc_464 -lghc_459 -lghc_454 -lghc_449 -lghc_444 -lghc_439 -lghc_434 -lghc_429 -lghc_424 -lghc_419 -lghc_414 -lghc_409 -lghc_404 -lghc_399 -lghc_394 -lghc_389 -lghc_384 -lghc_379 -lghc_374 -lghc_369 -lghc_364 -lghc_359 -lghc_354 -lghc_349 -lghc_344 -lghc_339 -lghc_334 -lghc_329 -lghc_324 -lghc_319 -lghc_314 -lghc_309 -lghc_304 -lghc_299 -lghc_294 -lghc_289 -lghc_284 -lghc_279 -lghc_274 -lghc_269 -lghc_264 -lghc_259 -lghc_254 -lghc_249 -lghc_244 -lghc_239 -lghc_234 -lghc_229 -lghc_224 -lghc_219 -lghc_214 -lghc_209 -lghc_204 -lghc_199 -lghc_194 -lghc_189 -lghc_184 -lghc_179 -lghc_174 -lghc_169 -lghc_164 -lghc_159 -lghc_154 -lghc_149 -lghc_144 -lghc_139 -lghc_134 -lghc_129 -lghc_124 -lghc_119 -lghc_114 -lghc_109 -lghc_104 -lghc_99 -lghc_94 -lghc_89 -lghc_84 -lghc_79 -lghc_74 -lghc_69 -lghc_64 -lghc_59 -lghc_54 -lghc_49 -lghc_44 -lghc_39 -lghc_34 -lghc_29 -lghc_24 -lghc_19 -lghc_14 -lghc_9 -lghc_4 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc28007_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc28007_0 -L/Users/angerman/Projects/zw3rk/ghc/libraries/base/dist-install/build -Xlinker -rpath -Xlinker /Users/angerman/Projects/zw3rk/ghc/libraries/base /dist-install/build -L/Users/angerman/Projects/zw3rk/ghc/libraries /integer-gmp/dist-install/build -Xlinker -rpath -Xlinker /Users/angerman/Projects/zw3rk/ghc/libraries/integer-gmp/dist- install/build -L/Users/angerman/Projects/zw3rk/ghc/libraries/ghc-prim /dist-install/build -Xlinker -rpath -Xlinker /Users/angerman/Projects/zw3rk/ghc/libraries/ghc-prim/dist-install/build -L/p/zw3rk/ghc/rts/dist/build -Xlinker -rpath -Xlinker /p/zw3rk/ghc/rts/dist/build -lHSbase-4.12.0.0-ghc8.7.20180728 -lHSinteger- gmp-1.0.2.0-ghc8.7.20180728 -lHSghc-prim-0.5.3-ghc8.7.20180728 -liconv -lgmp -Wl,-dead_strip_dylibs 6 Prelude Main> Prelude Main> Prelude Main> Leaving GHCi. }}} at the end of a slightly modified invocation: {{{ ghc/inplace/bin/ghc-stage2 --interactive -keep-tmp-files -ignore-dot-ghci -fobject-code -v3 -optl-Wl,-dead_strip_dylibs < ghci.sh >& ghci.out & }}} and otool shows: {{{ otool -L /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc28007_0/libghc_4109.dylib /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc28007_0/libghc_4109.dylib: @rpath/libghc_4109.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSbase-4.12.0.0-ghc8.7.20180728.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libHSghc-prim-0.5.3-ghc8.7.20180728.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 03:09:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 03:09:53 -0000 Subject: [GHC] #14329: GHC 8.2.1 segfaults while bootstrapping master In-Reply-To: <046.2503a1f6f14456a42761d49ce89e96f2@haskell.org> References: <046.2503a1f6f14456a42761d49ce89e96f2@haskell.org> Message-ID: <061.e144cfbdd922c9bc9b6cd3de83b69306@haskell.org> #14329: GHC 8.2.1 segfaults while bootstrapping master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12960, #9065, | Differential Rev(s): Phab:D4075 #7762 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): Could be related to #14346 if segfaults of 8.2.1 came back with 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 04:12:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 04:12:23 -0000 Subject: [GHC] #13101: Enable GHC to be loaded into GHCi In-Reply-To: <046.89a8eaf8c834efef8f09f13b000a4227@haskell.org> References: <046.89a8eaf8c834efef8f09f13b000a4227@haskell.org> Message-ID: <061.5f0f46f0330c10a10e7885784ebb0bcb@haskell.org> #13101: Enable GHC to be loaded into GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mgsloan): Now that D4904 and D4986 are merged, there are some scripts to load and run GHC in GHCi with `-fobject-code`. I wrote a blog post about it: http://www.mgsloan.com/posts/ghcinception/ I also opened https://ghc.haskell.org/trac/ghc/ticket/15454 to discuss using an approach similar to Ben's script, but as a general GHCi feature rather than a special purpose script. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 07:37:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 07:37:05 -0000 Subject: [GHC] #11261: Implement DWARF debugging on powerpc64 In-Reply-To: <047.fcb308b656617448e39264eeafa29658@haskell.org> References: <047.fcb308b656617448e39264eeafa29658@haskell.org> Message-ID: <062.41a9b6ba0b19ca91944fc03f7c42a618@haskell.org> #11261: Implement DWARF debugging on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: debug, at runtime | T10667, | simplCore/should_compile/T13658 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:9 admock]: > What's required to add this? I have started work on this two years ago in my github repository [https://github.com/trommler/ghc/tree/T11261]. The issue where I got stuck was that I could not find a way to tell a function label apart from other label types. In the ppc64 ABI a function label is the label of a function descriptor but for debug information I need the label of the function code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 07:39:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 07:39:25 -0000 Subject: [GHC] #11261: Implement DWARF debugging on powerpc64 In-Reply-To: <047.fcb308b656617448e39264eeafa29658@haskell.org> References: <047.fcb308b656617448e39264eeafa29658@haskell.org> Message-ID: <062.0a10fc999ab29e6d13270643c409b288@haskell.org> #11261: Implement DWARF debugging on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: debug, at runtime | T10667, | simplCore/should_compile/T13658 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * owner: trommler => (none) Comment: I have no bandwidth to work on this at the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 07:40:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 07:40:23 -0000 Subject: [GHC] #15260: Xmobar crashes with segmentation fault In-Reply-To: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> References: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> Message-ID: <061.26e6afa15a88f67e3ef060164829d26f@haskell.org> #15260: Xmobar crashes with segmentation fault ----------------------------------+-------------------------------------- Reporter: Voronwe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by osa1): Confirmed that the fix for #14346 (Phab:D5020) fixes this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 07:43:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 07:43:18 -0000 Subject: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls In-Reply-To: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> References: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> Message-ID: <064.33c566f2941b3d892ddedc0c682b3d9c@haskell.org> #14346: 8.2.1 regression: heap corruption after safe foreign calls -------------------------------------+------------------------------------- Reporter: andrewchen | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15260 | Differential Rev(s): Phab:D5020 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * version: 8.4.3 => 8.5 * related: => #15260 * milestone: 8.4.4 => 8.6.1 Comment: This issue seems quite serious to me and it's actually encountered in the wild (see the related ticket). bgamari, can we milestone this for the next release? comment:29 says "correctness issue is resolved for now" but I don't see how. As far as I can see no commits were done for this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 07:47:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 07:47:02 -0000 Subject: [GHC] #14375: Implement with# primop In-Reply-To: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> References: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> Message-ID: <061.dc25fad6dc70fe9eb71f43670b1cde64@haskell.org> #14375: Implement with# primop -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14346 | Differential Rev(s): ​Phab:D4110, Wiki Page: | Phab:D4189 -------------------------------------+------------------------------------- Changes (by osa1): * differential: ​Phab:D4110,Phab:D4189 => ​Phab:D4110, Phab:D4189 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 10:39:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 10:39:08 -0000 Subject: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls In-Reply-To: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> References: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> Message-ID: <064.78f1744b8cbc3b381faf2f039ffcf86c@haskell.org> #14346: 8.2.1 regression: heap corruption after safe foreign calls -------------------------------------+------------------------------------- Reporter: andrewchen | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15260 | Differential Rev(s): Phab:D5020 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): Replying to [comment:31 osa1]: > This issue seems quite serious to me and it's actually encountered in the wild (see the related ticket). bgamari, can we milestone this for the next release? Could we also have a 8.4.4 release? > comment:29 says "correctness issue is resolved for now" but I don't see how. As far as I can see no commits were done for this ticket. It was fixed in 8.2.2: https://git.haskell.org/ghc.git/commitdiff/404bf05ed3193e918875cd2f6c95ae0da5989be2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 11:43:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 11:43:22 -0000 Subject: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls In-Reply-To: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> References: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> Message-ID: <064.c70b6f261678f707ec74ffe1c15d95d3@haskell.org> #14346: 8.2.1 regression: heap corruption after safe foreign calls -------------------------------------+------------------------------------- Reporter: andrewchen | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15260 | Differential Rev(s): Phab:D5020 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > It was fixed in 8.2.2: ​https://git.haskell.org/ghc.git/commitdiff/404bf05ed3193e918875cd2f6c95ae0da5989be2 Ah, I guess the patch was only merged to 8.2.2 branch (not to master). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 12:23:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 12:23:30 -0000 Subject: [GHC] #15453: Bug in opt_trans_rule in OptCoercion In-Reply-To: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> References: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> Message-ID: <062.540792228da2c33026c86574d0a54b53@haskell.org> #15453: Bug in opt_trans_rule in OptCoercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5018 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"11de4380c2f16f374c6e8fbacf8dce00376e7efb/ghc" 11de438/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="11de4380c2f16f374c6e8fbacf8dce00376e7efb" Fix #15453: bug in ForAllCo case in opt_trans_rule Summary: Given ``` co1 = \/ tv1 : eta1. r1 co2 = \/ tv2 : eta2. r2 ``` We would like to optimize `co1; co2` so we push transitivity inside forall. It should be ``` \/tv1 : (eta1;eta2). (r1; r2[tv2 |-> tv1 |> eta1]) ``` It is implemented in the ForAllCo case in opt_trans_rule in OptCoercion. However current implementation is not right: ``` r2' = substCoWithUnchecked [tv2] [TyVarTy tv1] r2 -- ill-kinded! ``` This patch corrects it to be ``` r2' = substCoWithUnchecked [tv2] [mkCastTy (TyVarTy tv1) eta1] r2 ``` Test Plan: validate Reviewers: bgamari, goldfire, RyanGlScott Reviewed By: RyanGlScott Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15453 Differential Revision: https://phabricator.haskell.org/D5018 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 12:24:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 12:24:36 -0000 Subject: [GHC] #15453: Bug in opt_trans_rule in OptCoercion In-Reply-To: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> References: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> Message-ID: <062.430e7bfd0a62a380a7423e1276acd620@haskell.org> #15453: Bug in opt_trans_rule in OptCoercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5018 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 13:20:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 13:20:01 -0000 Subject: [GHC] #14247: Fails to coerce between newtypes directly In-Reply-To: <051.620a661bd2b7c68990ff1e8817e40a68@haskell.org> References: <051.620a661bd2b7c68990ff1e8817e40a68@haskell.org> Message-ID: <066.bafcf6aa4b87b66a308cfe202d6165e2@haskell.org> #14247: Fails to coerce between newtypes directly -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10184 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #10184 Comment: Closing as a duplicate of #10184. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 13:20:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 13:20:18 -0000 Subject: [GHC] #10184: Coercible solver incomplete with recursive newtypes In-Reply-To: <047.7509967c1582acd23d4cd58fb93af3d5@haskell.org> References: <047.7509967c1582acd23d4cd58fb93af3d5@haskell.org> Message-ID: <062.94bd57f97aee43d4636a544c4c4ff987@haskell.org> #10184: Coercible solver incomplete with recursive newtypes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10184 Blocked By: | Blocking: Related Tickets: #14247 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #14247 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 13:23:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 13:23:05 -0000 Subject: [GHC] #15273: Datatypes with CUSKs should quantify over unknown kinds In-Reply-To: <047.ec7ed2596e5045a5e66eba34c3a673fe@haskell.org> References: <047.ec7ed2596e5045a5e66eba34c3a673fe@haskell.org> Message-ID: <062.5c593ab224e32af175656b1a3ba7adc4@haskell.org> #15273: Datatypes with CUSKs should quantify over unknown kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T11648b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4845 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: merge => closed * resolution: => fixed * milestone: 8.8.1 => 8.6.1 Comment: Actually, this is present in the GHC 8.6 branch, so it //did// make it in. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 13:29:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 13:29:01 -0000 Subject: [GHC] #11549: Add -fshow-runtime-rep In-Reply-To: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> References: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> Message-ID: <062.7d66853e0a02887b55aa61bd66d8ff5a@haskell.org> #11549: Add -fshow-runtime-rep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1961 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: Indeed, I think my suggestion in comment:10 is far too ambitious to be realistic (at least, at the moment). Moreover, `-fprint-explicit-runtime- reps` is now fully implemented and does the job that it advertises in the users' guide (namely, it prints `RuntimeRep`-polymorphic type variables in full detail), so I think this can be closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 14:34:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 14:34:18 -0000 Subject: [GHC] #15260: Xmobar crashes with segmentation fault In-Reply-To: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> References: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> Message-ID: <061.a6949947d1e5ecbfe817e4a2d4b5019b@haskell.org> #15260: Xmobar crashes with segmentation fault ----------------------------------+-------------------------------------- Reporter: Voronwe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by Voronwe): Can you help me? I'm a bit confused... Where can I obtain source code of ghc ''with'' this fix? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 15:47:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 15:47:03 -0000 Subject: [GHC] #11514: Impredicativity is still sneaking in In-Reply-To: <047.227daeb89545e5c355bd1a0b7e05346f@haskell.org> References: <047.227daeb89545e5c355bd1a0b7e05346f@haskell.org> Message-ID: <062.c27aef8c37e461ea48c74d4a4e33df45@haskell.org> #11514: Impredicativity is still sneaking in -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Indeed, this //is// simply missing a check: {{{#!diff diff --git a/compiler/typecheck/TcUnify.hs b/compiler/typecheck/TcUnify.hs index 2ed861c..9280042 100644 --- a/compiler/typecheck/TcUnify.hs +++ b/compiler/typecheck/TcUnify.hs @@ -2165,7 +2165,7 @@ metaTyVarUpdateOK dflags tv ty preCheck :: DynFlags -> Bool -> TcTyVar -> TcType -> OccCheckResult () -- A quick check for --- (a) a forall type (unless -XImpredivativeTypes) +-- (a) a forall type (unless -XImpredicativeTypes) -- (b) a type family -- (c) an occurrence of the type variable (occurs check) -- @@ -2192,7 +2192,10 @@ preCheck dflags ty_fam_ok tv ty | bad_tc tc = OC_Bad | otherwise = mapM fast_check tys >> ok fast_check (LitTy {}) = ok - fast_check (FunTy a r) = fast_check a >> fast_check r + fast_check (FunTy a r) + | not impredicative_ok + && isPredTy a = OC_Bad + | otherwise = fast_check a >> fast_check r fast_check (AppTy fun arg) = fast_check fun >> fast_check arg fast_check (CastTy ty co) = fast_check ty >> fast_check_co co fast_check (CoercionTy co) = fast_check_co co }}} With that, the original program is rejected. There's one hiccup though: once this patch is applied, the `print027` test case begins to panic. Here is a minimized example of what happens: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 8.7.20180729: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :print (+) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20180729 for x86_64-unknown-linux): isUnliftedType t1_a1Cn[rt] :: TYPE t_a1Cm[rt] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:2015:10 in ghc:Type }}} As far as I can tell, `:print` attempts to unify a unification variable `t1` with `Num a => a -> a -> a`, which fails. But `:print` proceeds onward anyways with the (not-unified) type `t1`, and falls over when it passes `t1` to `isUnliftedType`, which doesn't expect a type variable. This is worrying, but then again, `:print` has been known to trigger this `isUnliftedType` panic in other ways for some time now (see #14828). In light of this, I'm not sure if it's worth investing the effort to fix this `:print` panic, or just accept this as a known regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 16:39:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 16:39:55 -0000 Subject: [GHC] #15260: Xmobar crashes with segmentation fault In-Reply-To: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> References: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> Message-ID: <061.a43445315df50aa0e44a20b5a357a0aa@haskell.org> #15260: Xmobar crashes with segmentation fault ----------------------------------+-------------------------------------- Reporter: Voronwe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by hsyl20): The easiest way is to use arcanist to download the patch from https://phabricator.haskell.org/D5020 (i.e. execute "arc patch D5020" in a Git checkout of GHC). But comment:13 already confirmed the fix so you don't have to bother. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 20:14:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 20:14:42 -0000 Subject: [GHC] #3984: Handle multiline input in GHCi history In-Reply-To: <045.498e82fb15ce3032dbd275cf4994c09c@haskell.org> References: <045.498e82fb15ce3032dbd275cf4994c09c@haskell.org> Message-ID: <060.4cf8e66e768559ae65e27c594610a879@haskell.org> #3984: Handle multiline input in GHCi history -------------------------------------+------------------------------------- Reporter: aavogt | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.12.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 fredefox): Has this been dropped? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 20:39:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 20:39:02 -0000 Subject: [GHC] #15415: GHCi's :kind doesn't work with wildcards In-Reply-To: <047.9324d649243992c743ffcce486b06b5a@haskell.org> References: <047.9324d649243992c743ffcce486b06b5a@haskell.org> Message-ID: <062.80f5a9aff9ef5446814771feceb50103@haskell.org> #15415: GHCi's :kind doesn't work with wildcards -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5022 Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * status: new => patch * differential: => Phab:D5022 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 00:58:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 00:58:31 -0000 Subject: [GHC] #15456: (ImplicitParams) Allow ? in binding patterns Message-ID: <049.576bcd2dc86f3f4f8164336cc7153c6f@haskell.org> #15456: (ImplicitParams) Allow ? in binding patterns -------------------------------------+------------------------------------- Reporter: Welperooni | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple ImplicitParams | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is mostly useful when dealing with ImplicitParams. Suppose "foo" takes an implicit parameter "?msg" {{{#!hs -- Invalid, parse error in pattern ?msg bar ?msg = foo \?msg -> foo -- With -XViewPatterns, same issue bar ( ... -> ?msg) = foo }}} Instead, you are forced to create a local let binding {{{#!hs bar msg = let ?msg = msg in foo \msg -> let ?msg = msg in foo bar ( ... -> msg) = let ?msg = msg in foo }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 01:01:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 01:01:13 -0000 Subject: [GHC] #15456: (ImplicitParams) Allow ? in binding patterns In-Reply-To: <049.576bcd2dc86f3f4f8164336cc7153c6f@haskell.org> References: <049.576bcd2dc86f3f4f8164336cc7153c6f@haskell.org> Message-ID: <064.9e70a72ba87f8519d43f54b9371a7526@haskell.org> #15456: (ImplicitParams) Allow ? in binding patterns -------------------------------------+------------------------------------- Reporter: Welperooni | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | ImplicitParams, patterns 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 Welperooni): * keywords: ImplicitParams => ImplicitParams, patterns -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 08:05:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 08:05:41 -0000 Subject: [GHC] #14887: Explicitly quantifying a kind variable causes a telescope to fail to kind-check In-Reply-To: <050.26e9faa4d4a29b625c8bfcdef0d31364@haskell.org> References: <050.26e9faa4d4a29b625c8bfcdef0d31364@haskell.org> Message-ID: <065.549b334bbebdaa26f82876c5fed3e8a7@haskell.org> #14887: Explicitly quantifying a kind variable causes a telescope to fail to kind- check -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Richard? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 08:11:40 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 08:11:40 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.e3cdd19ca0e09a029739909c8168c446@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059, #10431, | Differential Rev(s): Phab:D4876 #14316 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Can someone just summarise why we can't treat `(~)`, from a parsing point of view, as just an ordinary type operator with a specific fixity? With no special treatment in the parser? Why doe we need a "post-parsing pass" for `(~)`? And if it's just an ordinary operator, why does it even need to be built- in syntax? Maybe this all explained above, but a standalone summary would help make sure this ticket is well focused. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 08:28:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 08:28:50 -0000 Subject: [GHC] #15450: Inconsistency w.r.t. coverage checking warnings for EmptyCase under unsatisfiable constraints In-Reply-To: <050.a778e3d607f09b5ab14f992506aa831f@haskell.org> References: <050.a778e3d607f09b5ab14f992506aa831f@haskell.org> Message-ID: <065.c54e07a48a9e313241cd5454a60c5177@haskell.org> #15450: Inconsistency w.r.t. coverage checking warnings for EmptyCase under unsatisfiable constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #12957 | Differential Rev(s): Phab:D5017 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): (Commenting here because my reflections concern the specification, not the coding.) The patch says {{{ We decide to better than this. When beginning coverage checking, we first check if the constraints in scope are unsatisfiable, and if so, we start afresh with an empty set of constraints. This way, we'll get the warnings we expect. }}} That seems quite odd behaviour! The door closes gradually, but when it becomes shut we slam it open again?? What about simpler cases {{{ data T a where T1 :: T Int T2 :: T a f :: T Bool -> Int f T1 = ....(case x of { True -> False })... f T2 = ... }}} The entire RHS of the first equation is unreachable. Should we not just stop reporting errors from that branch altogether? If the door wasn't shut (say we had learned something about `x`, but nothing contradictory) then the inner case might be fine. The more we learn about `x` the fewer alternatives we may need in that inner case. When the door shuts altogether we need no branches in the inner case, so perhaps reporting a redundant match is correct. Or perhaps we just want to shut up once we find a contradiction, and let the user fix that first. But discarding all the constraints seems ... unexpected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 08:33:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 08:33:02 -0000 Subject: [GHC] #15450: Inconsistency w.r.t. coverage checking warnings for EmptyCase under unsatisfiable constraints In-Reply-To: <050.a778e3d607f09b5ab14f992506aa831f@haskell.org> References: <050.a778e3d607f09b5ab14f992506aa831f@haskell.org> Message-ID: <065.8bee9139e169c24bfb734aef08a5c10a@haskell.org> #15450: Inconsistency w.r.t. coverage checking warnings for EmptyCase under unsatisfiable constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #12957 | Differential Rev(s): Phab:D5017 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Another thing. I see in `Note [Checking EmptyCase Expressions]` (in `Check.hs`) this: {{{ Empty case expressions are strict on the scrutinee. That is, `case x of {}` will force argument `x`. Hence, `checkMatches` is not sufficient for checking empty cases, because it assumes that the match is not strict (which is true for all other cases, apart from EmptyCase). This gave rise to #10746. }}} I had no idea! The [http://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#empty-case-alternatives user manual entry] says nothing about this non-uniform behaviour of empty case expressions. What actually stops us from treating an empty case as an ordinary case expression with no alternatives? Anything else seems.. unexpected. The explanation in the user manual is cryptic (see the text about `absurd`. And it relates directly to this ticket, because it has `True ~ False` in scope, which is a contradiction. So maybe fixing comment:2 would mean we could treat case expressions uniformly, which would mean we could delete code? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 08:38:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 08:38:26 -0000 Subject: [GHC] #15453: Bug in opt_trans_rule in OptCoercion In-Reply-To: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> References: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> Message-ID: <062.718293d9b4bcfb7eb2f3c8ae02aa8809@haskell.org> #15453: Bug in opt_trans_rule in OptCoercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5018 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Great work! We have a paper about `OptCoercion`, [https://www.microsoft.com/en- us/research/publication/evidence-normalization-system-fc-2/ Evidence normalisation in System FC]. It is a million times more comprehensible than `OptCoercion.hs` itself. If I found the sources, would anyone (Ryan?) be willing to * put (a version of) it in the GHC repo * update it to be correct, and to cover `GRefl` Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 08:41:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 08:41:05 -0000 Subject: [GHC] #15455: Memory usage when compiling jsaddle-dom exploded in 8.4.3 In-Reply-To: <046.e653d9fec09649e1b4a200e6da1c2507@haskell.org> References: <046.e653d9fec09649e1b4a200e6da1c2507@haskell.org> Message-ID: <061.c97227fbca2693921022156607005602@haskell.org> #15455: Memory usage when compiling jsaddle-dom exploded in 8.4.3 -------------------------------------+------------------------------------- Reporter: eskimor | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * failure: None/Unknown => Compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 08:47:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 08:47:17 -0000 Subject: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls In-Reply-To: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> References: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> Message-ID: <064.63500fe811f8a6540a34f2d1b43a1dfd@haskell.org> #14346: 8.2.1 regression: heap corruption after safe foreign calls -------------------------------------+------------------------------------- Reporter: andrewchen | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15260 | Differential Rev(s): Phab:D5020 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Ah, I guess the patch was only merged to 8.2.2 branch (not to master). That's terrible. And very unusual; usually we put things on master first and then merge to a branch. However, if I understand aright: * The patch in 8.2.2 (comment:33 above) is very much a hack. * The real fix is in #14375 * There is an active patch for #14375 So we should make sure that the patch for #14375 does fix this ticket, and #15260 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 08:49:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 08:49:52 -0000 Subject: [GHC] #14375: Implement with# primop In-Reply-To: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> References: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> Message-ID: <061.8342d322fb2f49ee2e6e101fefbe0de5@haskell.org> #14375: Implement with# primop -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14346 | Differential Rev(s): ​Phab:D4110, Wiki Page: | Phab:D4189 -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => highest Comment: This ticket sounds urgent to me: * It caused #14346 * It caused #15260 (which absorbed lots of people's time) I'm not following the details, but it seems that alexbiehl has made a patch, and we should review and commit it. And check that it fixes the crashes above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 10:35:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 10:35:17 -0000 Subject: [GHC] #11514: Impredicativity is still sneaking in In-Reply-To: <047.227daeb89545e5c355bd1a0b7e05346f@haskell.org> References: <047.227daeb89545e5c355bd1a0b7e05346f@haskell.org> Message-ID: <062.0fd92389051b1aebc4de9ede3eeca514@haskell.org> #11514: Impredicativity is still sneaking in -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > This is worrying, but then again, :print has been known to trigger this isUnliftedType panic in other ways for some time now (see #14828). In light of this, I'm not sure if it's worth investing the effort to fix this :print panic, or just accept this as a known regression. Yes it looks exactly like #14828. I'd be inlined to accept the regression. But it would be great if someone was to actually look at #14828. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 10:50:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 10:50:24 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.42086870607c74ca7c169408233f7883@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059, #10431, | Differential Rev(s): Phab:D4876 #14316 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): When talking about `(~)`, it's important to distinguish between two different uses of it: 1. As the equality type operator. 2. As a laziness annotation in `-XStrict` (e.g., `data Foo a = MkFoo ~a`). If it weren't for usage (2), `(~)` would not need any special treatment at all in the parser. But alas, because of (2), we initially parse all uses of `(~)` as laziness annotations, and perform an additional pass right after parsing to determine which uses of `(~)` are for actually for (1), and which are for actually for (2). (Note that the problems I describe about `(->)` in comment:38 would still be relevant even if `(~)` had no special treatment in the parser. In other words, if we decided in the future to have some other type operator with a precedence of -2 or lower, than we'd have to figure out how to answer The `(->)` Question.) Once that's taken care of, the fixity of `(~)` is handled like any other type operator. I only opted to wire in the fixity of `(~)` in comment:38 since it's negative, and you can't assign a negative fixity through an `infix -2 ~` declaration. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 10:58:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 10:58:54 -0000 Subject: [GHC] #15450: Inconsistency w.r.t. coverage checking warnings for EmptyCase under unsatisfiable constraints In-Reply-To: <050.a778e3d607f09b5ab14f992506aa831f@haskell.org> References: <050.a778e3d607f09b5ab14f992506aa831f@haskell.org> Message-ID: <065.51e79ae47ae0cf12fe11765a6bda39c0@haskell.org> #15450: Inconsistency w.r.t. coverage checking warnings for EmptyCase under unsatisfiable constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #12957 | Differential Rev(s): Phab:D5017 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: mpickering (added) Comment: Replying to [comment:2 simonpj]: > (Commenting here because my reflections concern the specification, not the coding.) > > The patch says > {{{ > We decide to better than this. When beginning coverage checking, we first > check if the constraints in scope are unsatisfiable, and if so, we start > afresh with an empty set of constraints. This way, we'll get the warnings > we expect. > }}} > That seems quite odd behaviour! The door closes gradually, but when it becomes shut we slam it open again?? This is all explained in the commentary in https://phabricator.haskell.org/D3064 (which I've attempted to turn into Note form in this patch). Also cc'ing mpickering, who established this convention. Replying to [comment:3 simonpj]: > Another thing. I see in `Note [Checking EmptyCase Expressions]` (in `Check.hs`) this: > {{{ > Empty case expressions are strict on the scrutinee. That is, `case x of {}` > will force argument `x`. Hence, `checkMatches` is not sufficient for checking > empty cases, because it assumes that the match is not strict (which is true > for all other cases, apart from EmptyCase). This gave rise to #10746. > }}} > I had no idea! The [http://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#empty-case-alternatives user manual entry] says nothing about this non-uniform behaviour of empty case expressions. > > What actually stops us from treating an empty case as an ordinary case expression with no alternatives? Anything else seems.. unexpected. I'm not sure I understand this question. Did you read #10746? That seems to lay out pretty clearly why `EmptyCase` needs to be treated specially (because it's strict, unlike other `case` expressions). > The explanation in the user manual is cryptic (see the text about `absurd`. And it relates directly to this ticket, because it has `True ~ False` in scope, which is a contradiction. So maybe fixing comment:2 would mean we could treat case expressions uniformly, which would mean we could delete code? Maybe. But I have no interest in doing this here. I only opened this ticket because the lack of sharing between code paths in `checkEmptyCase` and `checkSingle` made it difficult to implement #15305, so I did the exact minimum amount of work to fix the discrepancy. Anything more than this deserves to be in a separate feature request, in my opinion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 11:02:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 11:02:07 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.e8b87656515719565d64852ea950f940@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:59 simonpj]: > 3. Try switching back to FV. That is, take the currently-deleted code for `tyCoFVsOfType`, and re-instate it, but modify it not to take the kinds at the variable occurrences. Now use that instead of the new `fvs_of_type`. It "obviously" should be a lot slower -- is it? I'm slightly confused here. `fvs_of_type` already uses FV, before and after the patch; the patch however introduces `tcvs_of_type`, which uses VarSets directly instead of going through `FV`, and this function is where the slowdown appears to be. I changed the code such that it always uses `fvs_of_type` (and thus `FV`) instead of `tcvs_of_type`, and the results are mixed: - The two perf test cases that fail validation now perform slightly better - ...but not enough to make the tests pass - ...and now 3 more perf tests fail Output from `./validate`: {{{ ==== STAGE 2 TESTS ==== Unexpected results from: TEST="T12227 T12545 T14052 T3234 T5321Fun T5631" SUMMARY for test run started at Mon Jul 30 12:28:36 2018 CEST 0:22:35 spent to go through 6350 total tests, which gave rise to 19866 test cases, of which 13175 were skipped 36 had missing libraries 6495 expected passes 154 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 1 unexpected failures 5 unexpected stat failures Unexpected failures: /tmp/ghctest-51wr9fmd/test spaces/./simplCore/should_compile/T3234.run T3234 [stderr mismatch] (optasm) Unexpected stat failures: /tmp/ghctest-51wr9fmd/test spaces/./perf/compiler/T5631.run T5631 [stat not good enough] (normal) /tmp/ghctest-51wr9fmd/test spaces/./perf/compiler/T5321Fun.run T5321Fun [stat not good enough] (normal) /tmp/ghctest-51wr9fmd/test spaces/./perf/compiler/T12227.run T12227 [stat not good enough] (normal) /tmp/ghctest-51wr9fmd/test spaces/./perf/compiler/T12545.run T12545 [stat not good enough] (normal) /tmp/ghctest-51wr9fmd/test spaces/./perf/should_run/T14052.run T14052 [stat not good enough] (ghci) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 11:31:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 11:31:39 -0000 Subject: [GHC] #15445: SPECIALIZE one of two identical functions does not fire well In-Reply-To: <047.c1676aaf78d977670954b9a4dbdf798e@haskell.org> References: <047.c1676aaf78d977670954b9a4dbdf798e@haskell.org> Message-ID: <062.e60133ff4aedba49e0beed9f8cd8f622@haskell.org> #15445: SPECIALIZE one of two identical functions does not fire well ---------------------------------+-------------------------------------- Reporter: nobrakal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by simonpj): Aha. The problem is that we get {{{ RULES: "SPEC plusTwoRec" forall ($dNum :: Num Int). plusTwoRec @ Int $dNum = plusTwoRec_$splusTwoRec }}} but, as you say, Common Subexpression Elimination has decided to replace `plusTwoRec`'s RHS with just `plusTwoRec'`. This is basically a good thing to do (saves code duplication), but if `plusTwoRec` is inlined before the rule has a chance to fire, we'll miss the specialisation. I thought of disabling CSE for functions with RULES; but that seems wrong. Generally, we add a NOINLINE pragma to a function with RULES to ensure that the function does not inline before the rule has a chance to fire. I think we should do the same thing with these auto-generated RULES from specialisations. Patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 11:44:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 11:44:56 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.0c67352633f62b5bfcb29bdcbf21b514@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059, #10431, | Differential Rev(s): Phab:D4876 #14316 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah! I'd forgotten about `-XStrict`. So the special treatment in `Parsery.y` is (only) here {{{ strictness :: { Located ([AddAnn], SrcStrictness) } : '!' { sL1 $1 ([mj AnnBang $1], SrcStrict) } | '~' { sL1 $1 ([mj AnnTilde $1], SrcLazy) } }}} So is `(~)` (in types) handled uniformly with `(!)`? It seems not. Perhaps that's because we don't want to give up `(~)` as an infix operator, but we are willing to give up `(!)`? I got as far as reading `splitTilde` but got lost in its invocations in `RdrHsSyn` and `Parser.y`. Anyway, it'd be good to summarise how the moving parts fit together, in a Note. There are some e.g. `Note [Parsing ~]`, but they are too brief to do justice to the question. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 11:52:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 11:52:06 -0000 Subject: [GHC] #15450: Inconsistency w.r.t. coverage checking warnings for EmptyCase under unsatisfiable constraints In-Reply-To: <050.a778e3d607f09b5ab14f992506aa831f@haskell.org> References: <050.a778e3d607f09b5ab14f992506aa831f@haskell.org> Message-ID: <065.26a365f9f550236fc6ecf057fe27fbc3@haskell.org> #15450: Inconsistency w.r.t. coverage checking warnings for EmptyCase under unsatisfiable constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #12957 | Differential Rev(s): Phab:D5017 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > This is all explained in the commentary in ​https://phabricator.haskell.org/D3064 (which I've attempted to turn into Note form in this patch). Thank you for turning it into a Note. Yes, I am questioning the principle. It seems bizarrely discontinuous to fling the door wide open when (but only when) it completely closes. Indeed I see that on Phab:D3064 George did suggest "The patch as is just drops information, we can instead issue no warnings if we are already in a dead-code branch." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 12:46:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 12:46:35 -0000 Subject: [GHC] #15450: Inconsistency w.r.t. coverage checking warnings for EmptyCase under unsatisfiable constraints In-Reply-To: <050.a778e3d607f09b5ab14f992506aa831f@haskell.org> References: <050.a778e3d607f09b5ab14f992506aa831f@haskell.org> Message-ID: <065.69630d142ac99264586e32cd98bd7bba@haskell.org> #15450: Inconsistency w.r.t. coverage checking warnings for EmptyCase under unsatisfiable constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #12957 | Differential Rev(s): Phab:D5017 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Be careful. You're conflating two separate issues: 1. Should we emit coverage warnings in unreachable alternatives? 2. Should `EmptyCase`'s code path (`checkEmptyCase'`) behave differently than other `case` expressions' code path (`checkMatches'`)? I don't feel strongly about (1), and I think we could just as well answer that question with "yes" or "no". Matthew, can you comment here? You're the one who introduced this convention. The answer to (2) is an emphatic "yes". If you try to delete `checkEmptyCase'`, then //all// `EmptyCase` expressions will be reported as non-exhaustive (this isn't just speculation on my part; I actually tried this). And this is not surprising. Regular `case` expressions are lazy, whereas `EmptyCase` expressions are strict. Hypothetically speaking, if `EmptyCase` were lazy, then in the following code: {{{#!hs data Void absurd :: Void -> a absurd x = case x of {} main :: IO () main = putStrLn (absurd undefined) }}} `main` would produce a non-exhaustive pattern-match error at runtime instead of an `undefined` exception! This alone shows that `EmptyCase` needs some degree of special-casing. While an interesting discussion, (2) doesn't pertain much to this ticket, so I'd encourage you not to bog down the discussion with mention of it. (Feel free to open a separate ticket if it's bothering you that much.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 12:55:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 12:55:49 -0000 Subject: [GHC] #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards In-Reply-To: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> References: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> Message-ID: <065.9e5beeb067a53fe6552e2f09dafdb098@haskell.org> #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4968 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"9d388eb83e797fd28e14868009c4786f3f1a8aa6/ghc" 9d388eb8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9d388eb83e797fd28e14868009c4786f3f1a8aa6" Fix #15385 by using addDictsDs in matchGuards Summary: When coverage checking pattern-matches, we rely on the call sites in the desugarer to populate the local dictionaries and term evidence in scope using `addDictsDs` and `addTmCsDs`. But it turns out that only the call site for desugaring `case` expressions was actually doing this properly. In another part of the desugarer, `matchGuards` (which handles pattern guards), it did not update the local dictionaries in scope at all, leading to #15385. Fixing this is relatively straightforward: just augment the `BindStmt` case of `matchGuards` to use `addDictsDs` and `addTmCsDs`. Accomplishing this took a little bit of import/export tweaking: * We now need to export `collectEvVarsPat` from `HsPat.hs`. * To avoid an import cycle with `Check.hs`, I moved `isTrueLHsExpr` from `DsGRHSs.hs` to `DsUtils.hs`, which resides lower on the import chain. Test Plan: make test TEST=T15385 Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15385 Differential Revision: https://phabricator.haskell.org/D4968 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 12:57:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 12:57:42 -0000 Subject: [GHC] #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards In-Reply-To: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> References: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> Message-ID: <065.4e906b2886438948241395a6b96d81b7@haskell.org> #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | pmcheck/should_compile/T15385 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4968 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => pmcheck/should_compile/T15385 * status: patch => merge Comment: This fixes a pretty serious incompleteness in the pattern-match coverage checker, so I'd humbly request that the commits in comment:9 and comment:10 be merged to 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 13:05:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 13:05:38 -0000 Subject: [GHC] #15453: Bug in opt_trans_rule in OptCoercion In-Reply-To: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> References: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> Message-ID: <062.50cbcbbe77334cfdd9bd4981cdd6b488@haskell.org> #15453: Bug in opt_trans_rule in OptCoercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5018 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Great work indeed. Thanks Ningning! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 13:11:40 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 13:11:40 -0000 Subject: [GHC] #14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is In-Reply-To: <050.3962023f385f083f5f659edfe4ce01db@haskell.org> References: <050.3962023f385f083f5f659edfe4ce01db@haskell.org> Message-ID: <065.c11a60d7917a484e85cc2ad9d4f3e905@haskell.org> #14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Actually, I think the issue may be in an entirely different place than what I originally suspected, and the fact that it surfaces in `EmptyCase` may be entirely coincidental. Consider the following program, which uses an ordinary pattern-match: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -Wall #-} module Bug where data Unit = MkUnit data SUnit (u :: Unit) where SMkUnit :: SUnit 'MkUnit type family F (u :: Unit) where F 'MkUnit = () absoluteUnit :: SUnit u -> F u -> () absoluteUnit SMkUnit x = case x of { () -> () } }}} Things get interesting when you try to put wildcard types on various spots. For example, if you put one on the scrutinee of the `case` expression: {{{#!hs absoluteUnit :: SUnit u -> F u -> () absoluteUnit SMkUnit x = case (x :: _) of { () -> () } }}} Then this is what GHC gives back: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:17:37: error: • Found type wildcard ‘_’ standing for ‘F 'MkUnit’ To use the inferred type, enable PartialTypeSignatures • In an expression type signature: _ In the expression: (x :: _) In the expression: case (x :: _) of { () -> () } • Relevant bindings include x :: F u (bound at Bug.hs:17:22) absoluteUnit :: SUnit u -> F u -> () (bound at Bug.hs:17:1) | 17 | absoluteUnit SMkUnit x = case (x :: _) of { () -> () } | ^ }}} Note that it says `x`'s type is `F 'MkUnit`, not `()`! To make things stranger, if you put an additional wildcard type on the binder for `x`: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -Wall #-} module Bug where data Unit = MkUnit data SUnit (u :: Unit) where SMkUnit :: SUnit 'MkUnit type family F (u :: Unit) where F 'MkUnit = () absoluteUnit :: SUnit u -> F u -> () absoluteUnit SMkUnit (x :: _) = case (x :: _) of { () -> () } }}} Now GHC claims the type of both wildcards is `()`! All this makes me believe that somehow, the typechecker isn't giving the correct type (or at least, an insufficiently type-family-free–type) to `x` unless you explicitly prod GHC with redundant typing information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 13:12:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 13:12:38 -0000 Subject: [GHC] #15456: (ImplicitParams) Allow ? in binding patterns In-Reply-To: <049.576bcd2dc86f3f4f8164336cc7153c6f@haskell.org> References: <049.576bcd2dc86f3f4f8164336cc7153c6f@haskell.org> Message-ID: <064.b7ebf9cbcea85c63b624cae214150ce5@haskell.org> #15456: (ImplicitParams) Allow ? in binding patterns -------------------------------------+------------------------------------- Reporter: Welperooni | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: invalid | Keywords: | ImplicitParams, patterns Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: This is a worthwhile idea to consider, but it should really go via the https://github.com/ghc-proposals/ghc-proposals process, as it's a user- facing language change. I'm closing this ticket as invalid, but I really do encourage you to post a proposal. That process is working well and has incorporated quite a few changes into the language. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 13:14:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 13:14:25 -0000 Subject: [GHC] #13451: Bind implicit parameter in patterns In-Reply-To: <051.db400dc2cca3bd9a6a599c9f27d0cab0@haskell.org> References: <051.db400dc2cca3bd9a6a599c9f27d0cab0@haskell.org> Message-ID: <066.236d5bfc3e92202093faf348752d2c80@haskell.org> #13451: Bind implicit parameter in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: | ImplicitParams Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15456 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid * related: => #15456 Comment: (Copying the resolution from #15456, which is a duplicate of this ticket.) This is a worthwhile idea to consider, but it should really go via the ​https://github.com/ghc-proposals/ghc-proposals process, as it's a user- facing language change. I'm closing this ticket as invalid, but I really do encourage you to post a proposal. That process is working well and has incorporated quite a few changes into the language. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 13:14:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 13:14:35 -0000 Subject: [GHC] #15456: (ImplicitParams) Allow ? in binding patterns In-Reply-To: <049.576bcd2dc86f3f4f8164336cc7153c6f@haskell.org> References: <049.576bcd2dc86f3f4f8164336cc7153c6f@haskell.org> Message-ID: <064.dfd9cdc59b334ccfe2867778e8607762@haskell.org> #15456: (ImplicitParams) Allow ? in binding patterns -------------------------------------+------------------------------------- Reporter: Welperooni | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: invalid | Keywords: | ImplicitParams, patterns Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13451 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13451 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 14:04:10 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 14:04:10 -0000 Subject: [GHC] #14873: The well-kinded type invariant (in TcType) In-Reply-To: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> References: <050.432390dbdc6a6bf0129a45fcc689c7e7@haskell.org> Message-ID: <065.1c9e11f32bf3a1cdd573351f372a4a7a@haskell.org> #14873: The well-kinded type invariant (in TcType) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 14:46:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 14:46:15 -0000 Subject: [GHC] #15457: (~) and (!) are parsed inconsistently in types (plus documentation warts) Message-ID: <050.bc8c0ec5a857afbbf6fcb9729be2d57e@haskell.org> #15457: (~) and (!) are parsed inconsistently in types (plus documentation warts) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (Spawned from https://ghc.haskell.org/trac/ghc/ticket/10056?replyto=41#comment:41) `~` and `!` are slightly special in the parser to allow strict annotations and lazy annotations (with `-XStrict`) in data types. As a result, we initially parse all uses of `~`/`!` as bangs, and we use a post-parsing pass (`mergeOps`/`splitTilde`) to figure out which uses of `~` are actually meant to refer to the equality type constructor. There's a couple of unsatisfying things here: 1. `splitTilde` handles `~`, but not `!`. This means that any use of `!` as a type operator will not work, as evidenced by this GHCi session: {{{ λ> type a ! b = Either a b :1:6: error: Malformed head of type or class declaration: a !b }}} We should update `splitTilde` to handle `!` as well. (And perhaps give that function a new name to reflect its more ambitious goals.) 2. `Note [Parsing ~]` is supposed to explain all of this hullabaloo, but it does a rather poor job of it. Let's add some more prose to it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 14:47:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 14:47:58 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.7bc0d6ab84a78a59622aa6b763584f49@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059, #10431, | Differential Rev(s): Phab:D4876 #14316, #15457 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #10059, #10431, #14316 => #10059, #10431, #14316, #15457 Comment: Replying to [comment:41 simonpj]: > So is `(~)` (in types) handled uniformly with `(!)`? It seems not. Perhaps that's because we don't want to give up `(~)` as an infix operator, but we are willing to give up `(!)`? Ugh, that's a very good point. We //should// be able to use `!` as a type operator, but because of this lack of uniformity, we can't. We should fix this. > Anyway, it'd be good to summarise how the moving parts fit together, in a Note. There are some e.g. `Note [Parsing ~]`, but they are too brief to do justice to the question. Indeed, `Note [Parsing ~]` could stand to be a bit longer. I've opened #15457 for both of these issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 14:55:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 14:55:41 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.d7bbd345dfecad37ec38a8bdabe5a075@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): harendra: is your issue also fixed in 8.6? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 15:18:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 15:18:13 -0000 Subject: [GHC] #15457: (~) and (!) are parsed inconsistently in types (plus documentation warts) In-Reply-To: <050.bc8c0ec5a857afbbf6fcb9729be2d57e@haskell.org> References: <050.bc8c0ec5a857afbbf6fcb9729be2d57e@haskell.org> Message-ID: <065.df8f3215b696ee061c907a3b3c83af55@haskell.org> #15457: (~) and (!) are parsed inconsistently in types (plus documentation warts) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 (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): Phab:D5023 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5023 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 15:34:30 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 15:34:30 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.41cec470f528fe5a9aaee2c49e3b9361@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): If comment: 49 is just an 8.2 issue and isn't reproducible on 8.4 or 8.6 then we should likely consider it to be a different (fixed!) bug than the original one that prompted this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 15:50:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 15:50:08 -0000 Subject: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls In-Reply-To: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> References: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> Message-ID: <064.5af8120f8d711ca989495550112b4ef3@haskell.org> #14346: 8.2.1 regression: heap corruption after safe foreign calls -------------------------------------+------------------------------------- Reporter: andrewchen | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15260 | Differential Rev(s): Phab:D5020 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Very sorry about that hsyl20. This was a case where we had temporary fix which we desperately wanted to improve upon and therefore only merged it to `ghc-8.2`. However, we then weren't able to finish the real fix (`with#`, #14375) before 8.4 and the hack was never ported to `master`. I've cherry-picked the fix onto `ghc-8.4`, `ghc-8.6`, and `master`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 16:29:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 16:29:17 -0000 Subject: [GHC] #15453: Bug in opt_trans_rule in OptCoercion In-Reply-To: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> References: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> Message-ID: <062.131702691d2becca9e0ba1eb71bcc9ad@haskell.org> #15453: Bug in opt_trans_rule in OptCoercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5018 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ningning): Replying to [comment:9 simonpj]: > If I found the sources, would anyone (Ryan?) be willing to > * put (a version of) it in the GHC repo > * update it to be correct, and to cover `GRefl` Also let me know if I could help with anything. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 16:32:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 16:32:18 -0000 Subject: [GHC] #15453: Bug in opt_trans_rule in OptCoercion In-Reply-To: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> References: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> Message-ID: <062.49067fb240beaf3ccceaf7548b47ac7b@haskell.org> #15453: Bug in opt_trans_rule in OptCoercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5018 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): If you (ningning) were willing to put (an updated version of) the paper in the GHC repo, that'd be great. If so I'll dig out the sources. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 16:35:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 16:35:37 -0000 Subject: [GHC] #15453: Bug in opt_trans_rule in OptCoercion In-Reply-To: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> References: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> Message-ID: <062.bc1cc8434c7ad7303d1bf8108f399d82@haskell.org> #15453: Bug in opt_trans_rule in OptCoercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5018 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ningning): Replying to [comment:12 simonpj]: > If you (ningning) were willing to put (an updated version of) the paper in the GHC repo, that'd be great. If so I'll dig out the sources. Yes sure! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 16:39:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 16:39:35 -0000 Subject: [GHC] #14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is In-Reply-To: <050.3962023f385f083f5f659edfe4ce01db@haskell.org> References: <050.3962023f385f083f5f659edfe4ce01db@haskell.org> Message-ID: <065.17953638c1999a2c32e4809084bef8d0@haskell.org> #14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): But `()` and `F 'MkUnit` are equal types, so it's probably a bit random which gets reported wehre. Why do you think the typechecker "isn't giving the correct type", and would would be consequences of that be? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 16:45:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 16:45:53 -0000 Subject: [GHC] #14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is In-Reply-To: <050.3962023f385f083f5f659edfe4ce01db@haskell.org> References: <050.3962023f385f083f5f659edfe4ce01db@haskell.org> Message-ID: <065.b2c6dd99e27f9940f3b5feb8ee1a6724@haskell.org> #14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:3 simonpj]: > Why do you think the typechecker "isn't giving the correct type" Like I said in comment:2, what I meant by "correct type" is "insufficiently type-family–free type". > and would would be consequences of that be? The consequences are this very ticket! As explained in comment:1, `F False a` and `Void` can produce different results in the pattern-match coverage checker, so it's critical that we use the latter whenever possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 17:22:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 17:22:05 -0000 Subject: [GHC] #15441: Data type with phantoms using TypeInType isn't coercible In-Reply-To: <051.c0b9407ab0ec784876ce6e4509034b58@haskell.org> References: <051.c0b9407ab0ec784876ce6e4509034b58@haskell.org> Message-ID: <066.665e409666b3da8ef05a4750417287be@haskell.org> #15441: Data type with phantoms using TypeInType isn't coercible -------------------------------------+------------------------------------- Reporter: glittershark | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Roles 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 monoidal): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 18:33:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 18:33:09 -0000 Subject: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls In-Reply-To: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> References: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> Message-ID: <064.9b3fd43e4d324ebd4a6be967db18e7bc@haskell.org> #14346: 8.2.1 regression: heap corruption after safe foreign calls -------------------------------------+------------------------------------- Reporter: andrewchen | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15260 | Differential Rev(s): Phab:D5020 Wiki Page: | -------------------------------------+------------------------------------- Comment (by svenpanne): So this looks like a hint that there will be a GHC 8.4.4. :-) Can we bump the haddock submodule in that branch, too, to get a fix for https://github.com/haskell/haddock/issues/837? That issue is quite annoying, breaking lots of packages when built with stack. Perhaps there is already a ticket for this, but I couldn't find it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 20:09:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 20:09:20 -0000 Subject: [GHC] #15441: Data type with phantoms using TypeInType isn't coercible In-Reply-To: <051.c0b9407ab0ec784876ce6e4509034b58@haskell.org> References: <051.c0b9407ab0ec784876ce6e4509034b58@haskell.org> Message-ID: <066.9692ed7786d1792cd479424eb8d2a869@haskell.org> #15441: Data type with phantoms using TypeInType isn't coercible -------------------------------------+------------------------------------- Reporter: glittershark | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Research | needed Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Roles Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.6.1 => Research needed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 20:31:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 20:31:59 -0000 Subject: [GHC] #15458: Misleading error message on mising BangPatterns extension Message-ID: <044.242c625a48ea7d7485227276f506fe2e@haskell.org> #15458: Misleading error message on mising BangPatterns extension -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Poor/confusing (amd64) | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For following program I'm getting an unexpected error message. {{{#!hs foo :: Int -> Int foo = bar where bar :: Int -> Int bar !i = i }}} {{{ $ ghc -o Test Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Test.hs:4:5: error: The type signature for ‘bar’ lacks an accompanying binding | 4 | bar :: Int -> Int | ^^^ }}} Enabling `-XBangPatterns` fixes the issue but I wanted the compiler to suggest me to enable it: {{{ $ ghc -XBangPatterns -o Test Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Test.hs:1:1: error: The IO action ‘main’ is not defined in module ‘Main’ | 1 | foo :: Int -> Int | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 20:38:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 20:38:54 -0000 Subject: [GHC] #12674: GHC doesn't handle ./ prefixed paths correctly In-Reply-To: <047.897ae5e9c5c47ed13f84034ccb7c5729@haskell.org> References: <047.897ae5e9c5c47ed13f84034ccb7c5729@haskell.org> Message-ID: <062.bab6780704affa76e011fc2b3ffc4d31@haskell.org> #12674: GHC doesn't handle ./ prefixed paths correctly -------------------------------------+------------------------------------- Reporter: dobenour | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: Component: Driver | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: T12674 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D5009 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"a7c8acda5c7ad99fa983bbd5e59480ab5e633c54/ghc" a7c8acd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a7c8acda5c7ad99fa983bbd5e59480ab5e633c54" GHC doesn't handle ./ prefixed paths correctly (#12674) Summary: If a filename starts with a hypen, GHC keeps the prefixed "./" path. Test Plan: make test TEST=T12674 Reviewers: Phyx, nomeata, bgamari, erikd Reviewed By: Phyx Subscribers: rwbarton, thomie, carter GHC Trac Issues: #12674 Differential Revision: https://phabricator.haskell.org/D5009 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 21:31:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 21:31:43 -0000 Subject: [GHC] #15459: Wredundant-constraints does not work when constraint synonym is used Message-ID: <046.7a03097bbe6977e49c92deb446a0c2df@haskell.org> #15459: Wredundant-constraints does not work when constraint synonym is used -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE ConstraintKinds #-} {-# OPTIONS_GHC -Wredundant-constraints #-} module Main where import Data.List main :: IO () main = return () withWarning :: (Show a, Ord a) => [a] -> [a] withWarning = sort type ConstraintSynonym a = (Show a, Ord a) withoutWarning :: ConstraintSynonym a => [a] -> [a] withoutWarning = sort }}} {{{ Main.hs:12:1: warning: [-Wredundant-constraints] • Redundant constraint: Show a • In the type signature for: withWarning :: forall a. (Show a, Ord a) => [a] -> [a] | 14 | withWarning :: (Show a, Ord a) => [a] -> [a] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} The withoutWarning function does not need the (Show a) constraint but there is no warning for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 21:53:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 21:53:33 -0000 Subject: [GHC] #3984: Handle multiline input in GHCi history In-Reply-To: <045.498e82fb15ce3032dbd275cf4994c09c@haskell.org> References: <045.498e82fb15ce3032dbd275cf4994c09c@haskell.org> Message-ID: <060.70b2cd04010065ee0539bb0aa3b0aa95@haskell.org> #3984: Handle multiline input in GHCi history -------------------------------------+------------------------------------- Reporter: aavogt | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.12.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I would guess so. Perhaps you would like to pick it up? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 21:55:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 21:55:43 -0000 Subject: [GHC] #15260: Xmobar crashes with segmentation fault In-Reply-To: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> References: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> Message-ID: <061.0dc80f40e87f8922e5c421c721dc2b1b@haskell.org> #15260: Xmobar crashes with segmentation fault ----------------------------------+-------------------------------------- Reporter: Voronwe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by bgamari): * milestone: 8.8.1 => 8.6.1 Comment: We all owe hsyl20 a debt of gratitude for taking the time to get to the bottom of this. Thanks to him the fix will be present in 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 22:00:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 22:00:03 -0000 Subject: [GHC] #14375: Implement with# primop In-Reply-To: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> References: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> Message-ID: <061.d2b1171d290d94526641df94870d5dcc@haskell.org> #14375: Implement with# primop -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14346 | Differential Rev(s): ​Phab:D4110, Wiki Page: | Phab:D4189 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"56590db07a776ce81eb89d4a4d86bd0f953fb44e/ghc" 56590db/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="56590db07a776ce81eb89d4a4d86bd0f953fb44e" base: Make Foreign.Marshal.Alloc.allocBytes[Aligned] NOINLINE As noted in #14346, touch# may be optimized away when the simplifier can see that the continuation passed to allocaBytes will not return. Marking CPS- style functions with NOINLINE ensures that the simplier can't draw any unsound conclusions. Ultimately the right solution here will be to do away with touch# and instead introduce a scoped primitive as is suggested in #14375. Note: This was present in 8.2 but was never merged to 8.4 in hopes that we would have #14375 implemented in time. This meant that the issue regressed again in 8.4. Thankfully we caught it in time to fix it for 8.6. (cherry picked from commit 404bf05ed3193e918875cd2f6c95ae0da5989be2) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 22:00:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 22:00:03 -0000 Subject: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls In-Reply-To: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> References: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> Message-ID: <064.e1b85e309cbcc0e3ba4c0a7b1df94ce2@haskell.org> #14346: 8.2.1 regression: heap corruption after safe foreign calls -------------------------------------+------------------------------------- Reporter: andrewchen | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15260 | Differential Rev(s): Phab:D5020 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"56590db07a776ce81eb89d4a4d86bd0f953fb44e/ghc" 56590db/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="56590db07a776ce81eb89d4a4d86bd0f953fb44e" base: Make Foreign.Marshal.Alloc.allocBytes[Aligned] NOINLINE As noted in #14346, touch# may be optimized away when the simplifier can see that the continuation passed to allocaBytes will not return. Marking CPS- style functions with NOINLINE ensures that the simplier can't draw any unsound conclusions. Ultimately the right solution here will be to do away with touch# and instead introduce a scoped primitive as is suggested in #14375. Note: This was present in 8.2 but was never merged to 8.4 in hopes that we would have #14375 implemented in time. This meant that the issue regressed again in 8.4. Thankfully we caught it in time to fix it for 8.6. (cherry picked from commit 404bf05ed3193e918875cd2f6c95ae0da5989be2) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 22:16:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 22:16:25 -0000 Subject: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls In-Reply-To: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> References: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> Message-ID: <064.6944fd7e9a47be097bdbf71efcbb5e84@haskell.org> #14346: 8.2.1 regression: heap corruption after safe foreign calls -------------------------------------+------------------------------------- Reporter: andrewchen | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15260 | Differential Rev(s): Phab:D5020 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): Thanks Ben. Could you also merge the test case from Phab:D5020 so that it doesn't get lost? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 22:23:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 22:23:58 -0000 Subject: [GHC] #15386: TTG typo: XFieldOcc should be XCFieldOcc In-Reply-To: <044.ce27d4db3b23b0319278af1be4448a3c@haskell.org> References: <044.ce27d4db3b23b0319278af1be4448a3c@haskell.org> Message-ID: <059.4b075a484d07bd44578ba6f8de9eed03@haskell.org> #15386: TTG typo: XFieldOcc should be XCFieldOcc -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in f14c087a8b88c39e3567af1dde7c2368a5391333. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 22:26:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 22:26:48 -0000 Subject: [GHC] #15051: -split-objs generates excessively many files on Windows In-Reply-To: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> References: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> Message-ID: <060.c99e69029f7e3edd37fa568ece44c2ed@haskell.org> #15051: -split-objs generates excessively many files on Windows -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Phyx- Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (CodeGen) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4915 Wiki Page: | Phab:D4916 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: comment:13 merged to `ghc-8.6` in f14c087a8b88c39e3567af1dde7c2368a5391333. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 22:27:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 22:27:33 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.aabb72c56ef641a42b79744712bdb296@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: osa1 Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4962 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.6` in 72dc7989a25ed6ec4ab9d3adfeefc15425acbf57. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 22:28:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 22:28:04 -0000 Subject: [GHC] #15440: Flush eventlog in hs_init_ghc In-Reply-To: <043.a9a8394a5250a3fe2c866ddd9f27e645@haskell.org> References: <043.a9a8394a5250a3fe2c866ddd9f27e645@haskell.org> Message-ID: <058.58bd047e9d460477a104b414e9c2dcbb@haskell.org> #15440: Flush eventlog in hs_init_ghc -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.6` in 50e4e48bb0d63aaa4c62f5ca0f01d5fb7587ec84. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 22:28:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 22:28:29 -0000 Subject: [GHC] #15399: Build failure on PowerPC 64-bit big endian In-Reply-To: <047.59eacae05c8ce75e039f0bbb218e3836@haskell.org> References: <047.59eacae05c8ce75e039f0bbb218e3836@haskell.org> Message-ID: <062.441465fd4659d39f9cec9359be240425@haskell.org> #15399: Build failure on PowerPC 64-bit big endian ----------------------------------------+---------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5001 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.6` in 3795b454f4b788e23fee89d81a187db089183e06. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 22:30:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 22:30:50 -0000 Subject: [GHC] #14375: Implement with# primop In-Reply-To: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> References: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> Message-ID: <061.db394bed7b2f485a344dffd7974fbb88@haskell.org> #14375: Implement with# primop -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14346 | Differential Rev(s): ​Phab:D4110, Wiki Page: | Phab:D4189 -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-8.6` and `master`. Hopefully we will be able to revert this when `with#` is merged in (likely) 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 22:40:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 22:40:52 -0000 Subject: [GHC] #15051: -split-objs generates excessively many files on Windows In-Reply-To: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> References: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> Message-ID: <060.55b4c6fe537c7e5536344bca324df60a@haskell.org> #15051: -split-objs generates excessively many files on Windows -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Phyx- Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (CodeGen) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4915 Wiki Page: | Phab:D4916 -------------------------------------+------------------------------------- Comment (by Phyx-): > I've noticed this problem too, but I'm not sure getting rid of split- objs is the solution. The problem, it seems to me, is that it's (a) splitting with a Perl script, and (b) calling gcc with each and every single individual file produced. (a) is not the problem. The perl script just does a simple linear scan looking for split markers and breaks it up. The overall runtime of the split script is negligible. (b) It won't work without this. split-objs just exploits the fact that linkers pull in library code on demand. If no symbols in an object file in an archive is needed it's not pulled in. split-section uses "linker stubs" to get the same effect, the tiny object files are pre-linked together to get one giant object file where each original .s file is a new stub. Passing all the .s files to the assembler will cause it to merge the contents of the sections and you'd get one linker stub. The net effect would be the same as not splitting to begin with. While you could force the creation of a linker stub with a `.file` directive for each part, the result still won't be the same as your `.text` section header will still be merged. > Is it possible to get rid of the Perl script, at least on Windows, by specializing the split-objects procedure for Windows x86/x64 builds and then using gcc to build many assembly files at a time? Not really, as I've explained above. > Actually, now that I think about it, why is it even using gcc to convert the assembly files into object files in the first place? Doesn't it convert the code directly into an object file when split-objs isn't used? No, GHC doesn't have an assembler or static linker. It always uses an external program for both of these cases. It only has a runtime linker for GHCi and Template Haskell. As it stands, `-split-objs` is simply a dead approach, it's better to invest the time into getting `-split-sections` working, which doesn't rely on hacks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 23:47:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 23:47:11 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.fb4fcc59bc60300260bbc4fff7364508@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Yikes, this is quite scary. I supposee x86's memory model is so strong that it likely doesn't make much of a difference there, but having such a bug in the LLVM codegen is quite concerning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jul 30 23:52:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 30 Jul 2018 23:52:35 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.4ac0207625af78028cbc26c9de010102@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Actually, I don't think it's true that what suggestion in comment:2 is quite right. The fact that there is a barrier is embodied by the `True` argument of `genLoadW` (which the definition site binds to the name `atomic`). This gets lowered as a `seq_cst` load. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 00:34:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 00:34:16 -0000 Subject: [GHC] #15458: Misleading error message on mising BangPatterns extension In-Reply-To: <044.242c625a48ea7d7485227276f506fe2e@haskell.org> References: <044.242c625a48ea7d7485227276f506fe2e@haskell.org> Message-ID: <059.6d87472bfe5968c5cde33da49b729c46@haskell.org> #15458: Misleading error message on mising BangPatterns extension -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: #13600, #15166 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13600, #15166 Comment: This is a duplicate of #13600, so I'll close this ticket in favor of that one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 00:35:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 00:35:21 -0000 Subject: [GHC] #13600: surprising error message with bang pattern In-Reply-To: <051.cb1136f932f929f97ddeb5e4dd8a6304@haskell.org> References: <051.cb1136f932f929f97ddeb5e4dd8a6304@haskell.org> Message-ID: <066.8cda398d01f813fb52420c1757ff3b87@haskell.org> #13600: surprising error message with bang pattern -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: BangPatterns Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #15166, #15458 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * os: Linux => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple * related: => #15166, #15458 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 00:52:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 00:52:22 -0000 Subject: [GHC] #13600: surprising error message with bang pattern In-Reply-To: <051.cb1136f932f929f97ddeb5e4dd8a6304@haskell.org> References: <051.cb1136f932f929f97ddeb5e4dd8a6304@haskell.org> Message-ID: <066.8b734ebf6a6a6454279a7243baae1e0f@haskell.org> #13600: surprising error message with bang pattern -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: BangPatterns Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #15166, #15458 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * owner: sighingnow => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 00:53:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 00:53:03 -0000 Subject: [GHC] #13600: surprising error message with bang pattern In-Reply-To: <051.cb1136f932f929f97ddeb5e4dd8a6304@haskell.org> References: <051.cb1136f932f929f97ddeb5e4dd8a6304@haskell.org> Message-ID: <066.7986c83e2ecb44e83c59f25fc18b042d@haskell.org> #13600: surprising error message with bang pattern -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: BangPatterns, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #15166, #15458 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: BangPatterns => BangPatterns, newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 07:59:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 07:59:24 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.e6a5647bbbe3bf91b3e0c16d4d3565e7@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Richard's original patch: http://git.haskell.org/ghc.git/log/refs/heads/wip/T14880. I'll push experiments to branches wip/T14880/... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 08:17:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 08:17:02 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.dc0ff6b8f3260645e6c93c13e066172e@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Just to record that we decided that the experiment in comment:68 is misleading. There are two main changes in Richard's patch 1. Do `closeOverKinds` at the end, here: {{{ -- NEW tyCoVarsOfType = closeOverKinds . tcvs_of_type }}} rather than independently at each leaf: {{{ -- OLD tyCoFVsOfType (TyVarTy v) a b c = (unitFV v `unionFV` tyCoFVsOfType (tyVarKind v)) a b c -- NEW tcvs_of_type (TyVarTy v) = unitVarSet v }}} 2. Insetad of using `FV` and then taking its `VarSet`, use `VarSets` directly. This jolly well ought to be faster. But in comment:68, Tobias used the new (1) but the old (2) and thus closed over the kind vars ''both'' at the leaves ''and'' at the end. That's not going to be fast. We agreed that a it'd be iluminating to start from the existing GHC baseline and try (2) alone: is `VarSet` faster than `FV`? Then add (1). NB: it is (1) that fixes the actual bug in this ticket. Ultimately it is not optional. But (1) should be a perf boost too! If a variable occurs N times, we'll take the free vars of its kind once instead of N times. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 08:54:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 08:54:27 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.7565fd79f75d27003af4a936e7d2c656@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I was suspicious about comment:64 so I took a look. Sure enough * The list `[1..n]` wasn't being fused away because it was shared between `insert` and `union`, while `balanced` worked differently and generated no intermediate list. * More significantly, the integers were in ascending order which is fantastically good for balanced union: the tree that implements the set is always balanced and never needs to be transformed. So I tried with a random tree. Code is below. Results are much more plausible * balanced: 1.15G alloc, 1.6sec * union: 1.2G alloc, 1.6sec * insert: 1.17G alloc, 1.6sec Conclusion: containers is behaving OK. {{{ {-#LANGUAGE LambdaCase #-} module Main( run, main ) where import qualified Data.IntSet as Set import System.Environment import System.Random data Tree = Leaf Int | Node Tree Tree randomTree :: Int -> Int -> IO Tree randomTree lo hi | lo == hi = do { n <- randomRIO (1,100000) ; return (Leaf n) } | otherwise = do { l <- randomTree lo mid ; r <- randomTree (mid+1) hi ; return (Node l r) } where mid = (lo+hi) `div` 2 main = do { args <- getArgs ; case args of (size:what:_) -> do { t <- randomTree 1 (read size) ; print (Set.size (run what t)) } _ -> error "Invalid args" } run :: String -> Tree -> Set.IntSet run "balanced" t = go t where go (Leaf n) = Set.singleton n go (Node t1 t2) = go t1 `Set.union` go t2 run "insert" t = go t Set.empty where go (Leaf n) acc = Set.insert n acc go (Node t1 t2) acc = go t1 (go t2 acc) run "union" t = go t Set.empty where go (Leaf n) acc = Set.union (Set.singleton n) acc go (Node t1 t2) acc = go t1 (go t2 acc) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 09:33:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 09:33:09 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <060.4a65184a8d06af7466a17b950a41c0ce@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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): Phab:D4988 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ppk): * Attachment "test.bkp" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 09:33:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 09:33:29 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <060.8614f4dffa237d81fb7aa3278603805b@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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): Phab:D4988 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ppk): * Attachment "out" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 09:44:04 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 09:44:04 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <060.51dc1d3f173a00b690ed53fd438825cd@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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): Phab:D4988 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ppk): * Attachment "out-desugar" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 09:46:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 09:46:55 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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): Phab:D4988 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ppk): * Attachment "out" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 09:46:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 09:46:55 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <060.f3f9786fd39d506d623615bf3f81ed45@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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): Phab:D4988 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ppk): * Attachment "out" added. Output after simplification `-ddump-simpl` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 10:12:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 10:12:22 -0000 Subject: [GHC] #8944: Warn instead of stopping on misplaced Haddock comments In-Reply-To: <047.5551abebc2213482bde9e949bb62029b@haskell.org> References: <047.5551abebc2213482bde9e949bb62029b@haskell.org> Message-ID: <062.d487ab5c24850307fda170c09b341761@haskell.org> #8944: Warn instead of stopping on misplaced Haddock comments -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (Parser) | 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:D452 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * cc: sjakobi (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 10:59:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 10:59:53 -0000 Subject: [GHC] #8944: Warn instead of stopping on misplaced Haddock comments In-Reply-To: <047.5551abebc2213482bde9e949bb62029b@haskell.org> References: <047.5551abebc2213482bde9e949bb62029b@haskell.org> Message-ID: <062.a20f8aef86cbb913d73b05e3af151e92@haskell.org> #8944: Warn instead of stopping on misplaced Haddock comments -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (Parser) | 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:D452 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * cc: hvr (added) Comment: It would be great to see this ticket revived: With the Hi Haddock changes, more people are going to enable `-haddock` by default. IMHO this doesn't have to work perfectly in order to avoid most of the pain for `-haddock` users. Maybe it would be enough to update Phab:D452 to get an initial fix? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 11:35:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 11:35:15 -0000 Subject: [GHC] #15460: Literals overflow Message-ID: <045.4d90b83e8c6931283f442559046619d4@haskell.org> #15460: Literals overflow -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following example: {{{#!hs {-# LANGUAGE MagicHash #-} import GHC.Int main :: IO () main = do let x = I# (0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff#) print x }}} It gets desugared into: {{{#!hs main = print @ Int GHC.Show.$fShowInt (GHC.Types.I# 7237005577332262213973186563042994240829374041602535252466099000494570602495#) }}} Problem: the literal value isn't rounded and there is no overflow warning. It breaks the invariant that literal values in Core have to be in range. Bad things can happen when we break this invariant: {{{#!hs {-# LANGUAGE MagicHash #-} import GHC.Int import Control.Monad main :: IO () main = do let x = I# (0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff#) when (x > maxBound) $ do print "Oups" > ghc TestLitOverflow.hs -Wall -O2 > ./TestLitOverflow "Oups" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 11:37:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 11:37:13 -0000 Subject: [GHC] #15460: Literals overflow In-Reply-To: <045.4d90b83e8c6931283f442559046619d4@haskell.org> References: <045.4d90b83e8c6931283f442559046619d4@haskell.org> Message-ID: <060.5b63ca283481ef84e6a68bddb3433983@haskell.org> #15460: Literals overflow -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by hsyl20: Old description: > Consider the following example: > > {{{#!hs > {-# LANGUAGE MagicHash #-} > import GHC.Int > > main :: IO () > main = do > let x = I# > (0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff#) > print x > }}} > > It gets desugared into: > {{{#!hs > main > = print > @ Int > GHC.Show.$fShowInt > (GHC.Types.I# > 7237005577332262213973186563042994240829374041602535252466099000494570602495#) > }}} > > Problem: the literal value isn't rounded and there is no overflow > warning. > > It breaks the invariant that literal values in Core have to be in range. > Bad things can happen when we break this invariant: > > {{{#!hs > {-# LANGUAGE MagicHash #-} > import GHC.Int > import Control.Monad > > main :: IO () > main = do > let x = I# > (0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff#) > when (x > maxBound) $ do > print "Oups" > > > ghc TestLitOverflow.hs -Wall -O2 > > ./TestLitOverflow > "Oups" > }}} New description: Consider the following example: {{{#!hs {-# LANGUAGE MagicHash #-} import GHC.Int main :: IO () main = do let x = I# (0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff#) print x }}} It gets desugared into: {{{#!hs main = print @ Int GHC.Show.$fShowInt (GHC.Types.I# 7237005577332262213973186563042994240829374041602535252466099000494570602495#) }}} Problem: the literal value isn't rounded and there is no overflow warning. It breaks the invariant that literal values in Core have to be in range. Bad things can happen when we break this invariant: {{{#!hs {-# LANGUAGE MagicHash #-} import GHC.Int main :: IO () main = do let x = I# (0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff#) if (x > maxBound) then print "Oups" else print "Ok" > ghc TestLitOverflow.hs -Wall -O0 > ./TestLitOverflow "Ok" > ghc TestLitOverflow.hs -Wall -O2 > ./TestLitOverflow "Oups" }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 12:19:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 12:19:52 -0000 Subject: [GHC] #15445: SPECIALIZE one of two identical functions does not fire well In-Reply-To: <047.c1676aaf78d977670954b9a4dbdf798e@haskell.org> References: <047.c1676aaf78d977670954b9a4dbdf798e@haskell.org> Message-ID: <062.91172ccede37283728779673da138259@haskell.org> #15445: SPECIALIZE one of two identical functions does not fire well ---------------------------------+-------------------------------------- Reporter: nobrakal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2110738b280543698407924a16ac92b6d804dc36/ghc" 2110738b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2110738b280543698407924a16ac92b6d804dc36" Don't inline functions with RULES too early Trac #15445 showed that a function with an automatically generated specialisation RULE coudl be inlined before the RULE had a chance to fire. This patch attaches a NOINLINE[2] activation to the Id, to stop this happening. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 12:24:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 12:24:18 -0000 Subject: [GHC] #15453: Bug in opt_trans_rule in OptCoercion In-Reply-To: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> References: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> Message-ID: <062.7df169d91ba9c6f227ca4647015d43eb@haskell.org> #15453: Bug in opt_trans_rule in OptCoercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5018 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK done! Here is the original publication: [https://www.microsoft.com/en- us/research/publication/evidence-normalization-system-fc-2/ Evidence normalisation in System FC]. {{{ commit 3a065617b168813ec7e356ddd4eb25d125e9ff59 Author: Simon Peyton Jones Date: Tue Jul 31 13:17:58 2018 +0100 Add the paper "Evidence normalisation in System FC" This is with a view to editing it to include new developments in the coercion infrastructure. >--------------------------------------------------------------- 3a065617b168813ec7e356ddd4eb25d125e9ff59 docs/opt-coercion/Makefile | 9 + docs/{storage-mgt => opt-coercion}/code.sty | 2 + docs/opt-coercion/denot.sty | 120 + docs/opt-coercion/fc-normalization-rta.bib | 7157 +++++++++++++++++++++++++++ docs/opt-coercion/fc-normalization-rta.tex | 1627 ++++++ docs/opt-coercion/lipics.cls | 647 +++ docs/opt-coercion/prooftree.sty | 347 ++ 7 files changed, 9909 insertions(+) }}} Please edit away! Perhaps you can include a preamble saying "This is an updated version of the published paper. This version is intended to evolve to accurately reflect GHC". If you want use OTT, like `core-spec` then fine. But it may be easier just to work with the formatting as-is. A first step would be to include `GRefl` and anything else that isn't reflected in the paper. Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 12:28:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 12:28:44 -0000 Subject: [GHC] #15445: SPECIALIZE one of two identical functions does not fire well In-Reply-To: <047.c1676aaf78d977670954b9a4dbdf798e@haskell.org> References: <047.c1676aaf78d977670954b9a4dbdf798e@haskell.org> Message-ID: <062.455f808c02c0f55d1a993b706ce0389a@haskell.org> #15445: SPECIALIZE one of two identical functions does not fire well -------------------------------------+------------------------------------- Reporter: nobrakal | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T15445 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => simplCore/should_compile/T15445 * status: new => closed * resolution: => fixed Comment: Fixed! Thank you for the bug report. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 12:40:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 12:40:17 -0000 Subject: [GHC] #15459: Wredundant-constraints does not work when constraint synonym is used In-Reply-To: <046.7a03097bbe6977e49c92deb446a0c2df@haskell.org> References: <046.7a03097bbe6977e49c92deb446a0c2df@haskell.org> Message-ID: <061.8744802c7e2817ee2d62d93ca8cdb602@haskell.org> #15459: Wredundant-constraints does not work when constraint synonym is used -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, this is a little awkward * `withWarning` has two separate constraints; its type is really curried, like this: {{{ withWarning :: Show a => Ord a => [a] -> [a] }}} * `withoutWarnig` only has one constraint, a tuple. It is uncurried. This is so even though it's only a synonym, so that if you ask say `:t withoutWarning` it'll display the type with the synonym. But the result is that the compound constraint for `withoutWarning` is in fact used (by `sort`). I'm sure it'd be possible to fix this, but there's a bit of a grey zone. What about {{{ type family F a :: Constraint type instance F [a] = (Show a, Ord a) foo :: F [a] => [a] -> [a] }}} Do you expect a warning for that? A type system is a degenerate form of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 13:11:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 13:11:16 -0000 Subject: [GHC] #15459: Wredundant-constraints does not work when constraint synonym is used In-Reply-To: <046.7a03097bbe6977e49c92deb446a0c2df@haskell.org> References: <046.7a03097bbe6977e49c92deb446a0c2df@haskell.org> Message-ID: <061.7408db674489176eb63064d76a0661b2@haskell.org> #15459: Wredundant-constraints does not work when constraint synonym is used -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by flip101): Simon, i don't know about type families. I tried reading about them at https://wiki.haskell.org/GHC/Type_families but even so i don't feel i have enough experience with them to give a useful response to your question. It's also more confusing for me because in your example foo doesn't have an implementation. With `withoutWarning = sort` it was clear to me that sort requires Ord but not Show. I will make a guess here and say "yes i expect a warning for that". When the instance `F [a]` is used in used in the function `foo` it can be deduced that this is the is the active instance which is used in the function foo. If foo is implemented as `foo = sort` then (`Show a`) is also redundant in the instance of the .. constraint type family ? My guess can be non-sense .. please refer to the first paragraph :P -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 13:29:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 13:29:35 -0000 Subject: [GHC] #12030: GHCi Proposal: Display (Data.Kind.)Type instead of * In-Reply-To: <051.b7378bd56fec6afa8a8403e249c2a583@haskell.org> References: <051.b7378bd56fec6afa8a8403e249c2a583@haskell.org> Message-ID: <066.d4cd22aa154a148de69001a09031a30c@haskell.org> #12030: GHCi Proposal: Display (Data.Kind.)Type instead of * -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: johnleo Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed * milestone: => 8.6.1 Comment: My understanding is that the `-XNoStarIsType` extension gives you exactly what you seek here, since that displays `*` as `Type` in GHCi: {{{ GHCi, version 8.6.0.20180714: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :kind Int Int :: * λ> :set -XNoStarIsType λ> :kind Int Int :: Type }}} As such, I'm opting to close this. (There's still an [https://github.com/ghc-proposals/ghc-proposals/pull/143 ongoing discussion] about whether `-XNoStarIsType` should be the default, but that's a separate matter.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 14:07:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 14:07:18 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <060.13bc94eac1fbfc2b765886dfe956c562@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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): Phab:D4988 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ppk): As mentioned by @simonpj, it would be desirable to actually pinpoint how the dictionaries of `KnownNat` and friends get resolved in the context of backpack. This comment is more to document what I have learned by simply dumping the desugared version. I have attached a test backpack program (attachment:test.bkp) with the output after compiling with `-ddump-ds` and `-ddump-simpl`. The desugared version is avaliable in attachment:out-desugar One can clearly see that an the KnownNat instance is substituted for and the appropriate versions of Util is created [https://ghc.haskell.org/trac/ghc/attachment/ticket/15379/out-desugar#L58 Line 56] and [https://ghc.haskell.org/trac/ghc/attachment/ticket/15379/out- desugar#L92 Line 92]. Although there is no trace of the Util module without the substitution, if we had no mixing-in there will also be a variant of Util with the abstract dictionary for `KnownNat NatType`. So my understanding would be that backpack is going ahead and "inlining" the dictionary when mixing a module that uses a abstract signature with a concrete implementation of that signature. I hope that makes sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 14:15:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 14:15:33 -0000 Subject: [GHC] #14331: Overzealous free-floating kind check causes deriving clause to be rejected In-Reply-To: <050.cb87f2a10e38fd0ac57d92b074ac5d5b@haskell.org> References: <050.cb87f2a10e38fd0ac57d92b074ac5d5b@haskell.org> Message-ID: <065.6ec1b2fedf5694557b0b92ffda74af01@haskell.org> #14331: Overzealous free-floating kind check causes deriving clause to be rejected -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T14331 Blocked By: | Blocking: 15376 Related Tickets: #15376 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm a bit lost as to where we are on this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 14:17:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 14:17:31 -0000 Subject: [GHC] #14331: Overzealous free-floating kind check causes deriving clause to be rejected In-Reply-To: <050.cb87f2a10e38fd0ac57d92b074ac5d5b@haskell.org> References: <050.cb87f2a10e38fd0ac57d92b074ac5d5b@haskell.org> Message-ID: <065.9dc38be91f0af3619a8acbf3c920d6a1@haskell.org> #14331: Overzealous free-floating kind check causes deriving clause to be rejected -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T14331 Blocked By: | Blocking: 15376 Related Tickets: #15376 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): No one has attempted to implemented comment:31, so there's been no progress on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 15:22:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 15:22:09 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.4ad298dcec4c5c16764050311a496c14@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:5 bgamari]: > Actually, I don't think it's true that what suggestion in comment:2 is quite right. The fact that there is a barrier is embodied by the `True` argument of `genLoadW` (which the definition site binds to the name `atomic`). This gets lowered as a `seq_cst` load. Yes, my bad. Sorry for the noise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 15:48:48 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 15:48:48 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.857a92f56586513678968b3ed0484352@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"123aeb916cba93018039e583d42408dae80a6dc9/ghc" 123aeb91/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="123aeb916cba93018039e583d42408dae80a6dc9" Enable two-step allocator on FreeBSD Simplify #ifdef nesting and use MAP_GUARD on FreeBSD and similar systems. This allows the two-step allocator to be used on FreeBSD, fixing #15348. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 15:49:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 15:49:34 -0000 Subject: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls In-Reply-To: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> References: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> Message-ID: <064.3b5f35af3d1e420554205e9f88d95d56@haskell.org> #14346: 8.2.1 regression: heap corruption after safe foreign calls -------------------------------------+------------------------------------- Reporter: andrewchen | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15260 | Differential Rev(s): Phab:D5020 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f8e5da92c0160a675e1666a5d6ed6a8ffcae193c/ghc" f8e5da92/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f8e5da92c0160a675e1666a5d6ed6a8ffcae193c" testsuite: Add test for #14346 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 15:49:51 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 15:49:51 -0000 Subject: [GHC] #15402: The settings and behaviour of idle GC are very confusing In-Reply-To: <042.e4c8b197ac5022919ee692ffbed96a1d@haskell.org> References: <042.e4c8b197ac5022919ee692ffbed96a1d@haskell.org> Message-ID: <057.405bee24cce0dd3c327e86e753561e12@haskell.org> #15402: The settings and behaviour of idle GC are very confusing -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0e34a9f3e77108c5561fb183e59230a2fc3d1615/ghc" 0e34a9f3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0e34a9f3e77108c5561fb183e59230a2fc3d1615" users-guide: Document default +RTS -I value As mentioned in #15402. [no ci] Test Plan: Read it. Reviewers: alpmestan Reviewed By: alpmestan Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15402 Differential Revision: https://phabricator.haskell.org/D5027 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 16:03:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 16:03:41 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.3a3b3282807cb25d287e7e182fd18b06@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Quite alright; you had me excited that this ticket might have an easy resolution afterall. However, given that this is only failing on LLVM/AArch64 it does sound like this is likely an `-fllvm` code generation bug. Doing a careful audit of the code generator's barriers sounds like the best way forward. This is likely wrong on LLVM/x86 as well, but the bug doesn't manifest due to the architecture's strong memory model. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 16:36:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 16:36:14 -0000 Subject: [GHC] #13587: addTopDecls fails with typed Template Haskell In-Reply-To: <048.1e9cb82827e3acfaa8c4e1f0f4c12487@haskell.org> References: <048.1e9cb82827e3acfaa8c4e1f0f4c12487@haskell.org> Message-ID: <063.8ae6c9007dec0e3fcb803e4b3c0d0c33@haskell.org> #13587: addTopDecls fails with typed Template Haskell -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15437 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I have just run into this ticket. Is there anything that can be done to fix it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 17:02:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 17:02:21 -0000 Subject: [GHC] #13587: addTopDecls fails with typed Template Haskell In-Reply-To: <048.1e9cb82827e3acfaa8c4e1f0f4c12487@haskell.org> References: <048.1e9cb82827e3acfaa8c4e1f0f4c12487@haskell.org> Message-ID: <063.ebf596e894551a6ff2e6c89042e0dfe5@haskell.org> #13587: addTopDecls fails with typed Template Haskell -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15437 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It's yet unclear to me why exactly this is failing. (Ben offered some speculation in comment:6, but it would be nice to confirm that this is indeed the case.) Once we have a proper diagnosis as to what the issue is, we can brainstorm possible solutions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 17:17:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 17:17:19 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.08eca4c0404745d7cb350969041471c4@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): One other thought: The code generator offers a write barrier primitive (which is a store-store barrier I think) but no read barrier (load-load barrier). The latter is not required on x86 and SPARC TSO but on PowerPC (and perhaps on ARM as well) read barriers are required in certain circumstances. I started to look into this a while ago but I did not find places where PowerPC would be allowed to reorder reads and would thus read stale data despite the presence of a write barrier on the writing processor. If I remember correctly: In cases where we have a data dependency (following a pointer) or control dependency (conditional branch) no barrier instruction is required on PowerPC. All cases I looked at in the code generator so far were of one these dependencies. But my search was neither systematic nor exhaustive. Unfortunately, I did not take any notes at the time. Note: `includes/stg/SMP.h` offers a load-load barrier for code (C and Cmm) in the RTS. I think it is surprising that ARM 6/7 do not seem to have those issues. The memory consistency model would be the same, wouldn't it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 17:18:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 17:18:14 -0000 Subject: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls In-Reply-To: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> References: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> Message-ID: <064.b65f211970cde70fd4169e205a78ebe1@haskell.org> #14346: 8.2.1 regression: heap corruption after safe foreign calls -------------------------------------+------------------------------------- Reporter: andrewchen | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15260 | Differential Rev(s): Phab:D5020 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Thanks Ben. Could you also merge the test case from ​Phab:D5020 so that it doesn't get lost? Sure. Done in f8e5da92c0160a675e1666a5d6ed6a8ffcae193c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 17:33:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 17:33:52 -0000 Subject: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls In-Reply-To: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> References: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> Message-ID: <064.d596eb4d7965d0cba413f9c0b49b2946@haskell.org> #14346: 8.2.1 regression: heap corruption after safe foreign calls -------------------------------------+------------------------------------- Reporter: andrewchen | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15260 | Differential Rev(s): Phab:D5020 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => closed * resolution: => fixed Comment: Thanks Ben! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 17:39:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 17:39:08 -0000 Subject: [GHC] #15063: T3001-2 fails on i386 Linux In-Reply-To: <046.fa478fb40ce13bbb24172a958e864762@haskell.org> References: <046.fa478fb40ce13bbb24172a958e864762@haskell.org> Message-ID: <061.bee223ed8057b16de21dd53a275abeb6@haskell.org> #15063: T3001-2 fails on i386 Linux -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Profiling | Version: 8.2.2 Resolution: fixed | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15087, #15165, | Differential Rev(s): Phab:D4928 #7836 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in 30a4bcc3fc3a434b3b6ab64289934281591ce09a (present in alpha 2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 17:40:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 17:40:54 -0000 Subject: [GHC] #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints In-Reply-To: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> References: <044.b2fda9f5077d101e5044beb43f714e4c@haskell.org> Message-ID: <059.9bf7a54fb03c516ee54c5b18a1aa1f10@haskell.org> #15316: Regarding coherence and implication loops in presence of QuantifiedConstraints -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: fixed | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: quantified- invalid program | constraints/T15316 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: 8.6.1 => 8.8.1 Comment: Unfortunately this looks to be a bit large to backport to 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 17:41:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 17:41:53 -0000 Subject: [GHC] #15343: Implicitly quantifying a kind variable causes GHC 8.6 to panic (coercionKind) In-Reply-To: <050.0e8877c07406b2b81b1a5431ef627da1@haskell.org> References: <050.0e8877c07406b2b81b1a5431ef627da1@haskell.org> Message-ID: <065.bd66a42cdc746339dd474f6d69c5cc7f@haskell.org> #15343: Implicitly quantifying a kind variable causes GHC 8.6 to panic (coercionKind) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | dependent/should_fail/T15343 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Comment:5 merged in 5b10d537bde8e1c1cf5e0359d38dac7351ae8b2a. Comment:6 merged in cfc4afad16d0eb99d5576cd998bcf473a1bc2af5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 17:45:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 17:45:49 -0000 Subject: [GHC] #15387: Unable to set testsuite verbosity to zero from command line In-Reply-To: <045.1ef98c4634b785a6312d5e3fc14d2d67@haskell.org> References: <045.1ef98c4634b785a6312d5e3fc14d2d67@haskell.org> Message-ID: <060.7b2b1c30d18028ae00afa5dc3a7f7fab@haskell.org> #15387: Unable to set testsuite verbosity to zero from command line -------------------------------------+------------------------------------- Reporter: lantti | Owner: lantti Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Test Suite | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.6` in 655c6175268352f00f142f98a8b58488cc953480 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 18:31:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 18:31:38 -0000 Subject: [GHC] #15461: Machine accessible interface to GHCi Message-ID: <046.c2d301970bbdff7b63fe4e2523868200@haskell.org> #15461: Machine accessible interface to GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For a long time tooling users (e.g. `haskell-mode`) have been treating GHCi as a language server. As one would expect this leads to a frustrating situation for both GHC developers (who feel constrained in their ability to change output) and users (who occasionally suffer breakage, e.g. [[https://github.com/haskell/haskell- mode/issues/1553#issuecomment-409267399]]). Ultimately the solution seems fairly clear: 1. allow GHCi to expose multiple REPL interfaces (e.g. such that a user could have multiple textual REPLs open, all served by the same GHCi session) 2. add a machine-readable request protocol to GHCi, giving tooling users a way to use GHCi's functionality without parsing human-readable output (1) should be fairly straightforward to implement. (2) on the other hand requires some design work (e.g. what does the wire protocol look like?) and a fair bit of refactoring (to expose the existing commands in a machine-readable manner). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 18:34:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 18:34:23 -0000 Subject: [GHC] #15461: Machine accessible interface to GHCi In-Reply-To: <046.c2d301970bbdff7b63fe4e2523868200@haskell.org> References: <046.c2d301970bbdff7b63fe4e2523868200@haskell.org> Message-ID: <061.dce3b700a47b7b61189ffcccbb5d7103@haskell.org> #15461: Machine accessible interface to GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > For a long time tooling users (e.g. `haskell-mode`) have been treating > GHCi as a language server. As one would expect this leads to a > frustrating situation for both GHC developers (who feel constrained in > their ability to change output) and users (who occasionally suffer > breakage, e.g. [[https://github.com/haskell/haskell- > mode/issues/1553#issuecomment-409267399]]). > > Ultimately the solution seems fairly clear: > > 1. allow GHCi to expose multiple REPL interfaces (e.g. such that a user > could have multiple textual REPLs open, all served by the same GHCi > session) > 2. add a machine-readable request protocol to GHCi, giving tooling users > a way to use GHCi's functionality without parsing human-readable output > > (1) should be fairly straightforward to implement. (2) on the other hand > requires some design work (e.g. what does the wire protocol look like?) > and a fair bit of refactoring (to expose the existing commands in a > machine-readable manner). New description: For a long time tooling users (e.g. `haskell-mode`) have been treating GHCi as a language server. As one would expect this leads to a frustrating situation for both GHC developers (who feel constrained in their ability to change output) and users (who occasionally suffer breakage, e.g. [[https://github.com/haskell/haskell- mode/issues/1553#issuecomment-409267399]]). Ultimately the solution seems fairly clear: 1. allow GHCi to expose multiple REPL interfaces (e.g. such that a user could have multiple textual REPLs open, all served by the same GHCi session) 2. add a machine-readable request protocol to GHCi, giving tooling users a way to use GHCi's functionality without parsing human-readable output (1) should be fairly straightforward to implement. There are a few decisions to be made, which will largely be driven by user needs: * what sort of channels do we support (e.g. TCP/IP sockets, Unix domain sockets, only pipes?) * how does one open a new channel? (2) on the other hand requires some design work (e.g. what does the wire protocol look like?) and a fair bit of refactoring (to expose the existing commands in a machine-readable manner). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 18:49:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 18:49:39 -0000 Subject: [GHC] #15461: Machine accessible interface to GHCi In-Reply-To: <046.c2d301970bbdff7b63fe4e2523868200@haskell.org> References: <046.c2d301970bbdff7b63fe4e2523868200@haskell.org> Message-ID: <061.458739dc41fb8f2731b05481ebf69907@haskell.org> #15461: Machine accessible interface to GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > For a long time tooling users (e.g. `haskell-mode`) have been treating > GHCi as a language server. As one would expect this leads to a > frustrating situation for both GHC developers (who feel constrained in > their ability to change output) and users (who occasionally suffer > breakage, e.g. [[https://github.com/haskell/haskell- > mode/issues/1553#issuecomment-409267399]]). > > Ultimately the solution seems fairly clear: > > 1. allow GHCi to expose multiple REPL interfaces (e.g. such that a user > could have multiple textual REPLs open, all served by the same GHCi > session) > 2. add a machine-readable request protocol to GHCi, giving tooling users > a way to use GHCi's functionality without parsing human-readable output > > (1) should be fairly straightforward to implement. There are a few > decisions to be made, which will largely be driven by user needs: > > * what sort of channels do we support (e.g. TCP/IP sockets, Unix domain > sockets, only pipes?) > * how does one open a new channel? > > (2) on the other hand requires some design work (e.g. what does the wire > protocol look like?) and a fair bit of refactoring (to expose the > existing commands in a machine-readable manner). New description: For a long time tooling users (e.g. `haskell-mode`) have been treating GHCi as a language server. As one would expect this leads to a frustrating situation for both GHC developers (who feel constrained in their ability to change output) and users (who occasionally suffer breakage, e.g. [[https://github.com/haskell/haskell- mode/issues/1553#issuecomment-409267399]]). Ultimately the solution seems fairly clear: 1. allow GHCi to expose multiple REPL interfaces (e.g. such that a user could have multiple textual REPLs open, all served by the same GHCi session) 2. add a machine-readable request protocol to GHCi, giving tooling users a way to use GHCi's functionality without parsing human-readable output (1) should be fairly straightforward to implement. There are a few decisions to be made, which will largely be driven by user needs: * what sort of channels do we support (e.g. TCP/IP sockets, Unix domain sockets, only pipes?) * how does one open a new channel? (2) on the other hand requires some design work (e.g. what does the wire protocol look like?) and a fair bit of refactoring (to expose the existing commands in a machine-readable manner). Users of this might include, * [[https://github.com/haskell/haskell-mode/|haskell-mode]] * [[https://github.com/gibiansky/IHaskell|IHaskell]] * Intero? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 18:55:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 18:55:14 -0000 Subject: [GHC] #15461: Machine accessible interface to GHCi In-Reply-To: <046.c2d301970bbdff7b63fe4e2523868200@haskell.org> References: <046.c2d301970bbdff7b63fe4e2523868200@haskell.org> Message-ID: <061.f2e7ae00ffd7987f7db210f11a28218d@haskell.org> #15461: Machine accessible interface to GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > For a long time tooling users (e.g. `haskell-mode`) have been treating > GHCi as a language server. As one would expect this leads to a > frustrating situation for both GHC developers (who feel constrained in > their ability to change output) and users (who occasionally suffer > breakage, e.g. [[https://github.com/haskell/haskell- > mode/issues/1553#issuecomment-409267399]]). > > Ultimately the solution seems fairly clear: > > 1. allow GHCi to expose multiple REPL interfaces (e.g. such that a user > could have multiple textual REPLs open, all served by the same GHCi > session) > 2. add a machine-readable request protocol to GHCi, giving tooling users > a way to use GHCi's functionality without parsing human-readable output > > (1) should be fairly straightforward to implement. There are a few > decisions to be made, which will largely be driven by user needs: > > * what sort of channels do we support (e.g. TCP/IP sockets, Unix domain > sockets, only pipes?) > * how does one open a new channel? > > (2) on the other hand requires some design work (e.g. what does the wire > protocol look like?) and a fair bit of refactoring (to expose the > existing commands in a machine-readable manner). > > Users of this might include, > > * [[https://github.com/haskell/haskell-mode/|haskell-mode]] > * [[https://github.com/gibiansky/IHaskell|IHaskell]] > * Intero? New description: For a long time tooling users (e.g. `haskell-mode`) have been treating GHCi as a language server. As one would expect this leads to a frustrating situation for both GHC developers (who feel constrained in their ability to change output) and users (who occasionally suffer breakage, e.g. [[https://github.com/haskell/haskell- mode/issues/1553#issuecomment-409267399]]). Ultimately the solution seems fairly clear: 1. allow GHCi to expose multiple REPL interfaces (e.g. such that a user could have multiple textual REPLs open, all served by the same GHCi session) 2. add a machine-readable request protocol to GHCi, giving tooling users a way to use GHCi's functionality without parsing human-readable output (1) should be fairly straightforward to implement. There are a few decisions to be made, which will largely be driven by user needs: * what sort of channels do we support (e.g. TCP/IP sockets, Unix domain sockets, only pipes?) * how does one open a new channel? * are the `std{in,out,err}` handles redirected? For instance, if multiple channels request execution of `putStrLn "hello world"` who gets the output? There are three options, a. neither requester gets any output b. both channels get two "hello world" messages c. each channel gets precisely the output from its evaluation (c) would be quite hard to do although an approximation could potentially be accomplished by hacking `GHC.IO.Handle.FD`. (2) on the other hand requires some design work (e.g. what does the wire protocol look like?) and a fair bit of refactoring (to expose the existing commands in a machine-readable manner). == Possible users == Users of this facility might include, * [[https://github.com/haskell/haskell-mode/|haskell-mode]] * [[https://github.com/gibiansky/IHaskell|IHaskell]] * Intero? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 19:05:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 19:05:01 -0000 Subject: [GHC] #15461: Machine accessible interface to GHCi In-Reply-To: <046.c2d301970bbdff7b63fe4e2523868200@haskell.org> References: <046.c2d301970bbdff7b63fe4e2523868200@haskell.org> Message-ID: <061.0b43a9fa876d7955a318699c3d3f08ab@haskell.org> #15461: Machine accessible interface to GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > For a long time tooling users (e.g. `haskell-mode`) have been treating > GHCi as a language server. As one would expect this leads to a > frustrating situation for both GHC developers (who feel constrained in > their ability to change output) and users (who occasionally suffer > breakage, e.g. [[https://github.com/haskell/haskell- > mode/issues/1553#issuecomment-409267399]]). > > Ultimately the solution seems fairly clear: > > 1. allow GHCi to expose multiple REPL interfaces (e.g. such that a user > could have multiple textual REPLs open, all served by the same GHCi > session) > 2. add a machine-readable request protocol to GHCi, giving tooling users > a way to use GHCi's functionality without parsing human-readable output > > (1) should be fairly straightforward to implement. There are a few > decisions to be made, which will largely be driven by user needs: > > * what sort of channels do we support (e.g. TCP/IP sockets, Unix domain > sockets, only pipes?) > * how does one open a new channel? > * are the `std{in,out,err}` handles redirected? For instance, if multiple > channels request execution of `putStrLn "hello world"` who gets the > output? There are three options, > a. neither requester gets any output > b. both channels get two "hello world" messages > c. each channel gets precisely the output from its evaluation > > (c) would be quite hard to do although an approximation could > potentially be accomplished by hacking `GHC.IO.Handle.FD`. > > (2) on the other hand requires some design work (e.g. what does the wire > protocol look like?) and a fair bit of refactoring (to expose the > existing commands in a machine-readable manner). > > == Possible users == > Users of this facility might include, > > * [[https://github.com/haskell/haskell-mode/|haskell-mode]] > * [[https://github.com/gibiansky/IHaskell|IHaskell]] > * Intero? New description: For a long time tooling users (e.g. `haskell-mode`) have been treating GHCi as a language server. As one would expect this leads to a frustrating situation for both GHC developers (who feel constrained in their ability to change output) and users (who occasionally suffer breakage, e.g. [[https://github.com/haskell/haskell- mode/issues/1553#issuecomment-409267399]]). Ultimately the general shape of the solution seems fairly clear: 1. allow GHCi to expose multiple REPL interfaces (e.g. such that a user could have multiple textual REPLs open, all served by the same GHCi session) 2. add a machine-readable request protocol to GHCi, giving tooling users a way to use GHCi's functionality without parsing human-readable output (1) should be fairly straightforward to implement. There are a few decisions to be made, which will largely be driven by user needs: * what sort of channels do we support (e.g. TCP/IP sockets, Unix domain sockets, only pipes?) * how does one open a new channel? * are the `std{in,out,err}` handles redirected? For instance, if multiple channels request execution of `putStrLn "hello world"` who gets the output? There are three options, a. neither requester gets any output b. both channels get two "hello world" messages c. each channel gets precisely the output from its evaluation (c) would be quite hard to do although an approximation could potentially be accomplished by hacking `GHC.IO.Handle.FD`. (2) on the other hand requires some design work (e.g. what does the wire protocol look like?) and a fair bit of refactoring (to expose the existing commands in a machine-readable manner). == Possible users == Users of this facility might include, * [[https://github.com/haskell/haskell-mode/|haskell-mode]] * [[https://github.com/gibiansky/IHaskell|IHaskell]] * Intero? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 19:13:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 19:13:14 -0000 Subject: [GHC] #15461: Machine accessible interface to GHCi In-Reply-To: <046.c2d301970bbdff7b63fe4e2523868200@haskell.org> References: <046.c2d301970bbdff7b63fe4e2523868200@haskell.org> Message-ID: <061.23927ba0c8198b1c47004ce460a86208@haskell.org> #15461: Machine accessible interface to GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): An interim step would be to add tests to ghc/ghci that explicitly exercise the features currently used in haskell-mod and/or Intero, so that we get an early warning on any of these changing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 19:19:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 19:19:42 -0000 Subject: [GHC] #14928: TH eats 50 GB memory when creating ADT with multiple constructors In-Reply-To: <047.b13a12d7e6e4b7703250170f5b54bd52@haskell.org> References: <047.b13a12d7e6e4b7703250170f5b54bd52@haskell.org> Message-ID: <062.1f55b889fe866714a2f1bef174870d20@haskell.org> #14928: TH eats 50 GB memory when creating ADT with multiple constructors -------------------------------------+------------------------------------- Reporter: YitzGale | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by YitzGale): @bgamari Thanks very much for that. Confirming your results: I retested using 8.4.3 and 8.6.0.20180714 from hvr's PPA. On 8.4.3 the bug reproduced with {{{-O1}}} but not with {{{-O0}}}. On 8.6.0.20180714 the bug did not reproduce at all, neither with {{{-O0}}} nor with {{{-O1}}}. And also thanks for your observations about the code generated by {{{mkMessages}}}. I'll report that as a separate issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 19:26:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 19:26:29 -0000 Subject: [GHC] #15388: GHC reports missing INLINABLE pragmas in vector and ghc-prim In-Reply-To: <047.d222f3350c1cc34659805b35239cc71c@haskell.org> References: <047.d222f3350c1cc34659805b35239cc71c@haskell.org> Message-ID: <062.8af8d535c9ed0b581ae4801e66da61b0@haskell.org> #15388: GHC reports missing INLINABLE pragmas in vector and ghc-prim -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by flip101): I'm getting similar/related warnings: {{{ src/Main.hs: warning: Could not specialise imported function ‘ghc- prim-0.5.2.0:GHC.Classes.$w$c==’ when specialising ‘ghc-prim-0.5.2.0:GHC.Classes.$fEq(,)_$c==’ Probable fix: add INLINABLE pragma on ‘ghc- prim-0.5.2.0:GHC.Classes.$w$c==’ src/Main.hs: warning: Could not specialise imported function ‘fromIntegral’ Probable fix: add INLINABLE pragma on ‘fromIntegral’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 20:28:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 20:28:22 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.b79530f141b838075b8ebb19142f064e@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tmobile): If this [https://en.wikipedia.org/wiki/Memory_ordering#In_symmetric_multiprocessing_(SMP)_microprocessor_systems table] is to be trusted, it looks like ARM 7 and PPC allow for the same sorts of load/store reorderings. As far as the difference between 32-bit and 64-bit ARM, the only thing I can guess is that perhaps the smaller ARM chips have much simpler instruction pipelines and don't necessarily perform the allowed reorderings in practice? But I might be missing something. As for x86 it does seem like we're getting away with this because of the stricter memory model. If I'm reading [https://llvm.org/docs/Atomics.html#sequentiallyconsistent this bit] correctly, as a frontend, we shouldn't have to emit any fences to ensure the semantics of `seq_cst`. If the target machine's memory model would require a fence to encode a `load atomic ... seq_cst` then it's on `llc` to emit it, not GHC, right? This seems to be contradicted by this equation in `genCall`: {{{ genCall (PrimTarget MO_WriteBarrier) _ _ = do platform <- getLlvmPlatform if platformArch platform `elem` [ArchX86, ArchX86_64, ArchSPARC] then return (nilOL, []) else barrier }}} Here we implement an arch-specific optimization on our own; I would've expected LLVM to be responsible for that, not GHC. I'm also a bit confused by this equation: {{{ genCall (PrimTarget (MO_AtomicWrite _width)) [] [addr, val] = runStmtsDecls $ do addrVar <- exprToVarW addr valVar <- exprToVarW val let ptrTy = pLift $ getVarType valVar ptrExpr = Cast LM_Inttoptr addrVar ptrTy ptrVar <- doExprW ptrTy ptrExpr statement $ Expr $ AtomicRMW LAO_Xchg ptrVar valVar SyncSeqCst }}} I must be missing some trick here; why isn't this implemented with `store atomic`? There isn't even a constructor for `store atomic` in `LlvmExpression` in `compiler/llvmGen/Llvm/AbsSyn.hs`. I think I'll try the sledgehammer approach of sticking fences before each atomic read and after each atomic write; if the behavior improves at least that's some evidence this is where the issue lies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 20:34:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 20:34:41 -0000 Subject: [GHC] #15428: Oversaturated type family application panicks GHC (piResultTys2) In-Reply-To: <050.3c0a11195082b4606825f1a42a15bbbb@haskell.org> References: <050.3c0a11195082b4606825f1a42a15bbbb@haskell.org> Message-ID: <065.6106a19ed354c4c7d3bd3bd7ed88db55@haskell.org> #15428: Oversaturated type family application panicks GHC (piResultTys2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: TypeInType, | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_compile/T15428 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in a107cced37cb95c661b7c7cca1171b33eedf18a9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 20:35:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 20:35:28 -0000 Subject: [GHC] #15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7 In-Reply-To: <048.2e4683ede5797175b196c3bdda927d9f@haskell.org> References: <048.2e4683ede5797175b196c3bdda927d9f@haskell.org> Message-ID: <063.245d3e1f1eebd43117bf74e6e99c3309@haskell.org> #15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7 -------------------------------------+------------------------------------- Reporter: ki11men0w | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: ghc-pkg | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4917 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with b6a2c0d90ceb1e2d68e9517306671b0c6f6ac7dc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 20:35:48 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 20:35:48 -0000 Subject: [GHC] #15430: Merge llvm fix to ghc-8.6 In-Reply-To: <047.e2f6587a5c3bcdb8c94fc02e2e26f5a5@haskell.org> References: <047.e2f6587a5c3bcdb8c94fc02e2e26f5a5@haskell.org> Message-ID: <062.257a4ac428ba1f4b612f99d053a5e7f2@haskell.org> #15430: Merge llvm fix to ghc-8.6 -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 9a4ac7567835c4ddf90d44500d4be7ddcaef4334. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 20:36:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 20:36:24 -0000 Subject: [GHC] #15349: fixST is a bit wrong In-Reply-To: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> References: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> Message-ID: <060.5a5acb438c4eb22664e631d531eca1ff@haskell.org> #15349: fixST is a bit wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4948 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged comment:10 with 39ab54c969fa5ca58392f039aa8f790932b9257a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 20:36:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 20:36:57 -0000 Subject: [GHC] #15365: Argument-less infix declarations printed without parentheses in -ddump-splices In-Reply-To: <050.44adfa65cdb3af03785c9fae8905524a@haskell.org> References: <050.44adfa65cdb3af03785c9fae8905524a@haskell.org> Message-ID: <065.7931eeb0eac54afd6e4a193c9b22e798@haskell.org> #15365: Argument-less infix declarations printed without parentheses in -ddump- splices -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: monoidal Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4998 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 4c044ed12d1d2e92580b587ae3a5ad001c1e6173. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 20:37:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 20:37:20 -0000 Subject: [GHC] #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions In-Reply-To: <050.6a9e69a1ab3df132884705211545628c@haskell.org> References: <050.6a9e69a1ab3df132884705211545628c@haskell.org> Message-ID: <065.55b0e846bbd9133bbf7fd5a30410df27@haskell.org> #15396: -staticlib is broken on GHC 8.4.3 on Linux under certain conditions -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Linking) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 04805078763d6c7347d4cecf33d7e14099790793. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 20:37:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 20:37:33 -0000 Subject: [GHC] #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. In-Reply-To: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> References: <051.7014a138e5f8b690d0e7df8a5fa0fe08@haskell.org> Message-ID: <066.20758d7dfcd38ff858adb0f0a8a3183b@haskell.org> #15398: GADT deriving Ord generates inaccessible code in a pattern with constructor. -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: deriving, | PatternMatchWarnings Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8128 #8740 | Differential Rev(s): Phab:D4993 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 8bed140099f8ab78e3e728fd2e50dd73d7210e84. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 20:37:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 20:37:54 -0000 Subject: [GHC] #15422: GHCi debugger doesn't see free variables when using ApplicativeDo In-Reply-To: <047.abebc5551ef8954944967449b4712428@haskell.org> References: <047.abebc5551ef8954944967449b4712428@haskell.org> Message-ID: <062.8c1bab9dd84bdffb6aa8d133ff3902f2@haskell.org> #15422: GHCi debugger doesn't see free variables when using ApplicativeDo -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4991 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with d170083be4c8ad0ce6a3d00ce5891341fde774b8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 20:38:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 20:38:09 -0000 Subject: [GHC] #15423: Ungrammatical error message involving a pattern binding In-Reply-To: <050.ebe40367e5b7002505ad9262c3f388cc@haskell.org> References: <050.ebe40367e5b7002505ad9262c3f388cc@haskell.org> Message-ID: <065.94111c96ed1ff57c319e8c5eb1ae6a30@haskell.org> #15423: Ungrammatical error message involving a pattern binding -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4992 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with ff839f20029b7f8742de05f7b49bf4117921db9c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 20:38:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 20:38:24 -0000 Subject: [GHC] #15431: Coercible and Existential types don't play nicely In-Reply-To: <046.f58bd30ad49ea13ff113888a9d6b4132@haskell.org> References: <046.f58bd30ad49ea13ff113888a9d6b4132@haskell.org> Message-ID: <061.f00f51f240f1a960c5b5fb81d2f18097@haskell.org> #15431: Coercible and Existential types don't play nicely -------------------------------------+------------------------------------- Reporter: NioBium | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14333 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 09abd1c420532c4274ddaeb5dfa54d7a9123d172. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 20:38:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 20:38:41 -0000 Subject: [GHC] #15436: Compile-time panic, Prelude.!!: negative index In-Reply-To: <047.11105fbd3a2250b4dd24d6c191fbb08d@haskell.org> References: <047.11105fbd3a2250b4dd24d6c191fbb08d@haskell.org> Message-ID: <062.5d34a3d5398abc6d5b90f466da0d70c1@haskell.org> #15436: Compile-time panic, Prelude.!!: negative index -------------------------------------+------------------------------------- Reporter: pbrisbin | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | simplCore/should_run/T15436 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5008 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 851f3341953587d9fd2e471994b37ad81f132b1a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 20:38:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 20:38:56 -0000 Subject: [GHC] #15451: Fix Git commit ID detection in worktrees In-Reply-To: <045.784f11b7dc6e141f133275a8c4f2c98c@haskell.org> References: <045.784f11b7dc6e141f133275a8c4f2c98c@haskell.org> Message-ID: <060.7a9c477253983400fc8bf479f501639e@haskell.org> #15451: Fix Git commit ID detection in worktrees -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5016 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 2a162ebac445b629b3ba6621ce81a746b5dd98d7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 20:40:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 20:40:33 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.db91352c66b28ebe393910d684a85eb8@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 20:47:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 20:47:31 -0000 Subject: [GHC] #15353: Another Cabal submodule bump In-Reply-To: <057.8f07747ab1b423349609ed5b64e04274@haskell.org> References: <057.8f07747ab1b423349609ed5b64e04274@haskell.org> Message-ID: <072.aab788ce85c0ce10107b043fab75a902@haskell.org> #15353: Another Cabal submodule bump -------------------------------------+------------------------------------- Reporter: | Owner: (none) quasicomputational | Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by quasicomputational): * status: new => closed * resolution: => fixed Comment: Bumped and should be good to go now. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 20:48:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 20:48:17 -0000 Subject: [GHC] #15462: fixST for lazy ST is a bit wrong Message-ID: <045.6347476d51ecc1b73a47e80abf0ca319@haskell.org> #15462: fixST for lazy ST is a bit wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Core | Version: 8.4.3 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: #15349 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- #15349 exposed a problem with repeated computations in invocations of `fixST` that should fail but can instead produce answers or even subvert safe Haskell. That has been fixed for strict `ST`, but not yet for lazy `ST`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 21:06:04 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 21:06:04 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.747f03c2b1382c7384d6deffdd6e8d84@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I really wish `MO_WriteBarrier` had some documentation. I added a comment documenting my understanding in Phab:D5029. It would be good to have more eyes on it. > If I'm reading ​this bit correctly, as a frontend, we shouldn't have to emit any fences to ensure the semantics of seq_cst. If the target machine's memory model would require a fence to encode a load atomic ... seq_cst then it's on llc to emit it, not GHC, right? This seems to be contradicted by this equation in genCall: I agree; I would have thought that we need to pass the barrier to LLVM regardless of whether the hardware requires it; afterall, there is otherwise nothing to stop LLVM's optimiser from violating the barrier. That being said, this clearly isn't the cause of the AArch64 issues. > I think I'll try the sledgehammer approach of sticking fences before each atomic read and after each atomic write; if the behavior improves at least that's some evidence this is where the issue lies. Sounds like a good first step. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 22:08:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 22:08:17 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.e56cc03b0422d3faa5c38fb6c9679f98@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tmobile): Ah, that makes sense. The same section of that same LLVM page says "SequentiallyConsistent operations may not be reordered," but there could be issues if ordinary loads/stores float over `seq_cst` atomic loads/stores, could there not? Still curious about the absence of `store atomic`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 23:12:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 23:12:42 -0000 Subject: [GHC] #11394: Base should use native Win32 IO on Windows In-Reply-To: <046.3c711b381d30e89343445554e3990623@haskell.org> References: <046.3c711b381d30e89343445554e3990623@haskell.org> Message-ID: <061.dd6bff3e9535557617c941295309043a@haskell.org> #11394: Base should use native Win32 IO on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 7.10.3 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: | -------------------------------------+------------------------------------- Comment (by Phyx-): deadlock fixed (turns out to be how the scheduler saves and restores errors in TLS when the haskell threads are scheduled) and timer manager integrated into I/O manager, working on fixing signal handlers and seeing if I can get it to work correctly in cygwin hosts like mintty which have unfortunately become standard. Do still have an issue to fix where there seems to be an outstanding I/O request which never finishes.. I think this might be the `LockFile` request. Need to investigate. Also working on how to implement the non-threaded version. Now that I'm unstuck on the deadlock can make some decent progress again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 23:20:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 23:20:15 -0000 Subject: [GHC] #11394: Base should use native Win32 IO on Windows In-Reply-To: <046.3c711b381d30e89343445554e3990623@haskell.org> References: <046.3c711b381d30e89343445554e3990623@haskell.org> Message-ID: <061.7558402079e89949dea931b3e596725f@haskell.org> #11394: Base should use native Win32 IO on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 7.10.3 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: | -------------------------------------+------------------------------------- Comment (by Phyx-): For the console I/O part I have implemented an alternative interface which is able to handle un-buffered reads. SO that works now as well on Windows. In un-buffered mode with processed inputs turned off, signal handlers won't work, as they'll be placed in the input stream one character at a time. I think this is an acceptable limitation so I won't spend the time to support this for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jul 31 23:23:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 31 Jul 2018 23:23:14 -0000 Subject: [GHC] #13617: GHCi linker does not honor alignment of sections. In-Reply-To: <050.e6156dbdb2fd87e0bc8e4bf60775489f@haskell.org> References: <050.e6156dbdb2fd87e0bc8e4bf60775489f@haskell.org> Message-ID: <065.0bee83d5da22a9457ad05bdc00caa5cf@haskell.org> #13617: GHCi linker does not honor alignment of sections. --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: T13617 Blocked By: | Blocking: Related Tickets: #7134 | Differential Rev(s): Phab:D3915 Wiki Page: | --------------------------------+---------------------------------------- Comment (by Phyx-): Ok, new cleanup of the linker is progressing again. I'm changing the interface to use mmap on Windows as well. and for the trampolines I have a new memory manager that's able to handle the space and mem protection for it and BSS and rest of the RTS to waste less memory. Have plain object files working almost but need to do some work to support archives. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jul 29 01:32:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 29 Jul 2018 01:32:51 -0000 Subject: [GHC] #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 In-Reply-To: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> References: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> Message-ID: <060.f6fded1a393d60ce99d2bd8dda443428@haskell.org> #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 -------------------------------+-------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by angerman): So yes... `c.o` is not causing the error. The dylibs are... GHCI keeps building dylibs and putting the previous ones in as well: {{{ /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc7448_0/libghc_1289.dylib: @rpath/libghc_1289.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1284.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1279.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1274.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1269.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1264.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1259.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1254.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1249.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1244.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1239.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1234.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1229.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1224.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1219.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1214.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1209.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1204.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1199.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1194.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1189.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1184.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1179.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1174.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1169.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1164.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1159.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1154.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1149.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1144.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1139.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1134.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1129.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1124.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1119.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1114.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1109.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1104.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1099.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1094.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1089.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1084.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1079.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1074.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1069.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1064.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1059.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1054.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1049.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1044.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1039.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1034.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1029.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1024.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1019.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1014.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1009.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_1004.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_999.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_994.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_989.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_984.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_979.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_974.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_969.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_964.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_959.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_954.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_949.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_944.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_939.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_934.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_929.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_924.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_919.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_914.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_909.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_904.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_899.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_894.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_889.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_884.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_879.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_874.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_869.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_864.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_859.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_854.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_849.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_844.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_839.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_834.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_829.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_824.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_819.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_814.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_809.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_804.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_799.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_794.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_789.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_784.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_779.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_774.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_769.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_764.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_759.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_754.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_749.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_744.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_739.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_734.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_729.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_724.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_719.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_714.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_709.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_704.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_699.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_694.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_689.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_684.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_679.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_674.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_669.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_664.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_659.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_654.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_649.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_644.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_639.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_634.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_629.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_624.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_619.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_614.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_609.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_604.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_599.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_594.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_589.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_584.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_579.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_574.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_569.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_564.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_559.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_554.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_549.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_544.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_539.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_534.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_529.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_524.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_519.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_514.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_509.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_504.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_499.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_494.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_489.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_484.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_479.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_474.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_469.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_464.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_459.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_454.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_449.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_444.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_439.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_434.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_429.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_424.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_419.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_414.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_409.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_404.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_399.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_394.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_389.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_384.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_379.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_374.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_369.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_364.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_359.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_354.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_349.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_344.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_339.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_334.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_329.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_324.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_319.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_314.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_309.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_304.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_299.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_294.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_289.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_284.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_279.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_274.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_269.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_264.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_259.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_254.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_249.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_244.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_239.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_234.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_229.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_224.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_219.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_214.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_209.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_204.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_199.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_194.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_189.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_184.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_179.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_174.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_169.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_164.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_159.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_154.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_149.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_144.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_139.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_134.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_129.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_124.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_119.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_114.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_109.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_104.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_99.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_94.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_89.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_84.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_79.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_74.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_69.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_64.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_59.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_54.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_49.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_44.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_39.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_34.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_29.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_24.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_19.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_14.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_9.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libghc_4.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/local/opt/ghc/lib/ghc-8.4.3/base-4.11.1.0/libHSbase-4.11.1.0-ghc8.4.3.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/local/opt/ghc/lib/ghc-8.4.3/integer-gmp-1.0.2.0/libHSinteger- gmp-1.0.2.0-ghc8.4.3.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/local/opt/ghc/lib/ghc-8.4.3/ghc-prim-0.5.2.0/libHSghc- prim-0.5.2.0-ghc8.4.3.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2) }}} Here's the madness we do in one of the last invocations: {{{ Prelude Main> Prelude Main> Prelude Main> *** Chasing dependencies: Chasing modules from: !!! Chasing dependencies: finished in 0.04 milliseconds, allocated 0.016 megabytes Stable obj: [] Stable BCO: [] unload: retaining objs [] unload: retaining bcos [] Ready for upsweep [] Upsweep completely successful. *** Chasing dependencies: Chasing modules from: *c.hs !!! Chasing dependencies: finished in 0.24 milliseconds, allocated 0.123 megabytes Stable obj: [] Stable BCO: [] unload: retaining objs [] unload: retaining bcos [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2018-07-28 07:25:07 UTC ms_mod = Main, ms_textual_imps = [(Nothing, Prelude)] ms_srcimps = [] }] compile: input file c.hs *** Checking old interface for Main (use -ddump-hi-diffs for more details): [1 of 1] Compiling Main ( c.hs, c.o ) *** Parser [Main]: !!! Parser [Main]: finished in 0.03 milliseconds, allocated 0.020 megabytes *** Renamer/typechecker [Main]: !!! Renamer/typechecker [Main]: finished in 0.40 milliseconds, allocated 0.330 megabytes *** Desugar [Main]: Result size of Desugar (after optimization) = {terms: 8, types: 5, coercions: 0, joins: 0/0} !!! Desugar [Main]: finished in 0.24 milliseconds, allocated 0.113 megabytes *** Simplifier [Main]: Result size of Simplifier iteration=1 = {terms: 16, types: 9, coercions: 0, joins: 0/0} Result size of Simplifier = {terms: 16, types: 9, coercions: 0, joins: 0/0} !!! Simplifier [Main]: finished in 0.31 milliseconds, allocated 0.178 megabytes *** CoreTidy [Main]: Result size of Tidy Core = {terms: 16, types: 9, coercions: 0, joins: 0/0} !!! CoreTidy [Main]: finished in 0.15 milliseconds, allocated 0.078 megabytes *** CorePrep [Main]: Result size of CorePrep = {terms: 16, types: 9, coercions: 0, joins: 0/0} !!! CorePrep [Main]: finished in 0.12 milliseconds, allocated 0.063 megabytes *** Stg2Stg: *** CodeGen [Main]: !!! CodeGen [Main]: finished in 0.82 milliseconds, allocated 0.188 megabytes *** Assembler: clang -fno-stack-protector -DTABLES_NEXT_TO_CODE -I. -fno-common -U__PIC__ -D__PIC__ -Qunused-arguments -x assembler -c /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0/ghc_4104.s -o c.o Upsweep completely successful. Ok, one module loaded. Prelude Main> *** Parser [source]: !!! Parser [source]: finished in 0.01 milliseconds, allocated 0.012 megabytes *** Desugar: *** Simplify [expr]: !!! Simplify [expr]: finished in 0.15 milliseconds, allocated 0.108 megabytes *** CorePrep [expr]: !!! CorePrep [expr]: finished in 0.05 milliseconds, allocated 0.035 megabytes *** ByteCodeGen [Ghci1]: !!! ByteCodeGen [Ghci1]: finished in 0.13 milliseconds, allocated 0.155 megabytes *** Linker: clang -fno-stack-protector -DTABLES_NEXT_TO_CODE -Wl,-dead_strip_dylibs -dynamiclib -o /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0/libghc_4106.dylib c.o -undefined dynamic_lookup -single_module -install_name '@rpath/libghc_4106.dylib' -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2176 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2171 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2166 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2161 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2156 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2151 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2146 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2141 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2136 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2131 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2126 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2121 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2116 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2111 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2106 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2101 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2096 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2091 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2086 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2081 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2076 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2071 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2066 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2061 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2056 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2051 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2046 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2041 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2036 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2031 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2026 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2021 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2016 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2011 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2006 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_2001 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1996 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1991 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1986 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1981 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1976 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1971 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1966 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1961 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1956 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1951 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1946 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1941 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1936 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1931 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1926 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1921 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1916 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1911 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1906 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1901 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1896 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1891 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1886 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1881 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1876 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1871 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1866 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1861 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1856 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1851 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1846 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1841 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1836 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1831 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1826 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1821 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1816 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1811 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1806 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1801 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1796 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1791 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1786 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1781 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1776 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1771 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1766 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1761 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1756 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1751 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1746 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1741 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1736 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1731 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1726 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1721 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1716 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1711 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1706 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1701 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1696 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1691 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1686 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1681 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1676 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1671 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1666 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1661 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1656 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1651 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1646 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1641 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1636 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1631 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1626 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1621 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1616 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1611 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1606 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1601 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1596 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1591 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1586 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1581 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1576 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1571 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1566 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1561 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1556 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1551 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1546 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1541 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1536 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1531 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1526 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1521 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1516 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1511 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1506 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1501 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1496 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1491 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1486 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1481 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1476 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1471 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1466 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1461 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1456 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1451 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1446 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1441 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1436 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1431 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1426 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1421 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1416 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1411 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1406 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1401 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1396 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1391 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1386 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1381 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1376 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1371 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1366 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1361 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1356 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1351 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1346 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1341 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1336 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1331 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1326 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1321 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1316 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1311 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1306 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1301 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1296 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1291 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1286 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1281 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1276 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1271 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1266 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1261 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1256 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1251 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1246 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1241 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1236 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1231 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1226 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1221 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1216 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1211 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1206 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1201 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1196 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1191 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1186 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1181 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1176 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1171 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1166 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1161 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1156 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1151 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1146 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1141 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1136 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1131 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1126 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1121 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1116 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1111 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1106 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1101 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1096 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1091 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1086 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1081 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1076 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1071 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1066 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1061 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1056 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1051 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1046 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1041 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1036 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1031 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1026 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1021 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1016 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1011 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1006 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1001 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_996 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_991 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_986 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_981 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_976 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_971 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_966 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_961 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_956 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_951 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_946 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_941 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_936 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_931 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_926 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_921 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_916 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_911 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_906 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_901 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_896 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_891 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_886 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_881 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_876 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_871 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_866 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_861 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_856 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_851 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_846 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_841 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_836 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_831 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_826 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_821 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_816 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_811 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_806 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_801 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_796 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_791 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_786 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_781 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_776 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_771 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_766 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_761 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_756 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_751 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_746 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_741 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_736 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_731 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_726 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_721 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_716 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_711 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_706 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_701 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_696 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_691 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_686 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_681 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_676 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_671 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_666 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_661 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_656 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_651 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_646 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_641 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_636 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_631 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_626 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_621 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_616 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_611 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_606 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_601 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_596 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_591 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_586 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_581 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_576 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_571 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_566 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_561 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_556 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_551 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_546 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_541 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_536 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_531 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_526 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_521 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_516 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_511 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_506 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_501 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_496 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_491 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_486 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_481 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_476 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_471 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_466 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_461 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_456 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_451 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_446 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_441 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_436 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_431 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_426 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_421 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_416 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_411 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_406 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_401 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_396 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_391 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_386 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_381 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_376 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_371 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_366 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_361 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_356 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_351 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_346 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_341 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_336 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_331 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_326 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_321 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_316 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_311 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_306 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_301 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_296 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_291 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_286 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_281 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_276 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_271 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_266 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_261 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_256 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_251 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_246 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_241 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_236 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_231 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_226 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_221 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_216 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_211 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_206 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_201 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_196 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_191 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_186 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_181 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_176 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_171 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_166 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_161 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_156 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_151 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_146 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_141 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_136 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_131 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_126 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_121 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_116 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_111 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_106 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_101 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_96 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_91 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_86 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_81 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_76 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_71 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_66 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_61 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_56 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_51 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_46 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_41 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_36 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_31 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_26 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_21 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_16 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_11 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_6 -L/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -Xlinker -rpath -Xlinker /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 -lghc_1 -L/usr/local/Cellar/ghc/8.4.3/lib/ghc-8.4.3/base-4.11.1.0 -Xlinker -rpath -Xlinker /usr/local/Cellar/ghc/8.4.3/lib/ghc-8.4.3/base-4.11.1.0 -L/usr/local/Cellar/ghc/8.4.3/lib/ghc-8.4.3/integer-gmp-1.0.2.0 -Xlinker -rpath -Xlinker /usr/local/Cellar/ghc/8.4.3/lib/ghc-8.4.3/integer- gmp-1.0.2.0 -L/usr/local/Cellar/ghc/8.4.3/libexec/integer-gmp/lib -Xlinker -rpath -Xlinker /usr/local/Cellar/ghc/8.4.3/libexec/integer-gmp/lib -L/usr/local/Cellar/ghc/8.4.3/lib/ghc-8.4.3/ghc-prim-0.5.2.0 -Xlinker -rpath -Xlinker /usr/local/Cellar/ghc/8.4.3/lib/ghc-8.4.3/ghc-prim-0.5.2.0 -L/usr/local/Cellar/ghc/8.4.3/lib/ghc-8.4.3/rts -Xlinker -rpath -Xlinker /usr/local/Cellar/ghc/8.4.3/lib/ghc-8.4.3/rts -lHSbase-4.11.1.0-ghc8.4.3 -lHSinteger-gmp-1.0.2.0-ghc8.4.3 -lHSghc-prim-0.5.2.0-ghc8.4.3 -liconv -lgmp ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0/libghc_4106.dylib, 5): no suitable image found. Did find: /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0/libghc_4106.dylib: malformed mach-o: load commands size (32808) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} as such, we'll run over the load command size limit at some point. The fix could be as easy as adding `-dead_strip_dylibs`. However, even though `-dead_strip_dylibs` does help, the excessive injection of rpath blows up: {{{ /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0/libghc_4106.dylib: Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags 0xfeedfacf 16777223 3 0x00 6 456 32776 0x00100085 Load command 0 cmd LC_SEGMENT_64 cmdsize 232 segname __TEXT vmaddr 0x0000000000000000 vmsize 0x0000000000009000 fileoff 0 filesize 36864 maxprot 0x00000007 initprot 0x00000005 nsects 2 flags 0x0 Section sectname __text segname __TEXT addr 0x0000000000008ff4 size 0x0000000000000000 offset 36852 align 2^0 (1) reloff 0 nreloc 0 flags 0x80000400 reserved1 0 reserved2 0 Section sectname __cstring segname __TEXT addr 0x0000000000008ff4 size 0x000000000000000b offset 36852 align 2^1 (2) reloff 0 nreloc 0 flags 0x00000002 reserved1 0 reserved2 0 Load command 1 cmd LC_SEGMENT_64 cmdsize 152 segname __DATA vmaddr 0x0000000000009000 vmsize 0x0000000000001000 fileoff 36864 filesize 4096 maxprot 0x00000007 initprot 0x00000003 nsects 1 flags 0x0 Section sectname __data segname __DATA addr 0x0000000000009000 size 0x0000000000000060 offset 36864 align 2^3 (8) reloff 0 nreloc 0 flags 0x00000000 reserved1 0 reserved2 0 Load command 2 cmd LC_SEGMENT_64 cmdsize 72 segname __LINKEDIT vmaddr 0x000000000000a000 vmsize 0x0000000000001000 fileoff 40960 filesize 656 maxprot 0x00000007 initprot 0x00000001 nsects 0 flags 0x0 Load command 3 cmd LC_ID_DYLIB cmdsize 56 name @rpath/libghc_4106.dylib (offset 24) time stamp 1 Thu Jan 1 07:30:01 1970 current version 0.0.0 compatibility version 0.0.0 Load command 4 cmd LC_DYLD_INFO_ONLY cmdsize 48 rebase_off 40960 rebase_size 8 bind_off 40968 bind_size 160 weak_bind_off 0 weak_bind_size 0 lazy_bind_off 0 lazy_bind_size 0 export_off 41128 export_size 64 Load command 5 cmd LC_SYMTAB cmdsize 24 symoff 41200 nsyms 11 stroff 41376 strsize 240 Load command 6 cmd LC_DYSYMTAB cmdsize 80 ilocalsym 0 nlocalsym 4 iextdefsym 4 nextdefsym 2 iundefsym 6 nundefsym 5 tocoff 0 ntoc 0 modtaboff 0 nmodtab 0 extrefsymoff 0 nextrefsyms 0 indirectsymoff 0 nindirectsyms 0 extreloff 0 nextrel 0 locreloff 0 nlocrel 0 Load command 7 cmd LC_UUID cmdsize 24 uuid 22EC5006-E685-3B7C-8A63-84B9E2D1DBBD Load command 8 cmd LC_VERSION_MIN_MACOSX cmdsize 16 version 10.12 sdk 10.12 Load command 9 cmd LC_SOURCE_VERSION cmdsize 16 version 0.0 Load command 10 cmd LC_LOAD_DYLIB cmdsize 112 name /usr/local/opt/ghc/lib/ghc-8.4.3/base-4.11.1.0/libHSbase-4.11.1.0-ghc8.4.3.dylib (offset 24) time stamp 2 Thu Jan 1 07:30:02 1970 current version 0.0.0 compatibility version 0.0.0 Load command 11 cmd LC_LOAD_DYLIB cmdsize 112 name /usr/local/opt/ghc/lib/ghc-8.4.3/ghc-prim-0.5.2.0/libHSghc- prim-0.5.2.0-ghc8.4.3.dylib (offset 24) time stamp 2 Thu Jan 1 07:30:02 1970 current version 0.0.0 compatibility version 0.0.0 Load command 12 cmd LC_LOAD_DYLIB cmdsize 56 name /usr/lib/libSystem.B.dylib (offset 24) time stamp 2 Thu Jan 1 07:30:02 1970 current version 1238.60.2 compatibility version 1.0.0 Load command 13 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 14 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 15 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 16 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 17 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 18 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 19 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 20 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 21 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 22 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 23 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 24 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 25 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 26 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 27 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 28 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 29 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 30 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 31 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 32 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 33 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 34 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 35 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 36 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 37 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 38 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 39 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 40 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 41 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 42 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 43 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 44 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 45 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 46 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 47 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 48 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 49 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 50 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 51 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 52 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 53 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 54 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 55 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 56 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 57 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 58 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 59 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 60 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 61 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 62 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 63 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 64 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 65 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 66 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 67 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 68 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 69 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 70 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 71 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 72 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 73 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 74 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 75 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 76 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 77 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 78 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 79 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 80 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 81 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 82 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 83 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 84 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 85 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 86 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 87 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 88 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 89 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 90 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 91 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 92 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 93 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 94 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 95 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 96 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 97 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 98 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 99 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 100 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 101 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 102 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 103 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 104 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 105 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 106 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 107 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 108 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 109 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 110 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 111 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 112 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 113 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 114 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 115 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 116 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 117 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 118 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 119 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 120 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 121 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 122 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 123 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 124 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 125 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 126 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 127 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 128 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 129 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 130 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 131 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 132 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 133 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 134 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 135 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 136 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 137 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 138 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 139 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 140 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 141 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 142 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 143 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 144 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 145 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 146 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 147 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 148 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 149 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 150 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 151 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 152 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 153 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 154 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 155 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 156 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 157 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 158 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 159 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 160 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 161 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 162 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 163 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 164 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 165 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 166 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 167 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 168 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 169 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 170 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 171 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 172 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 173 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 174 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 175 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 176 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 177 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 178 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 179 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 180 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 181 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 182 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 183 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 184 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 185 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 186 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 187 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 188 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 189 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 190 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 191 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 192 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 193 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 194 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 195 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 196 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 197 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 198 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 199 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 200 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 201 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 202 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 203 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 204 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 205 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 206 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 207 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 208 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 209 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 210 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 211 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 212 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 213 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 214 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 215 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 216 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 217 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 218 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 219 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 220 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 221 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 222 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 223 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 224 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 225 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 226 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 227 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 228 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 229 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 230 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 231 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 232 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 233 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 234 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 235 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 236 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 237 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 238 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 239 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 240 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 241 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 242 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 243 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 244 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 245 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 246 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 247 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 248 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 249 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 250 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 251 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 252 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 253 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 254 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 255 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 256 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 257 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 258 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 259 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 260 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 261 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 262 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 263 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 264 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 265 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 266 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 267 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 268 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 269 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 270 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 271 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 272 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 273 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 274 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 275 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 276 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 277 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 278 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 279 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 280 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 281 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 282 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 283 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 284 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 285 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 286 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 287 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 288 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 289 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 290 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 291 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 292 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 293 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 294 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 295 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 296 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 297 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 298 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 299 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 300 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 301 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 302 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 303 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 304 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 305 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 306 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 307 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 308 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 309 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 310 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 311 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 312 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 313 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 314 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 315 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 316 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 317 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 318 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 319 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 320 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 321 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 322 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 323 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 324 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 325 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 326 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 327 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 328 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 329 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 330 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 331 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 332 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 333 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 334 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 335 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 336 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 337 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 338 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 339 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 340 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 341 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 342 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 343 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 344 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 345 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 346 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 347 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 348 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 349 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 350 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 351 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 352 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 353 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 354 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 355 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 356 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 357 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 358 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 359 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 360 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 361 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 362 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 363 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 364 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 365 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 366 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 367 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 368 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 369 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 370 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 371 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 372 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 373 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 374 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 375 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 376 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 377 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 378 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 379 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 380 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 381 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 382 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 383 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 384 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 385 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 386 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 387 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 388 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 389 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 390 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 391 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 392 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 393 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 394 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 395 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 396 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 397 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 398 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 399 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 400 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 401 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 402 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 403 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 404 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 405 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 406 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 407 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 408 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 409 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 410 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 411 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 412 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 413 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 414 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 415 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 416 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 417 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 418 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 419 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 420 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 421 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 422 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 423 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 424 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 425 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 426 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 427 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 428 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 429 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 430 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 431 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 432 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 433 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 434 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 435 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 436 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 437 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 438 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 439 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 440 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 441 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 442 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 443 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 444 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 445 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 446 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 447 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 448 cmd LC_RPATH cmdsize 72 path /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc63089_0 (offset 12) Load command 449 cmd LC_RPATH cmdsize 72 path /usr/local/Cellar/ghc/8.4.3/lib/ghc-8.4.3/base-4.11.1.0 (offset 12) Load command 450 cmd LC_RPATH cmdsize 80 path /usr/local/Cellar/ghc/8.4.3/lib/ghc-8.4.3/integer- gmp-1.0.2.0 (offset 12) Load command 451 cmd LC_RPATH cmdsize 64 path /usr/local/Cellar/ghc/8.4.3/libexec/integer-gmp/lib (offset 12) Load command 452 cmd LC_RPATH cmdsize 72 path /usr/local/Cellar/ghc/8.4.3/lib/ghc-8.4.3/ghc-prim-0.5.2.0 (offset 12) Load command 453 cmd LC_RPATH cmdsize 64 path /usr/local/Cellar/ghc/8.4.3/lib/ghc-8.4.3/rts (offset 12) Load command 454 cmd LC_FUNCTION_STARTS cmdsize 16 dataoff 41192 datasize 8 Load command 455 cmd LC_DATA_IN_CODE cmdsize 16 dataoff 41200 datasize 0 }}} That is ~450 times the same RPATH, and the load command is 74bytes in size so we have ~32400bytes just for storing the identical rpath 450times. That seems quite silly *and* rather esay to fix. I'll give this a try today. Contrary to many, I'm actually happy for apple to have implemented this limit, as it shines a light onto us being stupid in some scenarios. -- Ticket URL: GHC The Glasgow Haskell Compiler