From ghc-devs at haskell.org Fri Sep 1 00:54:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 00:54:18 -0000 Subject: [GHC] #10843: Allow do blocks without dollar signs as arguments In-Reply-To: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> References: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> Message-ID: <064.528a7336396572f096e54fde2117b1dd@haskell.org> #10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11706 | Differential Rev(s): Phab:D1219 Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): Thank you for reminding me! I was waiting for the proposal process to start working and then forgot about this. I'll make a proposal shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 01:51:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 01:51:24 -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.fc3cded81f47848ad70ce62736dfcda8@haskell.org> #14174: GHC panic with TypeInType and type family -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.2.1 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 Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 02:46:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 02:46:31 -0000 Subject: [GHC] #14177: initTc: unsolved constraints Message-ID: <045.c4ef9a98a7bece84da9fc849502a4c08@haskell.org> #14177: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: satnam | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC asked me to report this is a bug... so I am just doing what I am told. ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] cValues_abIT :: t_abIS[tau:1] (CHoleCan: cValues)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 03:54:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 03:54:35 -0000 Subject: [GHC] #11645: Heap profiling - hp2ps: samples out of sequence In-Reply-To: <045.b3866e053eb1eb6cf46e7327a6d7e479@haskell.org> References: <045.b3866e053eb1eb6cf46e7327a6d7e479@haskell.org> Message-ID: <060.2807256427b2e70613c96d2857ecedb6@haskell.org> #11645: Heap profiling - hp2ps: samples out of sequence -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | libraries/hpc/tests/fork/hpc_fork Blocked By: | Blocking: Related Tickets: #664 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): I don't have the `.hp` anymore :( It's been basically a `prof` stage2, compiling a module e.g. Dynflags with `-fllvmng`. Due to the time building ghc takes, I won't be able to reproduce this right away. Eventually I'll probably have to again, when testing the `llvmng` backend. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 10:17:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 10:17:34 -0000 Subject: [GHC] #14152: Float exit paths out of recursive functions In-Reply-To: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> References: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> Message-ID: <061.7039ecb59c0ac4afe5337830fcb45154@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | 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: #14137 #10918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Wow, the results are great! {{{ Nofib allocations Benchmark name previous change now nofib/allocs/fannkuch-redux 870976696 - 99.99% 64728 bytes nofib/allocs/k-nucleotide 1089567552 - 91.74% 89963760 bytes Nofib runtimes Benchmark name previous change now nofib/time/CSD 0.536 - 6.72% 0.5 seconds nofib/time/FS 0.413 - 3.15% 0.4 seconds nofib/time/cryptarithm1 0.529 - 4.91% 0.503 seconds nofib/time/integer 1.562 + 3.01% 1.609 seconds nofib/time/last-piece 0.425 - 3.06% 0.412 seconds }}} Almost too good to be true. I wonder where the bug is… :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 13:15:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 13:15:50 -0000 Subject: [GHC] #14177: initTc: unsolved constraints In-Reply-To: <045.c4ef9a98a7bece84da9fc849502a4c08@haskell.org> References: <045.c4ef9a98a7bece84da9fc849502a4c08@haskell.org> Message-ID: <060.44b8b6eddf1599a95b6d6dc1eb077fc9@haskell.org> #14177: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: satnam | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13106 Comment: Thanks for the bug report. This is a duplicate of #13106, which has been fixed in GHC 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 13:57:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 13:57:05 -0000 Subject: [GHC] #14178: Constant folding bug due to 193664d42dbceadaa1e4689dfa17ff1cf5a405a0 Message-ID: <046.caa4d489565f7da2cc2621e816ebfc71@haskell.org> #14178: Constant folding bug due to 193664d42dbceadaa1e4689dfa17ff1cf5a405a0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Angerman points out on [[https://mail.haskell.org/pipermail/ghc- devs/2017-September/014572.html|ghc-devs]] a rather frightenin-looking regression involving integer constant folding. It seems that 193664d42dbceadaa1e4689dfa17ff1cf5a405a0 flipped the order of arguments in the constant-folding logic for binary-operations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 13:57:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 13:57:35 -0000 Subject: [GHC] #14178: Constant folding bug due to 193664d42dbceadaa1e4689dfa17ff1cf5a405a0 In-Reply-To: <046.caa4d489565f7da2cc2621e816ebfc71@haskell.org> References: <046.caa4d489565f7da2cc2621e816ebfc71@haskell.org> Message-ID: <061.32578bbf536f431cdeba5fcafa68d608@haskell.org> #14178: Constant folding bug due to 193664d42dbceadaa1e4689dfa17ff1cf5a405a0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3904 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3904 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 14:13:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 14:13:11 -0000 Subject: [GHC] #14179: "Conflicting family instance" error pretty prints data family instances poorly Message-ID: <050.3b34f958a96d53100d1cde9c870ee0f4@haskell.org> #14179: "Conflicting family instance" error pretty prints data family instances poorly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This can be observed on GHC 8.0.1 or later: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Bug where data family Fam a data instance Fam Int data instance Fam Int }}} {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:5:15: error: Conflicting family instance declarations: Fam Int = -- Defined at Bug.hs:5:15 Fam Int = -- Defined at Bug.hs:6:15 | 5 | data instance Fam Int | ^^^ }}} Notice how GHC attempts to pretty-print the RHS by using a `=` symbol, but there is no RHS! This gets even more confusing with this program, which requires GHC HEAD: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Bug where data family Fam :: k -> * data instance Fam :: * -> * data instance Fam :: * -> * }}} {{{ $ ghc5/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.3.20170818: 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:15: error: Conflicting family instance declarations: Fam = -- Defined at Bug.hs:6:15 Fam = -- Defined at Bug.hs:7:15 | 6 | data instance Fam :: * -> * | ^^^ }}} Not only is there no RHS, but the kind signatures of each instance aren't printed either. This is an issue, since the entire reason why the two instances conflict are because of their kinds! We should rethink how data family instances are pretty printer here to avoid this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 14:20:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 14:20:48 -0000 Subject: [GHC] #14179: "Conflicting family instance" error pretty prints data family instances poorly In-Reply-To: <050.3b34f958a96d53100d1cde9c870ee0f4@haskell.org> References: <050.3b34f958a96d53100d1cde9c870ee0f4@haskell.org> Message-ID: <065.a03a24f0546c9d2e573bc398392f6f0a@haskell.org> #14179: "Conflicting family instance" error pretty prints data family instances poorly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Indeed, the particular pretty printer that's being used in this error message is really broken. If you give GHC these conflicting instances: {{{#!hs module Bug where data family Fam a data instance Fam [a] where Fam1 :: Fam [Int] Fam2 :: Fam [Bool] data instance Fam [a] where Fam3 :: Fam [a] Fam4 :: Fam [Char] }}} Then the error message will print out information that's just plain wrong: {{{ $ ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:6:15: error: Conflicting family instance declarations: Fam [a] = Fam1 | Fam2 -- Defined at Bug.hs:6:15 Fam [a] = Fam3 | Fam4 -- Defined at Bug.hs:9:15 | 6 | data instance Fam [a] where | ^^^ }}} I use the word "particular" above since the general-purpose data family instance pretty printer actually does the right thing: {{{ λ> :i Fam data family Fam a -- Defined at Bug.hs:5:1 data instance Fam [a] where Fam3 :: Fam [a] Fam4 :: Fam [Char] -- Defined at Bug.hs:11:15 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 14:58:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 14:58:26 -0000 Subject: [GHC] #14171: STM causes program to suddenly exit In-Reply-To: <051.a861f285f45a631468bb590e6c9c6a19@haskell.org> References: <051.a861f285f45a631468bb590e6c9c6a19@haskell.org> Message-ID: <066.f915423887de23010d6fea6449529076@haskell.org> #14171: STM causes program to suddenly exit ----------------------------------+---------------------------------------- Reporter: MichaelBurge | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: Component: libraries/stm | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | 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:"dd643bcc970ac59507cab3b464905050d013b071/ghc" dd643bcc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dd643bcc970ac59507cab3b464905050d013b071" Improve stm haddocks While looking at #14171 I noticed these readability issues. Fix them. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 14:58:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 14:58:26 -0000 Subject: [GHC] #14178: Constant folding bug due to 193664d42dbceadaa1e4689dfa17ff1cf5a405a0 In-Reply-To: <046.caa4d489565f7da2cc2621e816ebfc71@haskell.org> References: <046.caa4d489565f7da2cc2621e816ebfc71@haskell.org> Message-ID: <061.a03975f19db15d7eb311046337551f91@haskell.org> #14178: Constant folding bug due to 193664d42dbceadaa1e4689dfa17ff1cf5a405a0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3904 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8a1de424143f5b75e12976ca739e58fe04ae04d6/ghc" 8a1de424/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8a1de424143f5b75e12976ca739e58fe04ae04d6" Add testcase for #14178 Reviewers: austin Subscribers: rwbarton, thomie GHC Trac Issues: #14178 Differential Revision: https://phabricator.haskell.org/D3905 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 14:58:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 14:58:26 -0000 Subject: [GHC] #14178: Constant folding bug due to 193664d42dbceadaa1e4689dfa17ff1cf5a405a0 In-Reply-To: <046.caa4d489565f7da2cc2621e816ebfc71@haskell.org> References: <046.caa4d489565f7da2cc2621e816ebfc71@haskell.org> Message-ID: <061.ac8b285cc743b7e46c8274de8dbdc58a@haskell.org> #14178: Constant folding bug due to 193664d42dbceadaa1e4689dfa17ff1cf5a405a0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3904 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1f052c50c1bcdfb838774eba5a83ae95a54f4702/ghc" 1f052c5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1f052c50c1bcdfb838774eba5a83ae95a54f4702" Fix order of PrelRule Test Plan: Added testcase in D3905. Reviewers: austin Subscribers: angerman, rwbarton, thomie GHC Trac Issues: #14178 Differential Revision: https://phabricator.haskell.org/D3904 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 14:58:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 14:58:48 -0000 Subject: [GHC] #14178: Constant folding bug due to 193664d42dbceadaa1e4689dfa17ff1cf5a405a0 In-Reply-To: <046.caa4d489565f7da2cc2621e816ebfc71@haskell.org> References: <046.caa4d489565f7da2cc2621e816ebfc71@haskell.org> Message-ID: <061.7a6332b1b4d75bbcb6423e58cf9a4d06@haskell.org> #14178: Constant folding bug due to 193664d42dbceadaa1e4689dfa17ff1cf5a405a0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simpleCore/should_run/T14178 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3904 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * testcase: => simpleCore/should_run/T14178 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 16:26:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 16:26:05 -0000 Subject: [GHC] #14152: Float exit paths out of recursive functions In-Reply-To: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> References: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> Message-ID: <061.1f289b8ee8bbc52d80032aa750f41f13@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | 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: #14137 #10918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Inlining the exit join points in the `"final"` simplifier iteration is not a clear win: {{{ Nofib runtimes Benchmark name previous change now nofib/time/VS 0.372 + 16.13% 0.432 seconds nofib/time/cryptarithm1 0.503 + 4.17% 0.524 seconds nofib/time/k-nucleotide 5.558 - 7.72% 5.129 seconds }}} my theory is that floating exit paths out of tight loops makes tight loops very small which is beneficial for *mumble mumble* weird hardware reasons. (I know, someone needs to look at the code instead of speculating…) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 16:32:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 16:32:45 -0000 Subject: [GHC] #14176: sortOn with tuple of >= 9 Maybe's triggers ghc: panic! with "Simplifier ticks exhausted" In-Reply-To: <045.933d859277c437bbd0633ba0b0a84f5a@haskell.org> References: <045.933d859277c437bbd0633ba0b0a84f5a@haskell.org> Message-ID: <060.d8c7ccec5673e4e8e12ccd8efa87ac54@haskell.org> #14176: sortOn with tuple of >= 9 Maybe's triggers ghc: panic! with "Simplifier ticks exhausted" -------------------------------------+------------------------------------- Reporter: kostmo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: This is no longer reproducible in 8.2.1 (perhaps due to the early inlining that we now do). Moreover, it is expected that GHC's simplifier tick threshold fluctuates a bit across releases for programs like this that produce a significant amount of code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 16:41:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 16:41:18 -0000 Subject: [GHC] #14144: Standardize binary distribution doc files In-Reply-To: <049.d1ba1a61ec88a72418a407b8a6104720@haskell.org> References: <049.d1ba1a61ec88a72418a407b8a6104720@haskell.org> Message-ID: <064.d89bbec7ab09ef407cf86335532ebfd3@haskell.org> #14144: Standardize binary distribution doc files -------------------------------------+------------------------------------- Reporter: patrickdoc | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): That is a good question; it's not clear to me whether these should really be bundled with GHC. However, as we currently ship both I suspect we should include at least their HTML guides; these should be linked to from `docs/index.html.in`. Incidentally, it would be great if `docs/index.html.in` were revamped; it currently looks like it was written in 1991. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 16:57:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 16:57:58 -0000 Subject: [GHC] #12502: Reject wrong find utility In-Reply-To: <044.bf466ae198a25fe9a5df2ca0f70bd734@haskell.org> References: <044.bf466ae198a25fe9a5df2ca0f70bd734@haskell.org> Message-ID: <059.a1eb8a0552fc6388f847d80106f155ee@haskell.org> #12502: Reject wrong find utility -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3907 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3907 * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 17:01:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 17:01:36 -0000 Subject: [GHC] #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. In-Reply-To: <054.2188bb19676a701eab2890d90541afc2@haskell.org> References: <054.2188bb19676a701eab2890d90541afc2@haskell.org> Message-ID: <069.cf83e8600b8c38ebb8adcc17465506c3@haskell.org> #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. -------------------------------------+------------------------------------- Reporter: leftaroundabout | Owner: alekzcb Type: bug | Status: new Priority: low | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: acosh(-1) :: at runtime | Complex Double Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Do let me know if you encounter trouble, alekzcb. Thanks for picking this up! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 17:15:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 17:15:32 -0000 Subject: [GHC] #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. In-Reply-To: <054.2188bb19676a701eab2890d90541afc2@haskell.org> References: <054.2188bb19676a701eab2890d90541afc2@haskell.org> Message-ID: <069.e05d10ef8fb4ac7e9a1520639cd513aa@haskell.org> #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. -------------------------------------+------------------------------------- Reporter: leftaroundabout | Owner: alekzcb Type: bug | Status: new Priority: low | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: acosh(-1) :: at runtime | Complex Double Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alekzcb): Replying to [comment:8 bgamari]: > Do let me know if you encounter trouble, alekzcb. Thanks for picking this up! I believe I have a simple fix for this, but have been wrangling with arcanist for the past day! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 18:11:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 18:11:58 -0000 Subject: [GHC] #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. In-Reply-To: <054.2188bb19676a701eab2890d90541afc2@haskell.org> References: <054.2188bb19676a701eab2890d90541afc2@haskell.org> Message-ID: <069.c994b712505e95f521be2815909f3c08@haskell.org> #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. -------------------------------------+------------------------------------- Reporter: leftaroundabout | Owner: alekzcb Type: bug | Status: new Priority: low | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: acosh(-1) :: at runtime | Complex Double Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Oh no! What are the symptoms? Feel free to drop by `#ghc` on `irc.freenode.net` if you want help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 18:20:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 18:20:26 -0000 Subject: [GHC] #14180: Strange/bad error message binding unboxed type variable Message-ID: <045.2cd418235dffeabd04a0de461895e7c1@haskell.org> #14180: Strange/bad error message binding unboxed type variable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.3 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# language TypeInType, TypeFamilies, MagicHash #-} import GHC.Exts type family MatchInt (f :: Int) :: () where MatchInt ('I# x) = '() }}} produces {{{ :2:59: error: • Couldn't match a lifted type with an unlifted type When matching kinds k0 :: * Int# :: TYPE 'IntRep Expected kind ‘Int#’, but ‘x’ has kind ‘k0’ • In the first argument of ‘ 'I#’, namely ‘x’ In the first argument of ‘MatchInt’, namely ‘( 'I# x)’ In the type family declaration for ‘MatchInt’ }}} If, however, I replace `x` in the pattern with `_`, the type checker is satisfied. If I give it a pattern signature, {{{#!hs MatchInt ('I# (x :: Int#)) = '() }}} I get a different (and equally unhelpful) error message, {{{ • Expecting a lifted type, but ‘Int#’ is unlifted • In the kind ‘Int#’ In the first argument of ‘ 'I#’, namely ‘(x :: Int#)’ In the first argument of ‘MatchInt’, namely ‘( 'I# (x :: Int#))’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 18:21:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 18:21:36 -0000 Subject: [GHC] #14180: Strange/bad error message binding unboxed type variable In-Reply-To: <045.2cd418235dffeabd04a0de461895e7c1@haskell.org> References: <045.2cd418235dffeabd04a0de461895e7c1@haskell.org> Message-ID: <060.f64d045edd359f4316e13a9e958ba1d3@haskell.org> #14180: Strange/bad error message binding unboxed type variable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: goldfire (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 18:38:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 18:38:21 -0000 Subject: [GHC] #12623: Make Harbormaster less terrible in the face of submodule updates In-Reply-To: <046.6ed234b0aab5561063eed563f1a09702@haskell.org> References: <046.6ed234b0aab5561063eed563f1a09702@haskell.org> Message-ID: <061.eac6051920b0e668160d1cfc97897758@haskell.org> #12623: Make Harbormaster less terrible in the face of submodule updates -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: closed Priority: highest | Milestone: Component: Build System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * component: Compiler => Build System Comment: This will be resolved with #13716, the solution to which is imminent. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 18:41:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 18:41:57 -0000 Subject: [GHC] #14013: Bad monads performance In-Reply-To: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> References: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> Message-ID: <061.32c96dd28c68e32e78164070cc58e1fd@haskell.org> #14013: Bad monads performance -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => simonpj * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 19:11:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 19:11:03 -0000 Subject: [GHC] #5553: sendWakeup error in simple test program with MVars and killThread In-Reply-To: <042.59ee379d0a78887aa9f6aa413434e659@haskell.org> References: <042.59ee379d0a78887aa9f6aa413434e659@haskell.org> Message-ID: <057.b3cb7f4598ddfa7e693144b8f78bdf74@haskell.org> #5553: sendWakeup error in simple test program with MVars and killThread -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => fixed Comment: I'm unable to reproduce this in 8.2.1. I think it may have been fixed by d5cd505bc484edee3dbd5d41fb7a27c2e18d528d {{{ Author: Ben Gamari Date: Tue Jan 17 15:52:37 2017 -0500 event manager: Don't worry if attempt to wake dead manager fails This fixes #12038, where the TimerManager would attempt to wake up a manager that was already dead, resulting in setnumcapabilities001 occassionally failing during shutdown with unexpected output on stderr. I'm frankly still not entirely confident in this solution but perhaps it will help to get a few more eyes on this. My hypothesis is that the TimerManager is racing: thread TimerManager worker ------- -------------------- requests that thread manager shuts down begins to clean up, closing eventfd calls wakeManager, which tries to write to closed eventfd To prevent this `wakeManager` will need to synchronize with the TimerManger worker to ensure that the worker doesn't clean up the `Control` while another thread is trying to send a wakeup. However, this would add a bit of overhead on every timer interaction, which feels rather costly for what is really a problem only at shutdown. Moreover, it seems that the event manager (e.g. `GHC.Event.Manager`) is also afflicted by a similar race. This patch instead simply tries to catch the write failure after it has happened and silence it in the case that the fd has vanished. It feels rather hacky but it seems to work. Test Plan: Run `setnumcapabilities001` repeatedly Reviewers: hvr, austin, simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2957 GHC Trac Issues: #12038 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 19:12:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 19:12:51 -0000 Subject: [GHC] #5553: sendWakeup error in simple test program with MVars and killThread In-Reply-To: <042.59ee379d0a78887aa9f6aa413434e659@haskell.org> References: <042.59ee379d0a78887aa9f6aa413434e659@haskell.org> Message-ID: <057.413efe0a00743ad4fbc47b9082363391@haskell.org> #5553: sendWakeup error in simple test program with MVars and killThread -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: #12038 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * related: => #12038 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 19:13:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 19:13:38 -0000 Subject: [GHC] #12038: Shutdown interacts badly with requestSync() In-Reply-To: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> References: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> Message-ID: <062.775fb32d788f4d7386e3b5cf18f420bf@haskell.org> #12038: Shutdown interacts badly with requestSync() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5553 | Differential Rev(s): Phab:D2926 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * related: => #5553 Comment: The fix for this ''appears'' to have fixed #5553 as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 19:14:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 19:14:28 -0000 Subject: [GHC] #12038: Shutdown interacts badly with requestSync() In-Reply-To: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> References: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> Message-ID: <062.7d93580e074c09aeab40e4e9bad48a00@haskell.org> #12038: Shutdown interacts badly with requestSync() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5553 | Differential Rev(s): Phab:D2926 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Well, I guess not the ''fix'' for this, but Ben's patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 20:29:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 20:29:46 -0000 Subject: [GHC] #14152: Float exit paths out of recursive functions In-Reply-To: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> References: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> Message-ID: <061.0d4ec4dbdf81820bc17e7cdee835e3f3@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | 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: #14137 #10918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Wow that's great. I would like to understand what's going on in comment:18. Inlining should simply remove a jump -- and the Cmm passes may well, I believe, do that anyway. As you say, actual insight is needed here! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 20:56:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 20:56:46 -0000 Subject: [GHC] #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. In-Reply-To: <054.2188bb19676a701eab2890d90541afc2@haskell.org> References: <054.2188bb19676a701eab2890d90541afc2@haskell.org> Message-ID: <069.ec4913bda8a7248c47e479f4fdcbd2d9@haskell.org> #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. -------------------------------------+------------------------------------- Reporter: leftaroundabout | Owner: alekzcb Type: bug | Status: new Priority: low | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: acosh(-1) :: at runtime | Complex Double Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alekzcb): Cheers bgamari. Just having a bit of trouble submitting my commit. Not sure if it's an Arcanist or a Windows issue. Or an "ID 10T" issue... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 21:03:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 21:03:28 -0000 Subject: [GHC] #14180: Strange/bad error message binding unboxed type variable In-Reply-To: <045.2cd418235dffeabd04a0de461895e7c1@haskell.org> References: <045.2cd418235dffeabd04a0de461895e7c1@haskell.org> Message-ID: <060.6e384975000a33362d15d33a558e8941@haskell.org> #14180: Strange/bad error message binding unboxed type variable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What do you expect to happen here? We just don't have unboxed ints at the type level. Doubtless the error message could be improved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 21:22:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 21:22:10 -0000 Subject: [GHC] #14180: Strange/bad error message binding unboxed type variable In-Reply-To: <045.2cd418235dffeabd04a0de461895e7c1@haskell.org> References: <045.2cd418235dffeabd04a0de461895e7c1@haskell.org> Message-ID: <060.ce8a4bec03bc614975883efaef917f5d@haskell.org> #14180: Strange/bad error message binding unboxed type variable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:2 simonpj]: > What do you expect to happen here? We just don't have unboxed ints at the type level. Doubtless the error message could be improved. Well, a message to that effect would be much better than what we get now! But I don't have a sufficiently clear sense of exactly what is and is not allowed to write it myself. Something about variables bound in type families not being able to have kinds of kind `TYPE r` unless `r ~ PtrRepLifted`, perhaps? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 1 22:50:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Sep 2017 22:50:15 -0000 Subject: [GHC] #14152: Float exit paths out of recursive functions In-Reply-To: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> References: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> Message-ID: <061.c4e4cecbf121fd1d9eb9a0831480237d@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | 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: #14137 #10918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > As you say, actual insight is needed here! Sigh. It seems that `VS` has identical core. So the difference must be in the libraries, or be completely spurious. But tracking down that requires two new freshly built checkouts and more time, and it might just be spurious… -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 2 00:03:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Sep 2017 00:03:34 -0000 Subject: [GHC] #14171: STM causes program to suddenly exit In-Reply-To: <051.a861f285f45a631468bb590e6c9c6a19@haskell.org> References: <051.a861f285f45a631468bb590e6c9c6a19@haskell.org> Message-ID: <066.5cf7da62016cdf478d3ed65302b91b7a@haskell.org> #14171: STM causes program to suddenly exit ----------------------------------+---------------------------------------- Reporter: MichaelBurge | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: Component: libraries/stm | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by bgamari): I had another quick look at this and believe that the critical mistake is this, {{{ dmdAnal:app dmd = expr = catchRetry# @ () (\ (s_a2KK [Dmd=, OS=OneShot] :: State# RealWorld) -> case readTVar# @ RealWorld @ [Int] ww_s485 s_a2KK of { (# ipv_a2Kl [Dmd=], ipv1_a2Km [Dmd=] #) -> retry# @ () ipv_a2Kl }) fun dmd_ty = arg dmd = arg dmd_ty = ([s485 :-> ], b) res dmd_ty = overall res dmd_ty = b {s485->} }}} Note that `arg dmd_ty` bottoms, due to its use of `retry#`. However, `arg dmd` is `ExnStr` and therefore should catch this bottom. However, `overall res dmd_ty` nevertheless bottoms. I'm not yet sure why, but it's quite intriguing. This all seems quite reminiscentv of #13916, but it doesn't seem to be the same issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 2 01:03:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Sep 2017 01:03:30 -0000 Subject: [GHC] #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. In-Reply-To: <054.2188bb19676a701eab2890d90541afc2@haskell.org> References: <054.2188bb19676a701eab2890d90541afc2@haskell.org> Message-ID: <069.a0d3bd16383144f52dd94e82813c237d@haskell.org> #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. -------------------------------------+------------------------------------- Reporter: leftaroundabout | Owner: alekzcb Type: bug | Status: new Priority: low | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: acosh(-1) :: at runtime | Complex Double Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, I suspect the issue was that alekzcb didn't have an editor in his `PATH`. Unfortunately it seems that arcanist doesn't deal with this terribly gracefully. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 2 05:40:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Sep 2017 05:40:57 -0000 Subject: [GHC] #14181: make test WAY=xxx broken Message-ID: <047.800b3734558383132e123840bac3e5aa@haskell.org> #14181: make test WAY=xxx broken -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.2.1 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: -------------------------------------+------------------------------------- It seems like running {{{ make test WAY=someWay }}} is broken. Looking at the `runtest.py`, it seems that we parse the arguments to the test driver before reading the configuration file (e.g. `config/ghc`), and thus the `--way` flags arguments are not available. E.g. the way options get populated, once the `--config-file` argument is processed. But the argument parser seems to be eager and as such the handling of the `--config-file` happens *after* all of the arguments have been parsed. Therefore the set of available `--way`s are always the empty set. I don't know if python2 was lazy here. But with `python3` using `--way` seems impossible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 2 15:06:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Sep 2017 15:06:30 -0000 Subject: [GHC] #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. In-Reply-To: <054.2188bb19676a701eab2890d90541afc2@haskell.org> References: <054.2188bb19676a701eab2890d90541afc2@haskell.org> Message-ID: <069.20b64390fc2ef457ba64a7dac25bc1ac@haskell.org> #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. -------------------------------------+------------------------------------- Reporter: leftaroundabout | Owner: alekzcb Type: bug | Status: new Priority: low | Milestone: 8.4.1 Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: numrun016 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3916 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: acosh(-1) :: Complex Double => numrun016 * differential: => Phab:D3916 * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 2 15:13:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Sep 2017 15:13:04 -0000 Subject: [GHC] #14181: make test WAY=xxx broken In-Reply-To: <047.800b3734558383132e123840bac3e5aa@haskell.org> References: <047.800b3734558383132e123840bac3e5aa@haskell.org> Message-ID: <062.d343aa48f208366544f0454056be3263@haskell.org> #14181: make test WAY=xxx broken -------------------------------------+------------------------------------- Reporter: angerman | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Test Suite | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3917 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari * differential: => Phab:D3917 * version: 8.2.1 => 8.3 * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 2 16:07:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Sep 2017 16:07:22 -0000 Subject: [GHC] #14017: "make install" with non-standard umask causes bad permission on package.cache In-Reply-To: <042.5806d86f4e310ee9a216a4e21aa656b9@haskell.org> References: <042.5806d86f4e310ee9a216a4e21aa656b9@haskell.org> Message-ID: <057.288df4fdb9f5e34a4f039294a0343f23@haskell.org> #14017: "make install" with non-standard umask causes bad permission on package.cache -------------------------------------+------------------------------------- Reporter: djf | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #13375, #13354, | Differential Rev(s): #13194 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have no idea what specifically changed in 8.2.1 but this certainly worked correctly in 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 2 17:27:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Sep 2017 17:27:16 -0000 Subject: [GHC] #14182: Allow full control over dyn lib names Message-ID: <045.073c1d99e34a3803119019c2f0a9d718@haskell.org> #14182: Allow full control over dyn lib names -------------------------------------+------------------------------------- Reporter: duncan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 8.2.1 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 is related to: * GHC ticket #11587 * Cabal issue https://github.com/haskell/cabal/issues/4263 * Cabal PR https://github.com/haskell/cabal/pull/4656 * Cabal PR https://github.com/haskell/cabal/pull/4426 Currently GHC hard codes the naming convention for shared/dynamic libraries. For example: For `hs-libraries: HScpu-0.1.2-b25995` in the package registration, on ELF GHC uses the name `libHScpu-0.1.2-b2599-ghc8.0.1.so` (and .dynlib on OSX). This naming convention is based on an old assumption that shared libraries would go in a shared `$libdir`, and that all that was needed to ensure uniqueness was the combination of the package id and ghc version. This assumption is very out of date now. Different install schemes are used by different packaging tools (nix style vs classic style) and sometimes we want shared lib dirs and sometimes not, and of course we all know now that a package id is not nearly enough to ensure file names are unique. The obvious solution is for GHC to stop making any unnecessary naming convention assumptions and allow specifying the full library name in the package registration information. We would of course keep the remaining necessary naming convention is the `lib` prefix and `.so`/`.dynlib`/`.dll` suffix, which is the same convention used by the system linker for `-lfoo` vs `libfoo.so`. **So specifically:** * Add a new `dynamic-hs-libraries` (to go along with `hs-libraries`) to the `ghc-pkg` registration information. This naming convention follows the existing `library-dirs` and `dynamic-library-dirs`. * When this field is used then these library names will by used for dynamic linking. For backward compatibility, when this field is not supplied then the existing `-ghc8.0.1` convention is used. While we are at it, we should do the same for the `extra-libraries` and add a `dynamic-extra-libraries`. Note that there is an existing `extra- ghci-libraries` which was added for a similar reason (though prior to ghci switching to dynamic libs by default) because in rare cases the dyn libs are just named differently from the static libs, or occasionally there are extra static vs dynamic libs. For example, `pkg-config` makes a clear distinction between static and dynamic libs (because dynamic libs only need direct deps whereas static needs the full transitive closure). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 2 18:57:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Sep 2017 18:57:33 -0000 Subject: [GHC] #13105: Allow type families in RuntimeReps In-Reply-To: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> References: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> Message-ID: <062.9d37e76ea375c1b6fba4cec217b0efd1@haskell.org> #13105: Allow type families in RuntimeReps -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13105 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by magesh.b): * cc: magesh.b (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 2 19:34:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Sep 2017 19:34:45 -0000 Subject: [GHC] #13885: Template Haskell doesn't freshen GADT type variables properly In-Reply-To: <050.316bfca35535b28b80cdb6a4e733201d@haskell.org> References: <050.316bfca35535b28b80cdb6a4e733201d@haskell.org> Message-ID: <065.b0537ce5f5d372d4aaa46d97e0b27a7a@haskell.org> #13885: Template Haskell doesn't freshen GADT type variables properly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: th/T13885 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3867 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"6330b0b0938bc7b27463b3bbfa0df661e4a966b1/ghc" 6330b0b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6330b0b0938bc7b27463b3bbfa0df661e4a966b1" Document the intricacies of ForallC variable quantification better Summary: I recently (re-)discovered that `ForallC` quantifies different type variables depending on whether `GadtC` is present or not. This is an important enough gotcha where I feel like this fact should also be advertised in the `template-haskell` documentation itself, so this patch does just that. Test Plan: Read it Reviewers: goldfire, austin, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13885 Differential Revision: https://phabricator.haskell.org/D3880 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 2 19:34:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Sep 2017 19:34:45 -0000 Subject: [GHC] #14112: bang patterns on pattern synonyms? (left vs right hand sides) In-Reply-To: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> References: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> Message-ID: <060.45e76820b371adddabd1a54ffe996220@haskell.org> #14112: bang patterns on pattern synonyms? (left vs right hand sides) -------------------------------------+------------------------------------- Reporter: carter | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3896 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"5dd6b13c6e2942976aa3b5f4906ff7d0f959272d/ghc" 5dd6b13c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5dd6b13c6e2942976aa3b5f4906ff7d0f959272d" Disallow bang/lazy patterns in the RHSes of implicitly bidirectional patsyns Summary: GHC was allowing implicitly bidirectional pattern synonyms with bang patterns and irrefutable patterns in the RHS, like so: ```lang=haskell pattern StrictJust a = Just !a ``` This has multiple problems: 1. `Just !a` isn't a valid expression, so it feels strange to allow it in an implicitly bidirectional pattern synonym. 2. `StrictJust` doesn't provide the strictness properties one would expect from a strict constructor. (One could imagine a design where the `StrictJust` builder infers a bang pattern for its pattern variable, but accomplishing this inference in a way that accounts for all possible patterns on the RHS, including other pattern synonyms, is somewhat awkward, so we do not pursue this design.) We nip these issues in the bud by simply disallowing bang/irrefutable patterns on the RHS. Test Plan: make test TEST="T14112 unidir" Reviewers: simonpj, austin, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #14112 Differential Revision: https://phabricator.haskell.org/D3896 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 2 19:34:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Sep 2017 19:34:45 -0000 Subject: [GHC] #14167: GHC often depicts H98 datatypes as GADTs when it shouldn't In-Reply-To: <050.3117bfc6e59410b350950a1fc0feadc9@haskell.org> References: <050.3117bfc6e59410b350950a1fc0feadc9@haskell.org> Message-ID: <065.d8c77a263555741d97643ea3dbcab42e@haskell.org> #14167: GHC often depicts H98 datatypes as GADTs when it shouldn't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: GADTs, | TemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3901 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"8e4229ab3dc3e1717ad557ef00f3518da6b5c523/ghc" 8e4229a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8e4229ab3dc3e1717ad557ef00f3518da6b5c523" Fix #14167 by using isGadtSyntaxTyCon in more places Summary: Two places in GHC effectively attempt to //guess// whether a data type was declared using GADT syntax: 1. When reifying a data type in Template Haskell 2. When pretty-printing a data type (e.g., via `:info` in GHCi) But there's no need for heuristics here, since we have a 100% accurate way to determine whether a data type was declared using GADT syntax: the `isGadtSyntaxTyCon` function! By simply using that as the metric, we obtain far more accurate TH reification and pretty-printing results. This is technically a breaking change, since Template Haskell reification will now reify some data type constructors as `(Rec)GadtC` that it didn't before, and some data type constructors that were previously reified as `(Rec)GadtC` will no longer be reified as such. But it's a very understandable breaking change, since the previous behavior was simply incorrect. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #14167 Differential Revision: https://phabricator.haskell.org/D3901 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 2 19:37:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Sep 2017 19:37:26 -0000 Subject: [GHC] #14112: bang patterns on pattern synonyms? (left vs right hand sides) In-Reply-To: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> References: <045.2fc7857e27ad5103b321b22f7f7b10f2@haskell.org> Message-ID: <060.96a36c9d27a9bc21c315590f7b2bd72b@haskell.org> #14112: bang patterns on pattern synonyms? (left vs right hand sides) -------------------------------------+------------------------------------- Reporter: carter | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyn/should_fail/T14112 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3896 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => patsyn/should_fail/T14112 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 2 19:40:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Sep 2017 19:40:39 -0000 Subject: [GHC] #14167: GHC often depicts H98 datatypes as GADTs when it shouldn't In-Reply-To: <050.3117bfc6e59410b350950a1fc0feadc9@haskell.org> References: <050.3117bfc6e59410b350950a1fc0feadc9@haskell.org> Message-ID: <065.20f79f13c1f7bf75a95acea53ad8ad95@haskell.org> #14167: GHC often depicts H98 datatypes as GADTs when it shouldn't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: GADTs, | TemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3901 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 2 23:03:41 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Sep 2017 23:03:41 -0000 Subject: [GHC] #14183: ghc.exe: addLibrarySearchPath error Message-ID: <048.65b771504971fb74c3ba8deaf145b0d9@haskell.org> #14183: ghc.exe: addLibrarySearchPath error ----------------------------------------+--------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Recently I've removed Haskell Platform 8.0.1 and installed new Platform 8.2.1 Since then, when compiling a module GHC sometimes spits the following messages: {{{ ghc.exe: addLibrarySearchPath: C:\Program Files\Haskell Platform\8.0.1\mingw\lib (Win32 error 3): The system cannot find the path specified. }}} dozens of times in a row. But the compilation succeeds. The directory `C:\Program Files\Haskell Platform\8.0.1\` doesn't exist on my machine. I haven't figured out when exactly this happens but it seems to happen only when the module has Template Haskell splices in it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 2 23:04:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Sep 2017 23:04:37 -0000 Subject: [GHC] #14183: ghc.exe: addLibrarySearchPath error In-Reply-To: <048.65b771504971fb74c3ba8deaf145b0d9@haskell.org> References: <048.65b771504971fb74c3ba8deaf145b0d9@haskell.org> Message-ID: <063.0d25bf5200b931cfc1f2a05ec601d7d1@haskell.org> #14183: ghc.exe: addLibrarySearchPath error ---------------------------------+---------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: | ---------------------------------+---------------------------------------- Description changed by vagarenko: Old description: > Recently I've removed Haskell Platform 8.0.1 and installed new Platform > 8.2.1 > > Since then, when compiling a module GHC sometimes spits the following > messages: > {{{ > ghc.exe: addLibrarySearchPath: C:\Program Files\Haskell > Platform\8.0.1\mingw\lib (Win32 error 3): The system cannot find the path > specified. > }}} > dozens of times in a row. > But the compilation succeeds. > The directory `C:\Program Files\Haskell Platform\8.0.1\` doesn't exist on > my machine. > > I haven't figured out when exactly this happens but it seems to happen > only when the module has Template Haskell splices in it. New description: My OS is Windows 7. Recently I've removed Haskell Platform 8.0.1 and installed new Platform 8.2.1 Since then, when compiling a module GHC sometimes spits the following messages: {{{ ghc.exe: addLibrarySearchPath: C:\Program Files\Haskell Platform\8.0.1\mingw\lib (Win32 error 3): The system cannot find the path specified. }}} dozens of times in a row. But the compilation succeeds. The directory `C:\Program Files\Haskell Platform\8.0.1\` doesn't exist on my machine. I haven't figured out when exactly this happens but it seems to happen only when the module has Template Haskell splices in it. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 3 00:09:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Sep 2017 00:09:09 -0000 Subject: [GHC] #14171: STM causes program to suddenly exit In-Reply-To: <051.a861f285f45a631468bb590e6c9c6a19@haskell.org> References: <051.a861f285f45a631468bb590e6c9c6a19@haskell.org> Message-ID: <066.9f4470f864043cae5456fd265623554d@haskell.org> #14171: STM causes program to suddenly exit ----------------------------------+---------------------------------------- Reporter: MichaelBurge | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: Component: libraries/stm | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by bgamari): I think I see what is going on here: `postProcessDmdResult` looks only for `ThrowsExn` `DmdResult` when computing termination, {{{#!hs postProcessDmdResult :: Str () -> DmdResult -> DmdResult postProcessDmdResult Lazy _ = topRes postProcessDmdResult (Str ExnStr _) ThrowsExn = topRes -- Key point! postProcessDmdResult _ res = res }}} However, the demand being analysed here is `Diverges`, not `ThrowsExn` (again, due to the use of `retry#`). One "solution" here is, {{{#!patch diff --git a/compiler/basicTypes/Demand.hs b/compiler/basicTypes/Demand.hs index dfff0a2c92..f56d28c4a9 100644 --- a/compiler/basicTypes/Demand.hs +++ b/compiler/basicTypes/Demand.hs @@ -1440,6 +1441,7 @@ postProcessDmdType du@(JD { sd = ss }) (DmdType fv _ res_ty) postProcessDmdResult :: Str () -> DmdResult -> DmdResult postProcessDmdResult Lazy _ = topRes postProcessDmdResult (Str ExnStr _) ThrowsExn = topRes -- Key point! +postProcessDmdResult (Str ExnStr _) Diverges = topRes -- Key point! postProcessDmdResult _ res = res }}} This allows the program malfunctioning in this ticket to run as expected. However, it's not clear to me that this is correct: the `ThrowsExn`/`Diverges` distinction isn't defined in the original demand analysis paper nor any of the later papers that I have found. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 3 00:31:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Sep 2017 00:31:13 -0000 Subject: [GHC] #14171: STM causes program to suddenly exit In-Reply-To: <051.a861f285f45a631468bb590e6c9c6a19@haskell.org> References: <051.a861f285f45a631468bb590e6c9c6a19@haskell.org> Message-ID: <066.538389fbf70f6d3d290960360916c62e@haskell.org> #14171: STM causes program to suddenly exit ----------------------------------+---------------------------------------- Reporter: MichaelBurge | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: libraries/stm | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3919 Wiki Page: | ----------------------------------+---------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3919 * milestone: => 8.4.1 Comment: I think the correct fix is Phab:D3919. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 3 00:31:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Sep 2017 00:31:55 -0000 Subject: [GHC] #14171: STM causes program to suddenly exit In-Reply-To: <051.a861f285f45a631468bb590e6c9c6a19@haskell.org> References: <051.a861f285f45a631468bb590e6c9c6a19@haskell.org> Message-ID: <066.4eb54533247a56011f65347fd45ff738@haskell.org> #14171: STM causes program to suddenly exit ----------------------------------+---------------------------------------- Reporter: MichaelBurge | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: libraries/stm | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #8091 | Differential Rev(s): Phab:D3919 Wiki Page: | ----------------------------------+---------------------------------------- Changes (by bgamari): * related: => #8091 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 3 00:39:03 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Sep 2017 00:39:03 -0000 Subject: [GHC] #14183: ghc.exe: addLibrarySearchPath error In-Reply-To: <048.65b771504971fb74c3ba8deaf145b0d9@haskell.org> References: <048.65b771504971fb74c3ba8deaf145b0d9@haskell.org> Message-ID: <063.7f08fe59d702d034e9d2c98d692845a6@haskell.org> #14183: ghc.exe: addLibrarySearchPath error ---------------------------------+---------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * cc: Phyx- (added) * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 3 10:14:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Sep 2017 10:14:44 -0000 Subject: [GHC] #14183: ghc.exe: addLibrarySearchPath error In-Reply-To: <048.65b771504971fb74c3ba8deaf145b0d9@haskell.org> References: <048.65b771504971fb74c3ba8deaf145b0d9@haskell.org> Message-ID: <063.e1e04b376655176f34bf0ff0952c81ae@haskell.org> #14183: ghc.exe: addLibrarySearchPath error ---------------------------------+---------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => invalid Comment: Hi, This isn't a GHC bug. Something external is giving GHC that path as an extra library path. Looking at the install instructions for Platform https://www.haskell.org/platform/windows.html it says to modify your cabal config to add extra library paths. these paths seem to match the format of the one that's giving you the warnings. You need to update your cabal config file to point to your new GHC instead of the old path. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 3 13:46:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Sep 2017 13:46:56 -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.716f53ea0bf058d3f40b1e8287fb7d1b@haskell.org> #14174: GHC panic with TypeInType and type family -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.2.1 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): Here is a simpler way to trigger the same panic {{{ {-# LANGUAGE TypeInType, RankNTypes, KindSignatures, PolyKinds #-} module Foo where data T k (x :: k) = MkT data S x = MkS (T (x Int) x) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 3 13:55:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Sep 2017 13:55:55 -0000 Subject: [GHC] #13481: T12622 fails in ghci way In-Reply-To: <046.f9d04c6c728f8f80bc5f7c5da4765696@haskell.org> References: <046.f9d04c6c728f8f80bc5f7c5da4765696@haskell.org> Message-ID: <061.eb6f85b421abce72f14514379a1134a9@haskell.org> #13481: T12622 fails in ghci way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12622 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'll try to have a look at this on the plane to ICFP. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 3 14:14:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Sep 2017 14:14:15 -0000 Subject: [GHC] #13481: T12622 fails in ghci way In-Reply-To: <046.f9d04c6c728f8f80bc5f7c5da4765696@haskell.org> References: <046.f9d04c6c728f8f80bc5f7c5da4765696@haskell.org> Message-ID: <061.c1d68e39ba68101b92ace61af01db321@haskell.org> #13481: T12622 fails in ghci way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: T12622 Blocked By: | Blocking: Related Tickets: #12622, #12356 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => T12622 * related: #12622 => #12622, #12356 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 3 14:24:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Sep 2017 14:24:00 -0000 Subject: [GHC] #13481: T12622 fails in ghci way In-Reply-To: <046.f9d04c6c728f8f80bc5f7c5da4765696@haskell.org> References: <046.f9d04c6c728f8f80bc5f7c5da4765696@haskell.org> Message-ID: <061.a22f959b859384e2f9a3bfb55282d893@haskell.org> #13481: T12622 fails in ghci way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: T12622 Blocked By: | Blocking: Related Tickets: #12622, #12356 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It looks like the cause here is that we started out with, {{{#!hs main :: IO () [LclIdX] main = break<14>() let { s_a2kk :: StaticPtr (Bool -> Bool) [LclId] s_a2kk = ... } in break<13>(s_a2kk) >>= @ IO GHC.Base.$fMonadIO @ (Bool -> Bool) @ () (break<10>(s_a2kk) lookupKey @ (Bool -> Bool) s_a2kk) (...) }}} But then `FloatOut` floats `s_a2kk` out of the let giving it a new name (`s_s3Sy`) in the process. Somehow `main` then gets partially rewritten to, {{{#!hs main :: IO () [LclIdX] main = break<14>() break<13>(s_s3Sy) >>= @ IO $fMonadIO @ (Bool -> Bool) @ () (break<10>(s_a2kk) lvl_s3Sz) lvl_s3SA }}} Note the mention of `s_a2kk` remaining in `break<10>`, despite the fact that the reference in `break<13>` was correctly renamed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 3 15:13:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Sep 2017 15:13:50 -0000 Subject: [GHC] #13481: T12622 fails in ghci way In-Reply-To: <046.f9d04c6c728f8f80bc5f7c5da4765696@haskell.org> References: <046.f9d04c6c728f8f80bc5f7c5da4765696@haskell.org> Message-ID: <061.fb669505c0621e4c356157862dc19845@haskell.org> #13481: T12622 fails in ghci way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: T12622 Blocked By: | Blocking: Related Tickets: #12622, #12356 | Differential Rev(s): Phab:D3920 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3920 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 3 15:18:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Sep 2017 15:18:32 -0000 Subject: [GHC] #14129: GHC segfaults trying to use ANN code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.348618562e66743b0480359855424811@haskell.org> References: <044.348618562e66743b0480359855424811@haskell.org> Message-ID: <059.4d2fe5d4aeefe1c390e7d4c2c3006d9b@haskell.org> #14129: GHC segfaults trying to use ANN code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari * priority: normal => high * milestone: => 8.4.1 Old description: > ghc: HEAD > > {{{ > module A where > > {-# ANN module "KABOOM" #-} > }}} New description: ghc: HEAD {{{#!hs module A where {-# ANN module "KABOOM" #-} }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 3 16:35:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Sep 2017 16:35:14 -0000 Subject: [GHC] #14096: Residency profiling with eventlog enabled breaks In-Reply-To: <046.b0ac9cb699336e79142ee4ab7e9074ac@haskell.org> References: <046.b0ac9cb699336e79142ee4ab7e9074ac@haskell.org> Message-ID: <061.5264f3e7f04628f3385e2f700fb5e835@haskell.org> #14096: Residency profiling with eventlog enabled breaks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * component: Compiler => Runtime System * milestone: 8.4.1 => 8.2.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 3 16:35:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Sep 2017 16:35:40 -0000 Subject: [GHC] #14017: "make install" with non-standard umask causes bad permission on package.cache In-Reply-To: <042.5806d86f4e310ee9a216a4e21aa656b9@haskell.org> References: <042.5806d86f4e310ee9a216a4e21aa656b9@haskell.org> Message-ID: <057.f093d5892dbbab6c8e29232efbeeec79@haskell.org> #14017: "make install" with non-standard umask causes bad permission on package.cache -------------------------------------+------------------------------------- Reporter: djf | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #13375, #13354, | Differential Rev(s): #13194 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari Comment: Alright, I'll try to look at this on the plane. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 3 18:53:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Sep 2017 18:53:57 -0000 Subject: [GHC] #13956: ghc panic compiling lame-0.1.1 In-Reply-To: <043.8dde961168640f1ce8c112db2b203fa7@haskell.org> References: <043.8dde961168640f1ce8c112db2b203fa7@haskell.org> Message-ID: <058.79d8f9b855879eb36c089be1265922e1@haskell.org> #13956: ghc panic compiling lame-0.1.1 -------------------------------------+------------------------------------- Reporter: uznx | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: Unfortunately I can no longer reproduce this with the final GHC 8.2.1 release. `Codec.Audio.LAME` seems to compile with profiling in around 3 seconds with rather reasonable memory usage on my laptop. This is admittedly a bit surprising as there weren't many relevant changes between -rc3 and final. uznx, can you confirm that this is fixed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 3 18:57:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Sep 2017 18:57:01 -0000 Subject: [GHC] #14184: Examples with language extensions Message-ID: <051.9e55f15094804527538dbcf24bce4abe@haskell.org> #14184: Examples with language extensions -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Are we okay with examples in the GHC user guide uses language extensions? The documentation has [https://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#record-constructors this code] {{{#!hs inc :: Counter a -> Counter a inc (NewCounter x i d t) = NewCounter { _this = i x, _inc = i, _display = d, tag = t } }}} which could be written {{{#!hs inc :: Counter a -> Counter a inc NewCounter{..} = NewCounter{ _this = _inc _this, .. } }}} if we're okay with that tradeoff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 3 19:34:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Sep 2017 19:34:15 -0000 Subject: [GHC] #14096: Residency profiling with eventlog enabled breaks In-Reply-To: <046.b0ac9cb699336e79142ee4ab7e9074ac@haskell.org> References: <046.b0ac9cb699336e79142ee4ab7e9074ac@haskell.org> Message-ID: <061.df534ab5717391b46e22c57deb5cb68a@haskell.org> #14096: Residency profiling with eventlog enabled breaks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3922 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3922 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 3 20:16:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Sep 2017 20:16:26 -0000 Subject: [GHC] #14184: Examples with language extensions In-Reply-To: <051.9e55f15094804527538dbcf24bce4abe@haskell.org> References: <051.9e55f15094804527538dbcf24bce4abe@haskell.org> Message-ID: <066.2229bf85caeb27e1dac15bc79779ca40@haskell.org> #14184: Examples with language extensions -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I personally think that extensions should be used when describing themselves or nearby features, but otherwise avoided in the manual. I also believe that record wildcards are less used than some other extensions and may be unfamiliar to readers. Thus, I advocate not making this change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 3 21:02:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Sep 2017 21:02:31 -0000 Subject: [GHC] #14184: Examples with language extensions In-Reply-To: <051.9e55f15094804527538dbcf24bce4abe@haskell.org> References: <051.9e55f15094804527538dbcf24bce4abe@haskell.org> Message-ID: <066.3da60f2e20f8e161dbd9ae7f0448359d@haskell.org> #14184: Examples with language extensions -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 4 00:46:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Sep 2017 00:46:17 -0000 Subject: [GHC] #14017: "make install" with non-standard umask causes bad permission on package.cache In-Reply-To: <042.5806d86f4e310ee9a216a4e21aa656b9@haskell.org> References: <042.5806d86f4e310ee9a216a4e21aa656b9@haskell.org> Message-ID: <057.91e1ef27bb31172b96a34ebebce35b82@haskell.org> #14017: "make install" with non-standard umask causes bad permission on package.cache -------------------------------------+------------------------------------- Reporter: djf | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #13375, #13354, | Differential Rev(s): #13194 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed the use of `writeFileAtomic` appears to be okay since it uses `openBinaryTempFileWithDefaultPermissions`, which uses a mode of `0666` to create the file. Looks like I'll have to look elsewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 4 08:08:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Sep 2017 08:08:47 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.ec8e41b912a8f608e75dc616c411f7ef@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1241, #2247, | Differential Rev(s): Phab:D69 #8356, #9103, #9227 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:63 goldfire]: > > My understanding of `DysfunctionalDependencies` is much, much simpler: just omit the check that takes place at instance declarations. For example, the following would be accepted: Hereby confirming we can write Richard’s class `Terrible` today [GHC 8.0.1]. Of course not directly like this: > > {{{ > class Terrible a b | a -> b > instance Terrible Int Bool > instance Terrible Int Char > }}} > “Instances inconsistent with Functional Dependency”. But we can abuse GHC’s "bogus consistency check" ticket:10675#comment:15. {{{ {-# LANGUAGE UndecidableInstances, … #-} class Terrible2 a b | a -> b instance {-# OVERLAPS #-} Terrible2 Int Bool instance {-# OVERLAPS #-} (b ~ Char) => Terrible2 Int b }}} If the usage site gives you wanted `b ~ Bool`, this uses the first instance. Otherwise it selects the second instance and improves to `b ~ Char`. > > {{{ > foo :: Terrible a b => a -> b > foo = undefined > }}} > > and we call `show (foo (5 :: Int))`. GHC has to figure out what type the argument to `show` has so it can supply the right `Show` instance. In this case, the type inferred for `foo (5 :: Int)` will either be `Bool` or `Char`, depending on the whims of GHC at the moment. They're called dysfunctional for a reason! > Want to choose one of those instances arbitrarily, in the absence of any wanted for `b`? Then just change the pragmas to `{-# INCOHERENT #-}`. You have more possible instances? Then repeat the trick. Instead of that second instance: {{{ instance {-# INCOHERENT #-} (Terrible3 Int b) => Terrible2 Int b class Terrible3 a b | a -> b instance {-# INCOHERENT #-} Terrible3 Int Char instance {-# INCOHERENT #-} (Terrible4 Int b) => Terrible3 Int b -- context gives you the constructor only? Then you can improve the content: class Terrible4 a b | a -> b instance {-# INCOHERENT #-} (b’ ~ String) => Terrible4 Int (Maybe b’) instance {-# INCOHERENT #-} (Terrible5 Int b) => Terrible4 Int b }}} This is a (verbose) way to achieve a Closed Class. The thing we can’t get is per @Danilo’s O.P. with a free type var: {{{ class Terrible5 a b | a -> b instance {-# INCOHERENT #-} (out ~ (t1 -> t1)) => Terrible5 Int out }}} Too liberal even for the Liberal Coverage Conditions. Perhaps if there’s a known set of choices for `t1` we could write out a class/instance for each? (With a default improvement at the end of the chain.) It's difficult to see this is any genuine variety of `FunDep`. It just evades the error you'd get in `show ( foo (5 :: Int) )` about an ambiguous type. I suppose we're lucky GHC has never applied the rule (from the original FunDeps paper) that if we have `Terrible Int b1` and `Terrible Int b2` then `b1 = b2` (that's identical types, not merely unifiable -- not that they're even unifiable for `Terrible`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 4 11:51:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Sep 2017 11:51:39 -0000 Subject: [GHC] #14017: "make install" with non-standard umask causes bad permission on package.cache In-Reply-To: <042.5806d86f4e310ee9a216a4e21aa656b9@haskell.org> References: <042.5806d86f4e310ee9a216a4e21aa656b9@haskell.org> Message-ID: <057.b0bee996ce0bd5a73856b2347097b946@haskell.org> #14017: "make install" with non-standard umask causes bad permission on package.cache -------------------------------------+------------------------------------- Reporter: djf | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #13375, #13354, | Differential Rev(s): #13194 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Actually, after looking the `umask` documentation more carefully I am even more confused. The mask is applied only to newly created files; this means that essential any file created during installation will need to `chmod` as well to ensure that the mode is set as expected in the event that the user has overridden umask. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 4 12:28:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Sep 2017 12:28:22 -0000 Subject: [GHC] #13105: Allow type families in RuntimeReps In-Reply-To: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> References: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> Message-ID: <062.ec02def6f60bb6aea14aa03d820ae63b@haskell.org> #13105: Allow type families in RuntimeReps -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13105 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by magesh.b): {{{#!haskell class Unbox (t :: *) (r :: TYPE k) | t -> r, r -> t where unbox :: t -> r box :: r -> t instance Unbox Int Int# where unbox (I# i) = i box i = I# i instance Unbox Char Char# where unbox (C# c) = c box c = C# c 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) -- Works fine testInt :: Int testInt = box (unbox 1) -- Throws an error at call site {-error: • Couldn't match a lifted type with an unlifted type When matching the kind of ‘Int#’ • In the expression: box (unbox (1, 'a')) In an equation for ‘testTup’: testTup = box (unbox (1, 'a')) | 168 | testTup = box (unbox (1, 'a')) | ^^^^^^^^^^^^^^^^^^^^ -} testTup :: (Int, Char) testTup = box (unbox (1, 'a')) }}} Does this error related to same bug? Any chance of such code to work in future GHC release or is it fundamentally not possible to have a levity polymorphic class as a constraint in an instance declaration. One of the use case is, above code would have allowed me to pack user defined data type in to highly packed unboxed anonymous record (using nested Unboxed Tuple) making boxing/unboxing first class in GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 4 15:06:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Sep 2017 15:06:07 -0000 Subject: [GHC] #14168: Installing math-functions with GHC-8.2.1 on windows crashed In-Reply-To: <044.4f270678bb008a7a39539de06752d80f@haskell.org> References: <044.4f270678bb008a7a39539de06752d80f@haskell.org> Message-ID: <059.a9b1543fcf6d6ac526939e48c7023a93@haskell.org> #14168: Installing math-functions with GHC-8.2.1 on windows crashed ---------------------------------+---------------------------------------- Reporter: Qinka | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 Qinka): I use the PowerShell, and it is same when I use the cmd. I though this problem is not related to math-function. When I am just trying to install something, there is the same problem: {{{ λ stack install glob-tool --flag glob-auth:client --flag glob- utils:client --stack-yaml stack-8.2.1.yaml WARNING: Ignoring out of range dependency (trusting snapshot over Hackage revisions): Win32-2.5.4.1. mintty requires: <2.5 mintty-0.1.1: configure aeson-1.2.1.0: download aeson-1.2.1.0: configure aeson-1.2.1.0: build Progress: 2/6 -- While building package aeson-1.2.1.0 using: C:\sr\setup-exe-cache\x86_64-windows\Cabal- simple_Z6RU0evB_2.0.0.2_ghc-8.2.1.exe --builddir=.stack-work\dist\e53504d9 build --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 3 Logs have been written to: A:\Glob\.stack-work\logs\aeson-1.2.1.0.log Configuring aeson-1.2.1.0... Preprocessing library for aeson-1.2.1.0.. Building library for aeson-1.2.1.0.. [ 1 of 23] Compiling Data.Aeson.Internal.Functions ( Data\Aeson\Internal\Functions.hs, .stack- work\dist\e53504d9\build\Data\Aeson\Internal\Functions.o ) [ 2 of 23] Compiling Data.Aeson.Parser.UnescapePure ( pure\Data\Aeson\Parser\UnescapePure.hs, .stack- work\dist\e53504d9\build\Data\Aeson\Parser\UnescapePure.o ) [ 3 of 23] Compiling Data.Aeson.Parser.Unescape ( Data\Aeson\Parser\Unescape.hs, .stack- work\dist\e53504d9\build\Data\Aeson\Parser\Unescape.o ) [ 4 of 23] Compiling Data.Aeson.Types.Generic ( Data\Aeson\Types\Generic.hs, .stack- work\dist\e53504d9\build\Data\Aeson\Types\Generic.o ) [ 5 of 23] Compiling Data.Aeson.Types.Internal ( Data\Aeson\Types\Internal.hs, .stack- work\dist\e53504d9\build\Data\Aeson\Types\Internal.o ) [ 6 of 23] Compiling Data.Aeson.Parser.Internal ( Data\Aeson\Parser\Internal.hs, .stack- work\dist\e53504d9\build\Data\Aeson\Parser\Internal.o ) ghc.EXE: internal error: mkPath failed converting char* to wchar_t* (GHC version 8.2.1 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. -- While building package mintty-0.1.1 using: C:\sr\setup-exe-cache\x86_64-windows\Cabal- simple_Z6RU0evB_2.0.0.2_ghc-8.2.1.exe --builddir=.stack-work\dist\e53504d9 configure --with- ghc=C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin\ghc.EXE --with-ghc- pkg=C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin \ghc-pkg.EXE --user --package-db=clear --package-db=global --package- db=C:\sr\snapshots\4c52f22a\pkgdb --libdir=C:\sr\snapshots\4c52f22a\lib --bindir=C:\sr\snapshots\4c52f22a\bin --datadir=C:\sr\snapshots\4c52f22a\share --libexecdir=C:\sr\snapshots\4c52f22a\libexec --sysconfdir=C:\sr\snapshots\4c52f22a\etc --docdir=C:\sr\snapshots\4c52f22a\doc\mintty-0.1.1 --htmldir=C:\sr\snapshots\4c52f22a\doc\mintty-0.1.1 --haddockdir=C:\sr\snapshots\4c52f22a\doc\mintty-0.1.1 --dependency=Win32=Win32-2.5.4.1 --dependency=base=base-4.10.0.0 --dependency=filepath=filepath-1.4.1.2 -f-win32-2-5 --extra-include- dirs=C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\msys2-20161025\mingw64\include --extra-lib- dirs=C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\msys2-20161025\mingw64\lib Process exited with code: ExitFailure 1 Logs have been written to: A:\Glob\.stack-work\logs\mintty-0.1.1.log Configuring mintty-0.1.1... Cabal-simple_Z6RU0evB_2.0.0.2_ghc-8.2.1.exe: Encountered missing dependencies: Win32 <2.5 && ==2.5.4.1 }}} My ghc-8.2.1 was installed via stack. {{{ λ stack --version Version 1.4.0, Git revision e714f1dd3fade19496d91bd6a017e435a96a6bcd x86_64 hpack-0.17.0 }}} I thought my toolchain might be broken. The ghc-8.2.1's "mingw" is replace by the msys2, which was I install with gcc. {{{ λ gcc --version gcc.exe (Rev2, Built by MSYS2 project) 7.1.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. λ which gcc /mingw64/bin/gcc }}} And unfortunately, my cabal a broken. {{{ λ cat .\build.log package: primitive-0.6.2.0 os: windows arch: x86_64 compiler: ghc-8.2.1 client: cabal-install-1.24.0.2 dependencies: base-4.10.0.0 ghc-prim-0.5.1.0 transformers-0.5.2.0 install-outcome: DownloadFailed docs-outcome: NotTried tests-outcome: NotTried package: vector-0.12.0.1 os: windows arch: x86_64 compiler: ghc-8.2.1 client: cabal-install-1.24.0.2 flags: -wall -unsafechecks -internalchecks boundschecks dependencies: base-4.10.0.0 deepseq-1.4.3.0 ghc-prim-0.5.1.0 primitive-0.6.2.0 install-outcome: DependencyFailed primitive-0.6.2.0 docs-outcome: NotTried tests-outcome: NotTried package: vector-th-unbox-0.2.1.6 os: windows arch: x86_64 compiler: ghc-8.2.1 client: cabal-install-1.24.0.2 dependencies: base-4.10.0.0 template-haskell-2.12.0.0 vector-0.12.0.1 install-outcome: DependencyFailed primitive-0.6.2.0 docs-outcome: NotTried tests-outcome: NotTried }}} {{{ λ cabal install math-functions --only-dependencies -v Using a sandbox located at A:\tmp\.cabal-sandbox "C:\Users\qinka\AppData\Roaming\local\bin\c2hs.exe" "--numeric-version" "C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\mingw\bin\gcc.exe" "-dumpversion" looking for tool haddock near compiler in C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin found haddock in C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin\haddock.exe "C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin\haddock.exe" "--version" "C:\Users\qinka\AppData\Roaming\local\bin\happy.exe" "--version" "C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin\hpc.exe" "version" looking for tool hsc2hs near compiler in C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin found hsc2hs in C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin\hsc2hs.exe "C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin\hsc2hs.exe" "--version" "C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin\ghc.exe" "-hide-all-packages" "-c" "C:\Users\qinka\AppData\Local\Temp\4118467.c" "-o" "C:\Users\qinka\AppData\Local\Temp\633426500.o" "C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\mingw\bin\ld.exe" "-x" "-r" "C:\Users\qinka\AppData\Local\Temp\633426500.o" "-o" "C:\Users\qinka\AppData\Local\Temp\1916915724.o" "C:\msys64\mingw64\bin\pkg-config.exe" "--version" "C:\msys64\usr\bin\tar.exe" "--help" Reading installed packages... "C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin \ghc-pkg.exe" "dump" "--package-db=A:\tmp\.cabal-sandbox\x86_64-windows- ghc-8.2.1-packages.conf.d" "-v0" "C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\bin\ghc.exe" "--print-libdir" Found no modified add-source deps. Reading available packages... "C:\msys64\mingw64\bin\pkg-config.exe" "--list-all" "C:\msys64\mingw64\bin\pkg-config.exe" "--modversion" "libtasn1" "zlib" "gobject-introspection-no-export-1.0" "theoraenc" "libecpg_compat" "protobuf" "gio-2.0" "dbus-glib-1" "python-3.6" "libidn" "hogweed" "cairo- gobject" "harfbuzz-icu" "opus" "libpng16" "gstreamer-net-1.0" "geoclue" "dbus-1" "cairo-ps" "gmodule-2.0" "fftw3" "gstreamer-tag-1.0" "p11-kit-1" "glib-2.0" "ImageMagick" "gstreamer-sdp-1.0" "libalpm" "libopenjpwl" "xpm" "python-3.6m" "libopenjp3d" "pango" "MagickCore-7.Q16HDRI" "gdk-win32-2.0" "libturbojpeg" "MagickWand" "fftw3f" "gstreamer-1.0" "panelw" "adwaita- icon-theme" "fftw3l" "json-glib-1.0" "libspdylay" "gnurx" "fftw3q" "libpcrecpp" "gdk-pixbuf-2.0" "pangoft2" "libexslt" "libprotobuf-c" "gmodule-no-export-2.0" "gtksourceview-3.0" "libffi" "orc-0.4" "theoradec" "libcroco-0.6" "libopenjpip" "icu-io" "liblzma" "gtk+-3.0" "lqr-1" "gstreamer-allocators-1.0" "gobject-introspection-1.0" "Magick++" "gtk+-win32-2.0" "javascriptcoregtk-3.0" "gstreamer-plugins-base-1.0" "python-2.7" "lcms2" "gdk-2.0" "isl" "libcares" "libssl" "webkitgtk-3.0" "menuw" "libsoup-2.4" "libxml-2.0" "openssl" "vorbisidec" "cairo-pdf" "minizip" "jasper" "python" "cairo-win32-font" "expat" "gstreamer- base-1.0" "graphite2" "libwebpdecoder" "libwebpmux" "gio-windows-2.0" "gdk-win32-3.0" "ddjvuapi" "gstreamer-app-1.0" "gmodule-export-2.0" "pangocairo" "libjpeg" "vorbisfile" "libpq" "sqlite3" "gnutls" "cairo- win32" "nettle" "pixman-1" "ncurses++w" "gstreamer-check-1.0" "enchant" "gtk+-broadway-3.0" "libpcre16" "gstreamer-controller-1.0" "libtiff-4" "gstreamer-video-1.0" "gobject-2.0" "ImageMagick-7.Q16HDRI" "Magick++-7.Q16HDRI" "libsoup-gnome-2.4" "libpng" "gthread-2.0" "gsl" "libnghttp2" "libecpg" "cairo-fc" "gdk-3.0" "python2" "cairo" "libopenjp2" "gstreamer-fft-1.0" "libpcreposix" "libwebp" "fontconfig" "gtk+-win32-3.0" "libcrypto" "gstreamer-pbutils-1.0" "jansson" "cairo-png" "cairo-ft" "epoxy" "pangowin32" "python3" "vorbisenc" "atk" "gstreamer-rtp-1.0" "bzip2" "ogg" "gdk-broadway-3.0" "MagickWand-7.Q16HDRI" "icu-uc" "cairo- svg" "gstreamer-rtsp-1.0" "regex" "ncursesw" "protobuf-lite" "shared-mime- info" "theora" "vorbis" "harfbuzz" "lzo2" "icu-i18n" "libpgtypes" "libpcre" "cairo-script" "libpcre32" "gstreamer-riff-1.0" "gail-3.0" "gstreamer-audio-1.0" "cairo-tee" "freeglut" "hunspell" "MagickCore" "fribidi" "tre" "freetype2" "librsvg-2.0" "tensorflow" "gtk+-2.0" "gail" "harfbuzz-gobject" "raqm" "libwebpdemux" "libxslt" "bash-completion" "oniguruma" "formw" Choosing modular solver. Resolving dependencies... Notice: installing into a sandbox located at A:\tmp\.cabal-sandbox Ready to install primitive-0.6.2.0 Downloading primitive-0.6.2.0... Waiting for install task to finish... Failed to install primitive-0.6.2.0 Build log ( A:\tmp\.cabal-sandbox\logs\primitive-0.6.2.0.log ): Updating world file... cabal.exe: Error: some packages failed to install: primitive-0.6.2.0 failed while downloading the package. The exception was: connect: failed (Connection timed out (WSAETIMEDOUT)) vector-0.12.0.1 depends on primitive-0.6.2.0 which failed to install. vector-th-unbox-0.2.1.6 depends on primitive-0.6.2.0 which failed to install. }}} When I try to run ghci(8.2.1) {{{ λ ghci -v3 GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 8.2.1, stage 2 booted by GHC version 8.0.2 Using binary package database: C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\lib\package.conf.d\package.cache package flags [] loading package database C:\Users\qinka\AppData\Local\Programs\stack\x86_64-windows\ghc-8.2.1\lib\package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.1.0 wired-in package integer-gmp mapped to integer-gmp-1.0.1.0 wired-in package base mapped to base-4.10.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.12.0.0 wired-in package ghc mapped to ghc-8.2.1 wired-in package dph-seq not found. wired-in package dph-par not found. *** Parser [source]: !!! Parser [source]: finished in 0.00 milliseconds, allocated 0.128 megabytes *** Desugar: *** Simplify [expr]: !!! Simplify [expr]: finished in 0.00 milliseconds, allocated 0.112 megabytes *** CorePrep [expr]: !!! CorePrep [expr]: finished in 0.00 milliseconds, allocated 1.560 megabytes *** ByteCodeGen [Ghci1]: !!! ByteCodeGen [Ghci1]: finished in 0.00 milliseconds, allocated 0.135 megabytes ghc.exe: internal error: mkPath failed converting char* to wchar_t* (GHC version 8.2.1 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 4 15:41:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Sep 2017 15:41:28 -0000 Subject: [GHC] #10833: Use injective type families (decomposition) when dealing with givens In-Reply-To: <048.a87fa063590f3f8feefba56badb8ff21@haskell.org> References: <048.a87fa063590f3f8feefba56badb8ff21@haskell.org> Message-ID: <063.f223348e5ffb0a37bfe9f685798f192f@haskell.org> #10833: Use injective type families (decomposition) when dealing with givens -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Keywords: TypeFamilies, Resolution: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6018, #11511, | Differential Rev(s): #12199 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by nfrisby): * cc: nfrisby (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 4 15:42:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Sep 2017 15:42:24 -0000 Subject: [GHC] #12199: GHC is oblivious to injectivity when solving an equality constraint In-Reply-To: <050.8b18860f28fadb7400553ef29ec1b26c@haskell.org> References: <050.8b18860f28fadb7400553ef29ec1b26c@haskell.org> Message-ID: <065.27ac7ea71687f19b0dd1ae295738f1bd@haskell.org> #12199: GHC is oblivious to injectivity when solving an equality constraint -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeFamilies, Resolution: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10833 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nfrisby): * cc: nfrisby (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 4 15:46:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Sep 2017 15:46:42 -0000 Subject: [GHC] #10833: Use injective type families (decomposition) when dealing with givens In-Reply-To: <048.a87fa063590f3f8feefba56badb8ff21@haskell.org> References: <048.a87fa063590f3f8feefba56badb8ff21@haskell.org> Message-ID: <063.e1423e8714fdf374db889666dc69a257@haskell.org> #10833: Use injective type families (decomposition) when dealing with givens -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Keywords: TypeFamilies, Resolution: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6018, #11511, | Differential Rev(s): #12199 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by nfrisby): This scenario seems like an excellent use-case for a typechecker plugin: so that power users could opt-in to the soundness conjecture. Do we have an estimate of if that's possible give current TC plugin API and how complicated it would be to implement? Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 4 16:12:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Sep 2017 16:12:44 -0000 Subject: [GHC] #10833: Use injective type families (decomposition) when dealing with givens In-Reply-To: <048.a87fa063590f3f8feefba56badb8ff21@haskell.org> References: <048.a87fa063590f3f8feefba56badb8ff21@haskell.org> Message-ID: <063.551916393a378fc7295763acb5512013@haskell.org> #10833: Use injective type families (decomposition) when dealing with givens -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Keywords: TypeFamilies, Resolution: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6018, #11511, | Differential Rev(s): #12199 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I don't see why it wouldn't be possible as a plugin. Shouldn't be all that hard (as plugins go). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 4 16:53:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Sep 2017 16:53:41 -0000 Subject: [GHC] #14183: ghc.exe: addLibrarySearchPath error In-Reply-To: <048.65b771504971fb74c3ba8deaf145b0d9@haskell.org> References: <048.65b771504971fb74c3ba8deaf145b0d9@haskell.org> Message-ID: <063.267f9592c7dd9d17fd4acb0f182cc780@haskell.org> #14183: ghc.exe: addLibrarySearchPath error ---------------------------------+---------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: invalid | 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 vagarenko): **Phyx-**: I've changed paths in cabal config, but the error is still there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 4 18:47:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Sep 2017 18:47:49 -0000 Subject: [GHC] #14183: ghc.exe: addLibrarySearchPath error In-Reply-To: <048.65b771504971fb74c3ba8deaf145b0d9@haskell.org> References: <048.65b771504971fb74c3ba8deaf145b0d9@haskell.org> Message-ID: <063.2c54edabdd8876d2c4fe60c636a5c898@haskell.org> #14183: ghc.exe: addLibrarySearchPath error ---------------------------------+---------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: invalid | 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 vagarenko): If I run `cabal haddock` the error changes to: {{{ haddock.exe: addLibrarySearchPath: C:\Program Files\Haskell Platform\8.0.1\mingw\lib (Win32 error 3): The system cannot find the path specified. }}} Looks like it is a cabal error. I've made an issue in cabal repo: https://github.com/haskell/cabal/issues/4741 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 4 19:09:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Sep 2017 19:09:32 -0000 Subject: [GHC] #14183: ghc.exe: addLibrarySearchPath error In-Reply-To: <048.65b771504971fb74c3ba8deaf145b0d9@haskell.org> References: <048.65b771504971fb74c3ba8deaf145b0d9@haskell.org> Message-ID: <063.8afe20191652b625cc717653a83043f2@haskell.org> #14183: ghc.exe: addLibrarySearchPath error ---------------------------------+---------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: invalid | 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-): I don't think it's a cabal bug. The fact that it's reporting a platform path indicates that it's something platform did or was done after it was install. You must still have a config that points to that path. GHC does infer some paths, but they're always relative to where it was installed. A couple of things to check, 1) check your ghc settings file (should be in your bin or lib folder, a file called Settings). Secondly check your packages, inspect the output of `ghc-pkg dump`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 4 19:22:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Sep 2017 19:22:26 -0000 Subject: [GHC] #14183: ghc.exe: addLibrarySearchPath error In-Reply-To: <048.65b771504971fb74c3ba8deaf145b0d9@haskell.org> References: <048.65b771504971fb74c3ba8deaf145b0d9@haskell.org> Message-ID: <063.cd3066b7d8354dcac9cb384fba5ae8b4@haskell.org> #14183: ghc.exe: addLibrarySearchPath error ---------------------------------+---------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by vagarenko): * Attachment "ghc-pkg dump.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 4 19:23:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Sep 2017 19:23:03 -0000 Subject: [GHC] #14183: ghc.exe: addLibrarySearchPath error In-Reply-To: <048.65b771504971fb74c3ba8deaf145b0d9@haskell.org> References: <048.65b771504971fb74c3ba8deaf145b0d9@haskell.org> Message-ID: <063.8a84a29d08cdc2c22fda70944e24347f@haskell.org> #14183: ghc.exe: addLibrarySearchPath error ---------------------------------+---------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: invalid | 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 vagarenko): `settings` file in `C:\Program Files\Haskell Platform\8.2.1\lib`: {{{ [("GCC extra via C opts", " -fwrapv -fno-builtin"), ("C compiler command", "$topdir/../mingw/bin/gcc.exe"), ("C compiler flags", " -fno-stack-protector"), ("C compiler link flags", " "), ("C compiler supports -no-pie", "YES"), ("Haskell CPP command","$topdir/../mingw/bin/gcc.exe"), ("Haskell CPP flags","-E -undef -traditional"), ("ld command", "$topdir/../mingw/bin/ld.exe"), ("ld flags", ""), ("ld supports compact unwind", "YES"), ("ld supports build-id", "YES"), ("ld supports filelist", "NO"), ("ld is GNU ld", "YES"), ("ar command", "$topdir/../mingw/bin/ar.exe"), ("ar flags", "q"), ("ar supports at file", "YES"), ("touch command", "$topdir/bin/touchy.exe"), ("dllwrap command", "$topdir/../mingw/bin/dllwrap.exe"), ("windres command", "$topdir/../mingw/bin/windres.exe"), ("libtool command", ""), ("perl command", "$topdir/../perl/perl.exe"), ("cross compiling", "NO"), ("target os", "OSMinGW32"), ("target arch", "ArchX86_64"), ("target word size", "8"), ("target has GNU nonexec stack", "False"), ("target has .ident directive", "True"), ("target has subsections via symbols", "False"), ("target has RTS linker", "YES"), ("Unregisterised", "NO"), ("LLVM llc command", "llc"), ("LLVM opt command", "opt") ] }}} `ghc-pkg dump` has no references to `Haskell Platform\8.0.1` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 4 19:28:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Sep 2017 19:28:36 -0000 Subject: [GHC] #14183: ghc.exe: addLibrarySearchPath error In-Reply-To: <048.65b771504971fb74c3ba8deaf145b0d9@haskell.org> References: <048.65b771504971fb74c3ba8deaf145b0d9@haskell.org> Message-ID: <063.d564c7d84858c89515d7c33725cb192d@haskell.org> #14183: ghc.exe: addLibrarySearchPath error ---------------------------------+---------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: invalid | 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 vagarenko): Oh wait when I run `cabal exec ghc-pkg dump` (I'm working in a cabal sandbox) it has a lot of references to `Haskell Platform\8.0.1` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 4 19:34:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Sep 2017 19:34:44 -0000 Subject: [GHC] #14183: ghc.exe: addLibrarySearchPath error In-Reply-To: <048.65b771504971fb74c3ba8deaf145b0d9@haskell.org> References: <048.65b771504971fb74c3ba8deaf145b0d9@haskell.org> Message-ID: <063.3666a4121c016bdc2418110bd3011e1b@haskell.org> #14183: ghc.exe: addLibrarySearchPath error ---------------------------------+---------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: invalid | 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-): You probably have to re-create your sandbox. The sandboxes are a snapshot in time so they would maintain reconfigured data. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 4 19:45:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Sep 2017 19:45:30 -0000 Subject: [GHC] #14168: Installing math-functions with GHC-8.2.1 on windows crashed In-Reply-To: <044.4f270678bb008a7a39539de06752d80f@haskell.org> References: <044.4f270678bb008a7a39539de06752d80f@haskell.org> Message-ID: <059.2e41d9c59df40287c1d1378ede3e41e2@haskell.org> #14168: Installing math-functions with GHC-8.2.1 on windows crashed ---------------------------------+---------------------------------------- Reporter: Qinka | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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-): Not all of those failures are the same, also your system gcc doesn't matter, the path to the one ghc uses is decided by the settings file, so it won't by default care aboutt what's on your path. Can you try reinstalling the compiler? if it still fails, I'll have to create a special version of 8.2.1 for you to get some more information. Unfortunately I didn't put the path information in the error message, and without a debug build of the compiler you can't generate very useful logs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 4 19:49:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Sep 2017 19:49:06 -0000 Subject: [GHC] #14183: ghc.exe: addLibrarySearchPath error In-Reply-To: <048.65b771504971fb74c3ba8deaf145b0d9@haskell.org> References: <048.65b771504971fb74c3ba8deaf145b0d9@haskell.org> Message-ID: <063.81128a69b29b33d78598fa94e63bbe68@haskell.org> #14183: ghc.exe: addLibrarySearchPath error ---------------------------------+---------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: invalid | 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 vagarenko): Yes, after re-creating the sandbox, the error disappeared. Thanks for your help! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 4 21:29:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Sep 2017 21:29:56 -0000 Subject: [GHC] #13105: Allow type families in RuntimeReps In-Reply-To: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> References: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> Message-ID: <062.82f0efb2fb9832a7263a0d8a52f750e8@haskell.org> #13105: Allow type families in RuntimeReps -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13105 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vagarenko): * cc: vagarenko (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 4 21:40:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Sep 2017 21:40:23 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.0ad41800d4a78ea92e213408fe5f148d@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12980 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vagarenko): * cc: vagarenko (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 4 22:15:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Sep 2017 22:15:04 -0000 Subject: [GHC] #14152: Float exit paths out of recursive functions In-Reply-To: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> References: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> Message-ID: <061.f6487e50d28b5ecab3f430d308cd2518@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | 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: #14137 #10918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Some of these measurements seem to be unreliably, in particular `time/VS`. Right now the whole branch, including inlining them back in the end, yields this: {{{ Nofib allocations Benchmark name previous change now nofib/allocs/fannkuch-redux 870976696 - 99.99% 64700 bytes nofib/allocs/k-nucleotide 1089567552 - 91.78% 89603872 bytes Nofib runtimes Benchmark name previous change now nofib/time/CSD 0.536 - 8.02% 0.493 seconds nofib/time/cryptarithm1 0.529 - 4.73% 0.504 seconds nofib/time/digits-of-e1 0.704 - 3.27% 0.681 seconds nofib/time/fannkuch-redux 4.401 + 3.84% 4.57 seconds nofib/time/integer 1.562 + 3.59% 1.618 seconds nofib/time/k-nucleotide 5.426 - 6.28% 5.085 seconds }}} The effect of just the inlining patch is {{{ Nofib runtimes Benchmark name previous change now nofib/time/VS 0.442 - 17.19% 0.366 seconds nofib/time/digits-of-e1 0.704 - 3.27% 0.681 seconds nofib/time/k-nucleotide 5.585 - 8.95% 5.085 seconds }}} That the inlining patch has not changed over the version in comment:18, it was just rebased onto a slightly improved exitification patch, yet the runtime of `VS` now ''improves'' by 17% rather than regress by 16%. I draw this conclusion: There is some sensitivity to layout in `SD` that seems to be tickled by my changes in a non-systematic way. I might have a closer look at the regressions (and gains), but not sure if ICFP is the right time to do that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 4 23:05:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Sep 2017 23:05:54 -0000 Subject: [GHC] #14185: Non-local bug reporting around levity polymorphism Message-ID: <047.b7b54b9f6935b8234dc0884836db560a@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 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism, | TypeErrorMessages | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From comment:12:ticket:13105. In HEAD (or, at least, my version, on the `wip/rae` branch), this code {{{#!hs class Unbox (t :: *) (r :: TYPE k) | t -> r, r -> t where unbox :: t -> r box :: r -> t instance Unbox Int Int# where unbox (I# i) = i box i = I# i instance Unbox Char Char# where unbox (C# c) = c box c = C# c 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) testInt :: Int testInt = box (unbox 1) testTup :: (Int, Char) testTup = box (unbox (1, 'a')) }}} fails with {{{ Bug.hs:27:11: error: • Couldn't match a lifted type with an unlifted type When matching types a' :: * Int# :: TYPE 'IntRep • In the expression: box (unbox 1) In an equation for ‘testInt’: testInt = box (unbox 1) | 27 | testInt = box (unbox 1) | ^^^^^^^^^^^^^ Bug.hs:27:16: error: • Couldn't match a lifted type with an unlifted type When matching types a' :: * Int# :: TYPE 'IntRep • In the first argument of ‘box’, namely ‘(unbox 1)’ In the expression: box (unbox 1) In an equation for ‘testInt’: testInt = box (unbox 1) | 27 | testInt = box (unbox 1) | ^^^^^^^ Bug.hs:42:11: error: • Couldn't match a lifted type with an unlifted type When matching types a' :: * Int# :: TYPE 'IntRep • In the expression: box (unbox (1, 'a')) In an equation for ‘testTup’: testTup = box (unbox (1, 'a')) | 42 | testTup = box (unbox (1, 'a')) | ^^^^^^^^^^^^^^^^^^^^ }}} I think it should succeed. Worse, when I comment out the `testTup` definition, the file succeeds... but note that two of the errors above are in `testInt`, which compiles fine on its own. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 4 23:06:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Sep 2017 23:06:16 -0000 Subject: [GHC] #13105: Allow type families in RuntimeReps In-Reply-To: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> References: <047.a8ba1e3e0326b5d11d717038809a59a9@haskell.org> Message-ID: <062.d9df5c6c98c358aa77ebd9cfae815f4e@haskell.org> #13105: Allow type families in RuntimeReps -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13105 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): comment:12 seems unrelated, but is problematic. See #14185. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 04:06:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 04:06:53 -0000 Subject: [GHC] #13397: Optimise calls to tagToEnum# In-Reply-To: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> References: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> Message-ID: <061.73c03ce2e42ad8840e71b10e1e1a77dd@haskell.org> #13397: Optimise calls to tagToEnum# -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: datacon-tags Operating System: 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): Simon's `caseRules` re-engineering was merged in 193664d42dbceadaa1e4689dfa17ff1cf5a405a0 {{{ commit 193664d42dbceadaa1e4689dfa17ff1cf5a405a0 Author: Simon Peyton Jones Date: Wed Mar 8 10:26:47 2017 +0000 Re-engineer caseRules to add tagToEnum/dataToTag See Note [Scrutinee Constant Folding] in SimplUtils * Add cases for tagToEnum and dataToTag. This is the main new bit. It allows the simplifier to remove the pervasive uses of case tagToEnum (a > b) of False -> e1 True -> e2 and replace it by the simpler case a > b of DEFAULT -> e1 1# -> e2 See Note [caseRules for tagToEnum] and Note [caseRules for dataToTag] in PrelRules. * This required some changes to the API of caseRules, and hence to code in SimplUtils. See Note [Scrutinee Constant Folding] in SimplUtils. * Avoid duplication of work in the (unusual) case of case BIG + 3# of b DEFAULT -> e1 6# -> e2 Previously we got case BIG of DEFAULT -> let b = BIG + 3# in e1 3# -> let b = 6# in e2 Now we get case BIG of b# DEFAULT -> let b = b' + 3# in e1 3# -> let b = 6# in e2 * Avoid duplicated code in caseRules A knock-on refactoring: * Move Note [Word/Int underflow/overflow] to Literal, as documentation to accompany mkMachIntWrap etc; and get rid of PrelRuls.intResult' in favour of mkMachIntWrap }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 04:07:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 04:07:20 -0000 Subject: [GHC] #13397: Optimise calls to tagToEnum# In-Reply-To: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> References: <046.429e0ae0551e63067642e3cbde6e3fef@haskell.org> Message-ID: <061.45c2058fdcc5f963da57c245b45c8b13@haskell.org> #13397: Optimise calls to tagToEnum# -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: datacon-tags Operating System: 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): It's not clear to me what remains to be done on this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 11:18:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 11:18:50 -0000 Subject: [GHC] #14181: make test WAY=xxx broken In-Reply-To: <047.800b3734558383132e123840bac3e5aa@haskell.org> References: <047.800b3734558383132e123840bac3e5aa@haskell.org> Message-ID: <062.b7a905ee8e20bae3f10231f615b24e45@haskell.org> #14181: make test WAY=xxx broken -------------------------------------+------------------------------------- Reporter: angerman | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Test Suite | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3917 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 11:21:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 11:21:21 -0000 Subject: [GHC] #14096: Residency profiling with eventlog enabled breaks In-Reply-To: <046.b0ac9cb699336e79142ee4ab7e9074ac@haskell.org> References: <046.b0ac9cb699336e79142ee4ab7e9074ac@haskell.org> Message-ID: <061.d677eb14621b3ee4592d87142a43db04@haskell.org> #14096: Residency profiling with eventlog enabled breaks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: merge Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3922 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 11:21:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 11:21:54 -0000 Subject: [GHC] #14181: make test WAY=xxx broken In-Reply-To: <047.800b3734558383132e123840bac3e5aa@haskell.org> References: <047.800b3734558383132e123840bac3e5aa@haskell.org> Message-ID: <062.7476ce062d8f1099365dcb50e65b8a1e@haskell.org> #14181: make test WAY=xxx broken -------------------------------------+------------------------------------- Reporter: angerman | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Test Suite | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3917 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"31281a476ded406091d0eaefc9d6f466272c985f/ghc" 31281a47/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="31281a476ded406091d0eaefc9d6f466272c985f" testsuite: Fix validation of ways Test Plan: Run `make test WAY=prof` Reviewers: angerman, austin Subscribers: rwbarton, thomie GHC Trac Issues: #14181 Differential Revision: https://phabricator.haskell.org/D3917 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 11:21:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 11:21:54 -0000 Subject: [GHC] #14129: GHC segfaults trying to use ANN code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.348618562e66743b0480359855424811@haskell.org> References: <044.348618562e66743b0480359855424811@haskell.org> Message-ID: <059.f5925876863fd095eb4ff233042540ec@haskell.org> #14129: GHC segfaults trying to use ANN code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b996e12d2c6a838a9c6d8096142f07de5cb7fedc/ghc" b996e12d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b996e12d2c6a838a9c6d8096142f07de5cb7fedc" testsuite: Add test for #14129 It's not impossible that this will also get caught by another test given a suitably configured compiler, but this is minimal enough that it seems worth including. Test Plan: Validate with `DYNAMIC_GHC_PROGRAMS=NO` Reviewers: austin Subscribers: rwbarton, thomie GHC Trac Issues: #14129 Differential Revision: https://phabricator.haskell.org/D3924 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 11:21:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 11:21:54 -0000 Subject: [GHC] #13988: GADT constructor with kind equality constraint quantifies unused existential type variables In-Reply-To: <050.f86444d263992660419b9d2efa0c4d7c@haskell.org> References: <050.f86444d263992660419b9d2efa0c4d7c@haskell.org> Message-ID: <065.2e3c345b8e4a4280d3d55648c3f54700@haskell.org> #13988: GADT constructor with kind equality constraint quantifies unused existential type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 14131 Related Tickets: | Differential Rev(s): Phab:D3902 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b9ac9e05b29c58efc93b78bf7fca43d61ead50c7/ghc" b9ac9e0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b9ac9e05b29c58efc93b78bf7fca43d61ead50c7" Fix egregious duplication of vars in RnTypes `RnTypes` contains a fairly intricate algorithm to extract the kind and type variables of an HsType. This algorithm carefully maintains the separation between type variables and kind variables so that the difference between `-XPolyKinds` and `-XTypeInType` can be respected. But after doing all this, `rmDupsInRdrTyVars` stupidly just concatenated the lists of type and kind variables at the end. If a variable were used as both a type and a kind, the algorithm would produce *both*! This led to all kinds of problems, including #13988. This is mostly Richard Eisenberg's patch. The only original contribution I made was adapting call sites of `rnImplicitBndrs` to work with the new definition of `rmDupsInRdrTyVars`. That is, `rnImplicitBndrs` checks for variables that are illegally used in both type and kind positions without using `-XTypeInType`, but in order to check this, one cannot have filtered duplicate variables out before passing them to `rnImplicitBndrs`. To accommodate for this, I needed to concoct variations on the existing `extract-` functions in `RnTypes` which do not remove duplicates, and use those near `rnImplicitBndrs` call sites. test case: ghci/scripts/T13988 Test Plan: make test TEST=T13988 Reviewers: goldfire, simonpj, austin, bgamari Reviewed By: goldfire, simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #13988 Differential Revision: https://phabricator.haskell.org/D3902 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 11:21:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 11:21:54 -0000 Subject: [GHC] #13165: Speed up the RTS hash table In-Reply-To: <047.5597063b110123c6100b4b707918365d@haskell.org> References: <047.5597063b110123c6100b4b707918365d@haskell.org> Message-ID: <062.14dbaf032d151837a0742e5235c6b279@haskell.org> #13165: Speed up the RTS hash table -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"542f89ff23e4deb66debca0b5de3ac3047befb28/ghc" 542f89f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="542f89ff23e4deb66debca0b5de3ac3047befb28" Replace hashing function for string keys implementation with xxhash When doing profiling on startup time of ghci on Windows, both cold and startup loading static LLVM libs, the profiler is showing a glaring red spot on the division operation of the the hashStr function. In fact profiling shows 14% of the time is spent hashing the keys. So I am replacing the hash function with xxHash which is a very fast non-crypto hash. It's faster than MurMurHash which node etc use. It also passes SMHasher. I can provide if required the collected raw data. But from analysis done on the keys, xxHash does not introduce more collisions than before, the amount splits seem about the same and the distributions among the buckets are slightly more uniform than before. However the runtime dropped enough to remove the function completely from the profiler's report. There's also a noticeable improvement in responsiveness. xxHash is BSD licensed and can be found https://github.com/Cyan4973/xxHash Test Plan: ./validate Reviewers: austin, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13165 Differential Revision: https://phabricator.haskell.org/D3909 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 11:21:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 11:21:54 -0000 Subject: [GHC] #12502: Reject wrong find utility In-Reply-To: <044.bf466ae198a25fe9a5df2ca0f70bd734@haskell.org> References: <044.bf466ae198a25fe9a5df2ca0f70bd734@haskell.org> Message-ID: <059.91799a5fbe2cbbbe007537167d2a5a4e@haskell.org> #12502: Reject wrong find utility -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3907 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a4c2ac2cef3d0ad3c968b8195daf651e672d3435/ghc" a4c2ac2c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a4c2ac2cef3d0ad3c968b8195daf651e672d3435" get-win32-tarballs: Use correct `find` This fixes #12502 by using the `find` utility found by FP_PROG_FIND instead of the first one in PATH. Test Plan: Validate on Windows Reviewers: Phyx, austin, hvr Reviewed By: Phyx Subscribers: rwbarton, thomie, erikd GHC Trac Issues: #12502 Differential Revision: https://phabricator.haskell.org/D3907 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 11:21:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 11:21:54 -0000 Subject: [GHC] #14096: Residency profiling with eventlog enabled breaks In-Reply-To: <046.b0ac9cb699336e79142ee4ab7e9074ac@haskell.org> References: <046.b0ac9cb699336e79142ee4ab7e9074ac@haskell.org> Message-ID: <061.95b06b8eafec1ac81b22a8168e42306a@haskell.org> #14096: Residency profiling with eventlog enabled breaks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: merge Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3922 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"822abbb1b4300ebaa3f12014b9fc477261283143/ghc" 822abbb1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="822abbb1b4300ebaa3f12014b9fc477261283143" eventlog: Clean up profiling heap breakdown type Reviewers: austin, erikd, simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #14096 Differential Revision: https://phabricator.haskell.org/D3923 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 11:21:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 11:21:54 -0000 Subject: [GHC] #13481: T12622 fails in ghci way In-Reply-To: <046.f9d04c6c728f8f80bc5f7c5da4765696@haskell.org> References: <046.f9d04c6c728f8f80bc5f7c5da4765696@haskell.org> Message-ID: <061.e54af2b16fee98e2ee3828a6488a3ade@haskell.org> #13481: T12622 fails in ghci way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: T12622 Blocked By: | Blocking: Related Tickets: #12622, #12356 | Differential Rev(s): Phab:D3920 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"cd857dd415378ac4204a164407d350b0c3ede5ae/ghc" cd857dd4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cd857dd415378ac4204a164407d350b0c3ede5ae" SetLevels: Substitute in ticks in lvlMFE Previously SetLevels.lvlMFE would fail to substitute in ticks, unlike lvlExpr. This lead to #13481. Fix this. Test Plan: `make test TEST=T12622 WAY=ghci` Reviewers: austin, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #13481 Differential Revision: https://phabricator.haskell.org/D3920 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 11:21:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 11:21:54 -0000 Subject: [GHC] #14096: Residency profiling with eventlog enabled breaks In-Reply-To: <046.b0ac9cb699336e79142ee4ab7e9074ac@haskell.org> References: <046.b0ac9cb699336e79142ee4ab7e9074ac@haskell.org> Message-ID: <061.4444578b8c50262551ee5e487e961feb@haskell.org> #14096: Residency profiling with eventlog enabled breaks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: merge Priority: high | Milestone: 8.2.2 Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3922 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"24e50f988f775c6bba7d1daaee2e23c13650aa3b/ghc" 24e50f98/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="24e50f988f775c6bba7d1daaee2e23c13650aa3b" rts: Add heap breakdown type for -hT Test Plan: Build, program with `-eventlog`, try running with `+RTS -h` Reviewers: austin, erikd, simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #14096 Differential Revision: https://phabricator.haskell.org/D3922 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 11:21:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 11:21:54 -0000 Subject: [GHC] #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. In-Reply-To: <054.2188bb19676a701eab2890d90541afc2@haskell.org> References: <054.2188bb19676a701eab2890d90541afc2@haskell.org> Message-ID: <069.b58e563a0fc78db7f8bc36e896ba7cca@haskell.org> #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. -------------------------------------+------------------------------------- Reporter: leftaroundabout | Owner: alekzcb Type: bug | Status: new Priority: low | Milestone: 8.4.1 Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: numrun016 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3916 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6458b8dcbd33b3c32f3c23f7e5b08fdc6e73ed46/ghc" 6458b8dc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6458b8dcbd33b3c32f3c23f7e5b08fdc6e73ed46" base: Update acosh to handle -1::Complex Summary: Fixes #8532 Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #8532 Differential Revision: https://phabricator.haskell.org/D3916 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 11:22:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 11:22:58 -0000 Subject: [GHC] #13165: Speed up the RTS hash table In-Reply-To: <047.5597063b110123c6100b4b707918365d@haskell.org> References: <047.5597063b110123c6100b4b707918365d@haskell.org> Message-ID: <062.4584d484cd108e40f3a6d7b28be1978c@haskell.org> #13165: Speed up the RTS hash table -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The switch to xxhash should help although I suspect more can be done here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 11:23:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 11:23:13 -0000 Subject: [GHC] #13481: T12622 fails in ghci way In-Reply-To: <046.f9d04c6c728f8f80bc5f7c5da4765696@haskell.org> References: <046.f9d04c6c728f8f80bc5f7c5da4765696@haskell.org> Message-ID: <061.777aa83388d577d7b3b8ff534dc8277b@haskell.org> #13481: T12622 fails in ghci way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: merge Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: T12622 Blocked By: | Blocking: Related Tickets: #12622, #12356 | Differential Rev(s): Phab:D3920 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 11:23:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 11:23:33 -0000 Subject: [GHC] #13988: GADT constructor with kind equality constraint quantifies unused existential type variables In-Reply-To: <050.f86444d263992660419b9d2efa0c4d7c@haskell.org> References: <050.f86444d263992660419b9d2efa0c4d7c@haskell.org> Message-ID: <065.795684a6cb7134791e4f2e8faca3c030@haskell.org> #13988: GADT constructor with kind equality constraint quantifies unused existential type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 14131 Related Tickets: | Differential Rev(s): Phab:D3902 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Can this be considered resolved? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 12:08:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 12:08:40 -0000 Subject: [GHC] #13988: GADT constructor with kind equality constraint quantifies unused existential type variables In-Reply-To: <050.f86444d263992660419b9d2efa0c4d7c@haskell.org> References: <050.f86444d263992660419b9d2efa0c4d7c@haskell.org> Message-ID: <065.4a2e09ef67a8c456e7e335c400e5e0a4@haskell.org> #13988: GADT constructor with kind equality constraint quantifies unused existential type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | ghci/scripts/T13988 Blocked By: | Blocking: 14131 Related Tickets: | Differential Rev(s): Phab:D3902 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => ghci/scripts/T13988 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 12:31:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 12:31:30 -0000 Subject: [GHC] #13988: GADT constructor with kind equality constraint quantifies unused existential type variables In-Reply-To: <050.f86444d263992660419b9d2efa0c4d7c@haskell.org> References: <050.f86444d263992660419b9d2efa0c4d7c@haskell.org> Message-ID: <065.0395b3895ea675afa2a98105f4605efd@haskell.org> #13988: GADT constructor with kind equality constraint quantifies unused existential type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | ghci/scripts/T13988 Blocked By: | Blocking: 14131 Related Tickets: | Differential Rev(s): Phab:D3902 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 Comment: Replying to [comment:6 bgamari]: > Can this be considered resolved? Indeed it can. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 12:59:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 12:59:12 -0000 Subject: [GHC] #13165: Speed up the RTS hash table In-Reply-To: <047.5597063b110123c6100b4b707918365d@haskell.org> References: <047.5597063b110123c6100b4b707918365d@haskell.org> Message-ID: <062.38972a584d6947465f32155b4003f312@haskell.org> #13165: Speed up the RTS hash table -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): The xxHash patch only improves hashing for strings, compaction uses address hashing which is unaffected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 13:49:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 13:49:12 -0000 Subject: [GHC] #14186: CSE fails to CSE Message-ID: <046.69825e5d45135d4ed01bf5ccfdf86282@haskell.org> #14186: CSE fails to CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this code: {{{ module CSEBug where data Succs a = Succs a [a] instance Functor Succs where fmap f (Succs o s) = Succs (f o) (map f s) foo, bar :: (a -> b) -> (b -> c) -> Succs a -> Succs c foo f g x = fmap (g . f) x bar f g x = fmap (g . f) x }}} If I compile this with `-O`, `foo` and `bar` are not CSEd, which can be seen with `-ddump-cse`. Removing either the first or the second argument of `Succs` makes CSE work. Is there a size limit on CSE? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 13:55:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 13:55:45 -0000 Subject: [GHC] #14186: CSE fails to CSE two identical large top-level functions (was: CSE fails to CSE) In-Reply-To: <046.69825e5d45135d4ed01bf5ccfdf86282@haskell.org> References: <046.69825e5d45135d4ed01bf5ccfdf86282@haskell.org> Message-ID: <061.d88491d8b957e94bf46d57b16c6b2339@haskell.org> #14186: CSE fails to CSE two identical large top-level functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 14:21:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 14:21:28 -0000 Subject: [GHC] #14057: Upstream Alpine Linux distribution patches In-Reply-To: <046.942a17c3b70d9863c708d25f4b0f2dde@haskell.org> References: <046.942a17c3b70d9863c708d25f4b0f2dde@haskell.org> Message-ID: <061.4dbce60c367e3717d9f374db8849361a@haskell.org> #14057: Upstream Alpine Linux distribution patches ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 15:10:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 15:10:13 -0000 Subject: [GHC] #7938: Unbound kind variable can appear in RHS of associated type In-Reply-To: <047.8d93f4592d6bcb39d468bee67a34e1d0@haskell.org> References: <047.8d93f4592d6bcb39d468bee67a34e1d0@haskell.org> Message-ID: <062.0a362083d43529c585ba9802d0f9a7e6@haskell.org> #7938: Unbound kind variable can appear in RHS of associated type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC accepts | Test Case: indexed- invalid program | types/should_fail/T7938 Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"0829821a6b886788a3ba6989e57e25a037bb6d05/ghc" 0829821a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0829821a6b886788a3ba6989e57e25a037bb6d05" Implicitly bind kind variables in type family instance RHSes when it's sensible Summary: Before, there was a discrepancy in how GHC renamed type synonyms as opposed to type family instances. That is, GHC would accept definitions like this one: ```lang=haskell type T = (Nothing :: Maybe a) ``` However, it would not accept a very similar type family instance: ```lang=haskell type family T :: Maybe a type instance T = (Nothing :: Maybe a) ``` The primary goal of this patch is to bring the renaming of type family instances up to par with that of type synonyms, causing the latter definition to be accepted, and fixing #14131. In particular, we now allow kind variables on the right-hand sides of type (and data) family instances to be //implicitly// bound by LHS type (or kind) patterns (as opposed to type variables, which must always be explicitly bound by LHS type patterns only). As a consequence, this allows programs reported in #7938 and #9574 to typecheck, whereas before they would have been rejected. Implementation-wise, there isn't much trickery involved in making this happen. We simply need to bind additional kind variables from the RHS of a type family in the right place (in particular, see `RnSource.rnFamInstEqn`, which has undergone a minor facelift). While doing this has the upside of fixing #14131, it also made it easier to trigger #13985, so I decided to fix that while I was in town. This was accomplished by a careful blast of `reportFloatingKvs` in `tcFamTyPats`. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #13985, #14131 Differential Revision: https://phabricator.haskell.org/D3872 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 15:10:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 15:10:13 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2313985=3A_GHC_8=2E0_regression=3A_?= =?utf-8?q?=E2=80=98k=E2=80=99_is_not_in_scope_during_type_checki?= =?utf-8?q?ng=2C_but_it_passed_the_renamer?= In-Reply-To: <050.713def54cc371cef366e72c06648a03c@haskell.org> References: <050.713def54cc371cef366e72c06648a03c@haskell.org> Message-ID: <065.1f371d3ec6d4a6da1313148d65a8b1b6@haskell.org> #13985: GHC 8.0 regression: ‘k’ is not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13738, #14131 | Differential Rev(s): Phab:D3872 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"0829821a6b886788a3ba6989e57e25a037bb6d05/ghc" 0829821a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0829821a6b886788a3ba6989e57e25a037bb6d05" Implicitly bind kind variables in type family instance RHSes when it's sensible Summary: Before, there was a discrepancy in how GHC renamed type synonyms as opposed to type family instances. That is, GHC would accept definitions like this one: ```lang=haskell type T = (Nothing :: Maybe a) ``` However, it would not accept a very similar type family instance: ```lang=haskell type family T :: Maybe a type instance T = (Nothing :: Maybe a) ``` The primary goal of this patch is to bring the renaming of type family instances up to par with that of type synonyms, causing the latter definition to be accepted, and fixing #14131. In particular, we now allow kind variables on the right-hand sides of type (and data) family instances to be //implicitly// bound by LHS type (or kind) patterns (as opposed to type variables, which must always be explicitly bound by LHS type patterns only). As a consequence, this allows programs reported in #7938 and #9574 to typecheck, whereas before they would have been rejected. Implementation-wise, there isn't much trickery involved in making this happen. We simply need to bind additional kind variables from the RHS of a type family in the right place (in particular, see `RnSource.rnFamInstEqn`, which has undergone a minor facelift). While doing this has the upside of fixing #14131, it also made it easier to trigger #13985, so I decided to fix that while I was in town. This was accomplished by a careful blast of `reportFloatingKvs` in `tcFamTyPats`. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #13985, #14131 Differential Revision: https://phabricator.haskell.org/D3872 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 15:10:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 15:10:13 -0000 Subject: [GHC] #14131: Difference between newtype and newtype instance In-Reply-To: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> References: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> Message-ID: <066.77271423d7b151ea7bc9fe0c1d14df24@haskell.org> #14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: RyanGlScott Type: bug | Status: patch 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: 13988 | Blocking: Related Tickets: #7938, #9574, | Differential Rev(s): Phab:D3872, #13985 | Phab:D3881 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"0829821a6b886788a3ba6989e57e25a037bb6d05/ghc" 0829821a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0829821a6b886788a3ba6989e57e25a037bb6d05" Implicitly bind kind variables in type family instance RHSes when it's sensible Summary: Before, there was a discrepancy in how GHC renamed type synonyms as opposed to type family instances. That is, GHC would accept definitions like this one: ```lang=haskell type T = (Nothing :: Maybe a) ``` However, it would not accept a very similar type family instance: ```lang=haskell type family T :: Maybe a type instance T = (Nothing :: Maybe a) ``` The primary goal of this patch is to bring the renaming of type family instances up to par with that of type synonyms, causing the latter definition to be accepted, and fixing #14131. In particular, we now allow kind variables on the right-hand sides of type (and data) family instances to be //implicitly// bound by LHS type (or kind) patterns (as opposed to type variables, which must always be explicitly bound by LHS type patterns only). As a consequence, this allows programs reported in #7938 and #9574 to typecheck, whereas before they would have been rejected. Implementation-wise, there isn't much trickery involved in making this happen. We simply need to bind additional kind variables from the RHS of a type family in the right place (in particular, see `RnSource.rnFamInstEqn`, which has undergone a minor facelift). While doing this has the upside of fixing #14131, it also made it easier to trigger #13985, so I decided to fix that while I was in town. This was accomplished by a careful blast of `reportFloatingKvs` in `tcFamTyPats`. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #13985, #14131 Differential Revision: https://phabricator.haskell.org/D3872 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 15:10:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 15:10:13 -0000 Subject: [GHC] #9574: GHC Panic: No Skolem Info In-Reply-To: <045.a8d5c4a0e8ebaca5dabb9fd5e04d534e@haskell.org> References: <045.a8d5c4a0e8ebaca5dabb9fd5e04d534e@haskell.org> Message-ID: <060.297831413a1a170a6e7e64e33d211d0e@haskell.org> #9574: GHC Panic: No Skolem Info -------------------------------------+------------------------------------- Reporter: ian_mi | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T9574 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"0829821a6b886788a3ba6989e57e25a037bb6d05/ghc" 0829821a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0829821a6b886788a3ba6989e57e25a037bb6d05" Implicitly bind kind variables in type family instance RHSes when it's sensible Summary: Before, there was a discrepancy in how GHC renamed type synonyms as opposed to type family instances. That is, GHC would accept definitions like this one: ```lang=haskell type T = (Nothing :: Maybe a) ``` However, it would not accept a very similar type family instance: ```lang=haskell type family T :: Maybe a type instance T = (Nothing :: Maybe a) ``` The primary goal of this patch is to bring the renaming of type family instances up to par with that of type synonyms, causing the latter definition to be accepted, and fixing #14131. In particular, we now allow kind variables on the right-hand sides of type (and data) family instances to be //implicitly// bound by LHS type (or kind) patterns (as opposed to type variables, which must always be explicitly bound by LHS type patterns only). As a consequence, this allows programs reported in #7938 and #9574 to typecheck, whereas before they would have been rejected. Implementation-wise, there isn't much trickery involved in making this happen. We simply need to bind additional kind variables from the RHS of a type family in the right place (in particular, see `RnSource.rnFamInstEqn`, which has undergone a minor facelift). While doing this has the upside of fixing #14131, it also made it easier to trigger #13985, so I decided to fix that while I was in town. This was accomplished by a careful blast of `reportFloatingKvs` in `tcFamTyPats`. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #13985, #14131 Differential Revision: https://phabricator.haskell.org/D3872 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 15:11:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 15:11:35 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2313985=3A_GHC_8=2E0_regression=3A_?= =?utf-8?q?=E2=80=98k=E2=80=99_is_not_in_scope_during_type_checki?= =?utf-8?q?ng=2C_but_it_passed_the_renamer?= In-Reply-To: <050.713def54cc371cef366e72c06648a03c@haskell.org> References: <050.713def54cc371cef366e72c06648a03c@haskell.org> Message-ID: <065.b31cf90c7c2bba8228e00f22f5a042ad@haskell.org> #13985: GHC 8.0 regression: ‘k’ is not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | polykinds/T13985 Blocked By: | Blocking: Related Tickets: #13738, #14131 | Differential Rev(s): Phab:D3872 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => polykinds/T13985 * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 15:12:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 15:12:11 -0000 Subject: [GHC] #14131: Difference between newtype and newtype instance In-Reply-To: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> References: <051.f12c7077bbbe1f2fe1437a366a9bb774@haskell.org> Message-ID: <066.41b691d878f8a55b3f90dd45b587210c@haskell.org> #14131: Difference between newtype and newtype instance -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T14131 Blocked By: 13988 | Blocking: Related Tickets: #7938, #9574, | Differential Rev(s): Phab:D3872, #13985 | Phab:D3881 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => indexed-types/should_compile/T14131 * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 15:15:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 15:15:11 -0000 Subject: [GHC] #14175: Panic repSplitTyConApp_maybe In-Reply-To: <045.2fc9be96fc161afbef29226fbd9e3b46@haskell.org> References: <045.2fc9be96fc161afbef29226fbd9e3b46@haskell.org> Message-ID: <060.c1fce833df59c31ccd9c5a7ee586d048@haskell.org> #14175: Panic repSplitTyConApp_maybe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.2.1 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: #13910 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) Comment: I suspect that this program (which panics after 0829821a6b886788a3ba6989e57e25a037bb6d05 on GHC HEAD) has the same underlying symptom: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} module Bug where class C k where data CD :: k -> k -> * instance C (Maybe a) where data CD :: (k -> *) -> (k -> *) -> * }}} {{{ $ inplace/bin/ghc-stage2 --interactive ../Bug.hs GHCi, version 8.3.20170818: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( ../Bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170818 for x86_64-unknown-linux): getRuntimeRep k_a1v3[sk:1] :: k_a1vl[tau:1] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1142:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1982:18 in ghc:Type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 16:49:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 16:49:28 -0000 Subject: [GHC] #14175: Panic repSplitTyConApp_maybe In-Reply-To: <045.2fc9be96fc161afbef29226fbd9e3b46@haskell.org> References: <045.2fc9be96fc161afbef29226fbd9e3b46@haskell.org> Message-ID: <060.05b5a6c4ea9863b4dc46b39e848eaf34@haskell.org> #14175: Panic repSplitTyConApp_maybe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.2.1 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: #13910 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks. I have a fix for this on my laptop. Not quite daring to push during ICFP lest I break something (alghoug it validates). With the fix I get {{{ T14175a.hs:11:15: error: Not in scope: type variable k | 11 | data CD :: (k -> *) -> (k -> *) -> * | ^ T14175a.hs:11:27: error: Not in scope: type variable k | 11 | data CD :: (k -> *) -> (k -> *) -> * | ^ }}} for comment:1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 19:08:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 19:08:43 -0000 Subject: [GHC] #14175: Panic repSplitTyConApp_maybe In-Reply-To: <045.2fc9be96fc161afbef29226fbd9e3b46@haskell.org> References: <045.2fc9be96fc161afbef29226fbd9e3b46@haskell.org> Message-ID: <060.bd903f86450fe9753c2c3d80816d72ed@haskell.org> #14175: Panic repSplitTyConApp_maybe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.2.1 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: #13910 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm confused about what this fix is doing. Isn't `k` implicitly quantified? In other words, what does your patch do on this program, which explicitly quantifies `k` but throws the same panic? {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind class C a where data CD k (a :: k) :: k -> * instance C (Maybe a) where data CD k (a :: k -> *) :: (k -> *) -> * }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 21:48:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 21:48:26 -0000 Subject: [GHC] #14175: Panic repSplitTyConApp_maybe In-Reply-To: <045.2fc9be96fc161afbef29226fbd9e3b46@haskell.org> References: <045.2fc9be96fc161afbef29226fbd9e3b46@haskell.org> Message-ID: <060.60073b0c0f13fd8aa66fec45130a3833@haskell.org> #14175: Panic repSplitTyConApp_maybe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.2.1 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: #13910 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): After my fix I get this for comment:4 {{{ c:/code/HEAD/inplace/bin/ghc-stage1 -c T14175b.hs T14175b.hs:13:3: error: Expected kind (k1 -> *) -> * , but CD k (a :: k -> *) :: (k -> *) -> * has kind k1 -> * In the data instance declaration for CD In the instance declaration for C (Maybe a) | 13 | data CD k (a :: k -> *) :: (k -> *) -> * | ^^^^^^^^^^^^^^^^^^^^^^^ }}} That looks pretty weird too. But at least neither crashes, which is the first thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 5 23:23:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Sep 2017 23:23:39 -0000 Subject: [GHC] #14186: CSE fails to CSE two identical large top-level functions In-Reply-To: <046.69825e5d45135d4ed01bf5ccfdf86282@haskell.org> References: <046.69825e5d45135d4ed01bf5ccfdf86282@haskell.org> Message-ID: <061.f75f6ce53de1cb8a2822c22a36568576@haskell.org> #14186: CSE fails to CSE two identical large top-level functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ha ha. This is caused by two things 1. We don't CSE things with an INLINE pragma: see `Note [CSE for INLINE and NOINLINE]` in `CSE.hs` 2. The worker/wrapper pass (right after demand analysis) gives the wrapper an inline pragma of `INLINE[0]`. So (2) means that (1) means no CSE for `foo` and `bar`. Sigh. What to do? Well * `InlinePragma` already distinguishse between the `inl_inline` field and `inl_act`. See `Note [inl_inline and inl_act]` in `BasicTypes`. * So we should be able to distinguish between a user-supplied INLINE pragma `inl_inline` and one supplied the w/w pass. * If we could distinguish then CSDE could fail on the user-supplied kind, but succeed on the w/w supplied kind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 00:27:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 00:27:12 -0000 Subject: [GHC] #14140: Better treatment for dataToTag In-Reply-To: <046.9a79626424ac111932e061637da60868@haskell.org> References: <046.9a79626424ac111932e061637da60868@haskell.org> Message-ID: <061.cf0f65b97f39a324596a15e89796039a@haskell.org> #14140: Better treatment for dataToTag -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: 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): For derived instances, might it make sense to write this? {{{#!hs eqOS :: OS -> OS -> Bool eqOS a b | dataToTag a /= dataToTag b = False eqOS (OtherOS s1) (OtherOS s2) = s1 == (s2 :: String) eqOS _ _ = False }}} Sometimes this will be better; sometimes it will be worse. But I don't think it's likely to do anything silly. Of course, even if we do that, we probably want to try to make the compiler cleverer too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 00:53:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 00:53:30 -0000 Subject: [GHC] #14140: Better treatment for dataToTag In-Reply-To: <046.9a79626424ac111932e061637da60868@haskell.org> References: <046.9a79626424ac111932e061637da60868@haskell.org> Message-ID: <061.11bdd407555f5481644dc9eee1a11fba@haskell.org> #14140: Better treatment for dataToTag -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: 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): Simon, could you point me to the code responsible for the constant folding here? I'd like to see if I can guess how to make it do what you want. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 00:53:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 00:53:43 -0000 Subject: [GHC] #14140: Better treatment for dataToTag In-Reply-To: <046.9a79626424ac111932e061637da60868@haskell.org> References: <046.9a79626424ac111932e061637da60868@haskell.org> Message-ID: <061.d9f8badf70773ce30a3d052ff47d9e07@haskell.org> #14140: Better treatment for dataToTag -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: 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) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 00:55:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 00:55:21 -0000 Subject: [GHC] #13182: Rethinking dataToTag# In-Reply-To: <045.d45bc6a143e080aa610c6726878b4318@haskell.org> References: <045.d45bc6a143e080aa610c6726878b4318@haskell.org> Message-ID: <060.80824c26d1621e68a4f236e29aca1c3a@haskell.org> #13182: Rethinking dataToTag# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: low | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 01:45:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 01:45:03 -0000 Subject: [GHC] #13779: Add more signature suppression control for dumps In-Reply-To: <045.b44ddd36d0c9b6a6e5b4023b72336dc3@haskell.org> References: <045.b44ddd36d0c9b6a6e5b4023b72336dc3@haskell.org> Message-ID: <060.d822250efb74b6de12e2828398f911a4@haskell.org> #13779: Add more signature suppression control for dumps -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 01:49:06 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 01:49:06 -0000 Subject: [GHC] #9756: Warn about unnecessary unsafeCoerce In-Reply-To: <045.5b6c1cb850fc12c4b8f4fd479d405f05@haskell.org> References: <045.5b6c1cb850fc12c4b8f4fd479d405f05@haskell.org> Message-ID: <060.12d6ddef1b370f7e6a295d8c52c02240@haskell.org> #9756: Warn about unnecessary unsafeCoerce -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.9 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 dfeuer): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 02:21:38 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 02:21:38 -0000 Subject: [GHC] #10328: Control.Monad exports lead to weird Haddocks In-Reply-To: <045.44a1bb94a3277e92b37fe4a986cde3c0@haskell.org> References: <045.44a1bb94a3277e92b37fe4a986cde3c0@haskell.org> Message-ID: <060.4f562524ae11168fab51a33ec9719051@haskell.org> #10328: Control.Monad exports lead to weird Haddocks -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 02:26:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 02:26:05 -0000 Subject: [GHC] #9797: Investigate rewriting `>>=` to `*>` or `>>` for appropriate types In-Reply-To: <045.54c1b52407bd07f539504f3c758ce78d@haskell.org> References: <045.54c1b52407bd07f539504f3c758ce78d@haskell.org> Message-ID: <060.35de9267014810e66cf6c3c084d2e37e@haskell.org> #9797: Investigate rewriting `>>=` to `*>` or `>>` for appropriate types -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.9 Resolution: wontfix | 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 dfeuer): * status: new => closed * resolution: => wontfix Comment: This seems likely to be much more trouble than it's worth, especially since the types in question seem likely to be internal compiler bits and trying to match on lambdas doesn't seem like the greatest way to make friends and influence people. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 04:39:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 04:39:37 -0000 Subject: [GHC] #13707: xmobar crashes with segmentation faults? In-Reply-To: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> References: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> Message-ID: <061.bd9b802490bf96271405922c654960e5@haskell.org> #13707: xmobar crashes with segmentation faults? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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 rezb1t): * Attachment "xmobar.coredump.xz" added. xmobar coredump after segfault, with GHC 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 04:42:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 04:42:28 -0000 Subject: [GHC] #13707: xmobar crashes with segmentation faults? In-Reply-To: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> References: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> Message-ID: <061.aa0f3634ccb42811fe901bc476cc2bbd@haskell.org> #13707: xmobar crashes with segmentation faults? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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 rezb1t): Hi there! I noticed you needed a coredump some time ago, and was only now able to get one, as it was difficult to reproduce this bug using my setup. It has only happened to me a handful of times so far, probably 3-4 since GHC 8.2.1 came out. I am using NixOS latest unstable, GHC 8.2.1, and xmonad with xmobar. This coredump was truncated down to 500kb but if you need a larger one, let me know and I will do my best to get you one. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 10:46:01 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 10:46:01 -0000 Subject: [GHC] #14187: Transpose hangs on infinite by finite lists Message-ID: <046.a4f96ddec98a60f261f732dc98cbcc9b@haskell.org> #14187: Transpose hangs on infinite by finite lists -------------------------------------+------------------------------------- Reporter: utikeev | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: transpose | Operating System: Windows Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found out that this code {{{#!hs take 5 $ map (take 3) (transpose (repeat [0..1])) }}} isn't equivalent to this one {{{#!hs take 5 $ map (take 3) [[0,0..], [1,1..]] }}} The second piece of code gives expectable output of {{{[[0,0,0],[1,1,1]]}}}, while first one just hangs with outpit {{{[[0,0,0],[1,1,1],}}} also probably screwing up some descriptors after interruption with Ctrl+C (as in 8.2.1, didn't have such problem in 8.0.2. I attach the screenshot of my cmd after interruption and pressing Up and Down buttons randomly for a few times. The history seems to be broken). In my homework I had to make a function zipN, which is actually zipWith but for more than two lists. The solution which dealt with stuck was to write my own transpose and apply {{{takeWhile (not . null)}}} to the remaining part of transposed matrix. P.S.: {{{#!hs [[0,0..],[1,1..]] == transpose (repeat [0..1]) }}} also hangs ghci. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 10:47:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 10:47:08 -0000 Subject: [GHC] #14187: Transpose hangs on infinite by finite lists In-Reply-To: <046.a4f96ddec98a60f261f732dc98cbcc9b@haskell.org> References: <046.a4f96ddec98a60f261f732dc98cbcc9b@haskell.org> Message-ID: <061.baa787455d031a19f1afe0806cc3b5aa@haskell.org> #14187: Transpose hangs on infinite by finite lists -------------------------------------+------------------------------------- Reporter: utikeev | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: transpose Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by utikeev): * Attachment "Screenshot_5.png" added. Cmd with broken history after hanging -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 10:50:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 10:50:51 -0000 Subject: [GHC] #14187: Transpose hangs on infinite by finite lists In-Reply-To: <046.a4f96ddec98a60f261f732dc98cbcc9b@haskell.org> References: <046.a4f96ddec98a60f261f732dc98cbcc9b@haskell.org> Message-ID: <061.e6151821765f7c8cad93ce856493637f@haskell.org> #14187: Transpose hangs on infinite by finite lists -------------------------------------+------------------------------------- Reporter: utikeev | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: transpose Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by utikeev: Old description: > I found out that this code > > {{{#!hs > take 5 $ map (take 3) (transpose (repeat [0..1])) > }}} > > isn't equivalent to this one > > {{{#!hs > take 5 $ map (take 3) [[0,0..], [1,1..]] > }}} > > The second piece of code gives expectable output of > {{{[[0,0,0],[1,1,1]]}}}, while first one just hangs with outpit > {{{[[0,0,0],[1,1,1],}}} also probably screwing up some descriptors after > interruption with Ctrl+C (as in 8.2.1, didn't have such problem in 8.0.2. > I attach the screenshot of my cmd after interruption and pressing Up and > Down buttons randomly for a few times. The history seems to be broken). > > In my homework I had to make a function zipN, which is actually zipWith > but for more than two lists. The solution which dealt with stuck was to > write my own transpose and apply {{{takeWhile (not . null)}}} to the > remaining part of transposed matrix. > > P.S.: > {{{#!hs > [[0,0..],[1,1..]] == transpose (repeat [0..1]) > }}} > also hangs ghci. New description: I found out that this code {{{#!hs take 5 $ map (take 3) (transpose (repeat [0..1])) }}} isn't equivalent to this one {{{#!hs take 5 $ map (take 3) [[0,0..], [1,1..]] }}} The second piece of code gives expectable output of {{{[[0,0,0],[1,1,1]]}}}, while first one just hangs with output {{{[[0,0,0],[1,1,1],}}} also probably screwing up some descriptors after interruption with Ctrl+C (as in 8.2.1, didn't have such problem in 8.0.2. I attach the screenshot of my cmd after interruption and pressing Up and Down buttons randomly for a few times. The history seems to be broken). In my homework I had to make a function zipN, which is actually zipWith but for more than two lists. The solution which dealt with stuck was to write my own transpose and apply {{{takeWhile (not . null)}}} to the remaining part of transposed matrix. P.S.: {{{#!hs [[0,0..],[1,1..]] == transpose (repeat [0..1]) }}} also hangs ghci. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 12:45:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 12:45:08 -0000 Subject: [GHC] #14188: On windows, trace prints out lines without proper line endings Message-ID: <046.a18d0ba283f4fb4d2734156aadd78dc2@haskell.org> #14188: On windows, trace prints out lines without proper line endings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Try this on Windows {{{ module Foo where f x = x }}} and now {{{ ghc -c -dverbose-core2core Foo.hs 2> foo }}} Now edit `foo`. You'll see that * Some lines, produced by monadic IO, I think, have CRLF endings (`^M^J`). * But others, produced by `pprTrace` (actually `Simplify.hs` line 220, only have a LF ending (`^J`). The inconsistent line endings confuses emacs, which displays `^M` at the end of all the CRLF lines (ie most of them). This is Jolly Annoying. John Wiegley has made me a special SPJ-only emacs mimor mode that suppresses the annoying `^M` stuff, but that seems like extreme measures. Question: why doesn't `pprTrace` properly terminate its lines? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 13:37:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 13:37:05 -0000 Subject: [GHC] #14186: CSE fails to CSE two identical large top-level functions In-Reply-To: <046.69825e5d45135d4ed01bf5ccfdf86282@haskell.org> References: <046.69825e5d45135d4ed01bf5ccfdf86282@haskell.org> Message-ID: <061.df526e09cfa32971dac783450b8f0bf0@haskell.org> #14186: CSE fails to CSE two identical large top-level functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > So we should be able to distinguish between a user-supplied INLINE pragma inl_inline and one supplied the w/w pass. Are you saying that we can do that already, without changes to `BasicTypes`, or that we should extend `BasicTypes` to be able to do that? The current code in WorkWrap is {{{ wrap_act = ActiveAfter NoSourceText 0 wrap_prag = InlinePragma { inl_src = SourceText "{-# INLINE" , inl_inline = Inline , inl_sat = Nothing , inl_act = wrap_act , inl_rule = rule_match_info } }}} and unless I check for `NoSourceText`, this seems to be indistinguishable from a `INLINE[0]` in the source. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 13:45:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 13:45:00 -0000 Subject: [GHC] #14187: Transpose hangs on infinite by finite lists In-Reply-To: <046.a4f96ddec98a60f261f732dc98cbcc9b@haskell.org> References: <046.a4f96ddec98a60f261f732dc98cbcc9b@haskell.org> Message-ID: <061.12e48324608ca7182f11a7d0b87ae739@haskell.org> #14187: Transpose hangs on infinite by finite lists -------------------------------------+------------------------------------- Reporter: utikeev | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: transpose Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => invalid Comment: Thanks for your report. This is expected behavior. Note that the documentation says > The transpose function transposes the rows and columns of its argument. For example, > > transpose [[1,2,3],[4,5,6]] == [[1,4],[2,5],[3,6]] > > If some of the rows are shorter than the following rows, their elements are skipped: > > transpose [[10,11],[20],[],[30,31,32]] == [[10,20,30],[11,31],[32]] Note that `repeat [0,1] = [[0,1],[0,1],[0,1],[0,1],[0,1],…`. So if you look at the third element of `transpose (repeat [0,1])` then it has to skip the first `[0,1]` in the list of lists, as it has no third element. Then it skips the second, for the same reason, and goes on like that for ever. (You might wonder why it doesn’t detect that, because you use `repeat`, that _no_ element in the list has a third element – but that kind of reasoning is beyond what you can expect from a compiler, unfortunately.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 13:55:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 13:55:58 -0000 Subject: [GHC] #14187: Transpose hangs on infinite by finite lists In-Reply-To: <046.a4f96ddec98a60f261f732dc98cbcc9b@haskell.org> References: <046.a4f96ddec98a60f261f732dc98cbcc9b@haskell.org> Message-ID: <061.1b32a8a525a537b4e35fcfa4df4b1346@haskell.org> #14187: Transpose hangs on infinite by finite lists -------------------------------------+------------------------------------- Reporter: utikeev | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: transpose Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14150 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #14150 Comment: As for why the console bugs out after you type Ctrl+C—I believe that is due to #14150. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 13:56:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 13:56:59 -0000 Subject: [GHC] #14188: On windows, trace prints out lines without proper line endings In-Reply-To: <046.a18d0ba283f4fb4d2734156aadd78dc2@haskell.org> References: <046.a18d0ba283f4fb4d2734156aadd78dc2@haskell.org> Message-ID: <061.ac6e9b3f650ff52086db313a029fe5b2@haskell.org> #14188: On windows, trace prints out lines without proper line endings ---------------------------------+---------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by RyanGlScott): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 14:02:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 14:02:28 -0000 Subject: [GHC] #14187: Transpose hangs on infinite by finite lists In-Reply-To: <046.a4f96ddec98a60f261f732dc98cbcc9b@haskell.org> References: <046.a4f96ddec98a60f261f732dc98cbcc9b@haskell.org> Message-ID: <061.9a940dc688383a7c54c8490ad458fce2@haskell.org> #14187: Transpose hangs on infinite by finite lists -------------------------------------+------------------------------------- Reporter: utikeev | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: transpose Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14150 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by utikeev): Replying to [comment:2 nomeata]: > Thanks for your report. > ... Thanks a lot for clarifying that! It's true that I expected the behaviour which you described in brackets in the end of your reply, but now when I thought a bit about it, it seems reasonably fair that it doesn't work the way I want. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 20:42:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 20:42:08 -0000 Subject: [GHC] #1460: Problem with Monoid instance of Data.Map In-Reply-To: <051.14fc774a6009986dddf4bde26633711e@haskell.org> References: <051.14fc774a6009986dddf4bde26633711e@haskell.org> Message-ID: <066.6a787967ecea15a79415be38236a77da@haskell.org> #1460: Problem with Monoid instance of Data.Map -------------------------------------+------------------------------------- Reporter: ahey@… | Owner: (none) Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Resolution: fixed | Keywords: Data.Map | Monoid Operating System: 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): * cc: andrewthad (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 21:08:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 21:08:08 -0000 Subject: [GHC] #14189: Renamer does not preserve location for IEThingWith list items Message-ID: <044.0c99d438de6c1244d5aee79758fc528d@haskell.org> #14189: Renamer does not preserve location for IEThingWith list items -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the `RenamedSource` for {{{#!hs module Renaming.RenameInExportedType ( MyType (NT) ) where data MyType = MT Int | NT }}} The `(NT)` is given the location of `MyType` earlier on the line in the export list. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 21:08:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 21:08:27 -0000 Subject: [GHC] #14189: Renamer does not preserve location for IEThingWith list items In-Reply-To: <044.0c99d438de6c1244d5aee79758fc528d@haskell.org> References: <044.0c99d438de6c1244d5aee79758fc528d@haskell.org> Message-ID: <059.d1cba52a61475a6f248ae9e4915691c3@haskell.org> #14189: Renamer does not preserve location for IEThingWith list items -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * owner: (none) => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 22:51:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 22:51:32 -0000 Subject: [GHC] #14186: CSE fails to CSE two identical large top-level functions In-Reply-To: <046.69825e5d45135d4ed01bf5ccfdf86282@haskell.org> References: <046.69825e5d45135d4ed01bf5ccfdf86282@haskell.org> Message-ID: <061.0b374f3eeeb649847c16bf518411b754@haskell.org> #14186: CSE fails to CSE two identical large top-level functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think perhaps the `wrap_prag` can be `EmptyInlineSpec`. That might do it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 6 23:05:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Sep 2017 23:05:17 -0000 Subject: [GHC] #13716: Move CI to Jenkins In-Reply-To: <046.48e2facaae8e965ca7d5990f8113aa95@haskell.org> References: <046.48e2facaae8e965ca7d5990f8113aa95@haskell.org> Message-ID: <061.6517cbd2ef77768a965a148a910128cf@haskell.org> #13716: Move CI to Jenkins -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13897 | Blocking: Related Tickets: #11958 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): Is there any chance Cabal/cabal-install could piggyback on this effort? We've outgrown free services like Travis and AppVeyor and could use support for additional platforms (OpenBSD and maybe ARM) too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 00:32:21 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 00:32:21 -0000 Subject: [GHC] #14190: Typeable imposes seemingly redundant constraints on polykinded instances Message-ID: <045.10ac00c982131e42012d99b318054ca4@haskell.org> #14190: Typeable imposes seemingly redundant constraints on polykinded instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple TypeableReflection | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- To derive `Data` for `Const`, we need {{{#!hs deriving instance (Typeable k, Data a, Typeable (b :: k)) => Data (Const a b) }}} Where's that `Typeable k` constraint come from? It turns out that for reasons I haven't looked into, we can only obtain `Typeable (Const a (b :: k))` if we have `Typeable k`; `(Typeable a, Typeable b)` is insufficient. Is there a reason for that? Annoyingly, we can actually ''get'' that: {{{#!hs weGotThat :: forall k (a :: k). Typeable a :- Typeable k weGotThat = Sub $ withTypeable (typeRepKind (typeRep :: TypeRep a)) Dict }}} But of course that doesn't help us. Could we use `UndecidableSuperClasses` to work around this problem? I think we likely can, although I'm concerned about the performance implications: {{{#!hs class (Typeable a, Typeable' k) => Typeable' (a :: k) instance (Typeable a, Typeable' k) => Typeable' (a :: k) withTypeable' :: forall k (a :: k) r. TypeRep a -> (Typeable' a => r) -> r withTypeable' tr f = withTypeable tr $ withTypeable (typeRepKind (typeRep @a)) f }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 02:07:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 02:07:56 -0000 Subject: [GHC] #12437: 20% regression in max_bytes_used for T1969 In-Reply-To: <047.090b2624111211cac9a272929b897b02@haskell.org> References: <047.090b2624111211cac9a272929b897b02@haskell.org> Message-ID: <062.3b50954350363301210e351166bdf912@haskell.org> #12437: 20% regression in max_bytes_used for T1969 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I tried adding `-i0.01` to the `extra_hc_opts` for T1969. It didn't seem to change much. However, when I removed the `-G1` from that line, the unboxed sum commit seemed to stop affecting anything. Interesting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 08:44:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 08:44:13 -0000 Subject: [GHC] #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) Message-ID: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: | Version: 8.2.1 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: | prime:Libraries/Proposals/SemigroupMonoid -------------------------------------+------------------------------------- More details in ​prime:Libraries/Proposals/SemigroupMonoid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 08:46:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 08:46:20 -0000 Subject: [GHC] #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) In-Reply-To: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> References: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> Message-ID: <057.d276e0d2e52f2979f3635403f7878e21@haskell.org> #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: libraries/base | 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:D3927 Wiki Page: | prime:Libraries/Proposals/SemigroupMonoid| -------------------------------------+------------------------------------- Changes (by hvr): * owner: (none) => hvr * differential: => phab:D3927 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 08:52:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 08:52:27 -0000 Subject: [GHC] #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) In-Reply-To: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> References: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> Message-ID: <057.5626d3055ec1eb02f01c4a872b6d573d@haskell.org> #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: libraries/base | 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:D3927 Wiki Page: | prime:Libraries/Proposals/SemigroupMonoid| -------------------------------------+------------------------------------- Description changed by hvr: Old description: > More details in ​prime:Libraries/Proposals/SemigroupMonoid New description: More details in ​prime:Libraries/Proposals/SemigroupMonoid For more recent details about phase 2, see https://groups.google.com/forum/#!topic/haskell-core-libraries/PyxpE2ebS9Q -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 08:55:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 08:55:25 -0000 Subject: [GHC] #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) In-Reply-To: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> References: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> Message-ID: <057.826918677e4d1eef7903f102e154e749@haskell.org> #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: libraries/base | 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: #10365 | Differential Rev(s): phab:D3927 Wiki Page: | prime:Libraries/Proposals/SemigroupMonoid| -------------------------------------+------------------------------------- Changes (by hvr): * related: => #10365 Old description: > More details in ​prime:Libraries/Proposals/SemigroupMonoid > > For more recent details about phase 2, see > https://groups.google.com/forum/#!topic/haskell-core- > libraries/PyxpE2ebS9Q New description: More details in ​prime:Libraries/Proposals/SemigroupMonoid For more recent details about phase 2, see https://groups.google.com/forum/#!topic/haskell-core-libraries/PyxpE2ebS9Q For the previous phase1, see #10365 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 08:56:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 08:56:00 -0000 Subject: [GHC] #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) In-Reply-To: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> References: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> Message-ID: <059.b6b03dc78d0e91fc513cf06672b511e5@haskell.org> #10365: Implement Semigroup as a superclass of Monoid Proposal (Phase 1) -------------------------------------+------------------------------------- Reporter: gidyn | Owner: quchen Type: feature request | Status: closed Priority: high | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.1 Resolution: fixed | Keywords: report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14191 | Differential Rev(s): Phab:D1284 Wiki Page: | prime:Libraries/Proposals/SemigroupMonoid| -------------------------------------+------------------------------------- Changes (by hvr): * related: => #14191 Comment: Phase 2 is tracked in #14191 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 09:29:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 09:29:49 -0000 Subject: [GHC] #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs Message-ID: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System | Keywords: gdb, | Operating System: Unknown/Multiple debugging | Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #9706 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.0.2 on Linux changed the memory allocator to always allocate 1TB virtual memory on startup (#9706). I now have a production Haskell program running in a loop and would like to debug where it is stuck, on another machine, thus attaching with `gdb -p` and running `generate-core-file`. But core dumping takes forever, I Ctrl-C'd it when it reached 140 GB in size (my machine only has 64 GB RAM btw.); after the Ctrl-C the size of the core file on the file system was reported as `1.1T` (probably it's a sparse file now). Is there a workaround for this? For example, if I could dump only the resident or actually allocated pages, that would probably help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 09:30:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 09:30:28 -0000 Subject: [GHC] #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs In-Reply-To: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> References: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> Message-ID: <057.36f0f908c80e75a4159fb6c1af052c6d@haskell.org> #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: gdb, | debugging Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I found some info on selective page dumping on https://stackoverflow.com/questions/11734583/why-core-file-is-more-than- virtual-memory but I'm not sure what the right dumping approach is for programs running under the GHC 8.0 RTS. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 09:31:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 09:31:51 -0000 Subject: [GHC] #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs In-Reply-To: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> References: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> Message-ID: <057.5660de4af2534d70483060a0fa620a8e@haskell.org> #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: gdb, | debugging Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: simonmar, gcampax, ezyang (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 09:53:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 09:53:11 -0000 Subject: [GHC] #14193: Add RTS flag to disable 1TB address space allocaiton Message-ID: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> #14193: Add RTS flag to disable 1TB address space allocaiton -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #9706, #14192 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.0 changed the default behaviour on Linux to allocate 1 TB virtual memory for Haskell programs (#9706). While shown to be good for performance (a small percentage gain), it has created me a couple problems, especially when: * trying to disable overcommit in Linux to get more reliable memory behaviour and avoid swapping / the OOM-killer (all Haskell programs crash at startup) * and in debugging (e.g. #14192) Currently you can turn that feature off only via a compile-time switch, e.g. `./configure --disable-large-address-space`. I'd like to request to make it possible to turn this behaviour off at run- time with an RTS flag, so that when the flag is given, it uses the old block-allocator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 09:53:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 09:53:36 -0000 Subject: [GHC] #14194: ghci 8.0.2 panics Message-ID: <050.3fdc1276bc8b76dfe3b9eb2eacc28125@haskell.org> #14194: ghci 8.0.2 panics -------------------------------------+------------------------------------- Reporter: jakubdaniel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- I know it is rather hard to replicate but (I currently cannot check whether it still occurs in 8.0.2+): git clone https://github.com/jakubdaniel/expressions git clone https://github.com/jakubdaniel/expressions-z3 hg clone https://bitbucket.org/jd823592/z3-haskell cd expressions-z3 cabal sandbox init cabal sandbox add-source ../expression cabal sandbox add-source ../z3-haskell cabal install && cabal exec ghci λ> -- forget to :set -XTypeInType λ> :m Z3.Monad Data.Expression λ> -- forget to :m Data.Expression.Z3 λ> evalZ3 $ astToString =<< toZ3 (forall [var "x" :: Var 'IntegralSort] (exists [var "y" :: Var 'IntegralSort] (var "x" .+. var "y" .=. cnst 0)) :: Lia 'BooleanSort) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] toZ3_a4CL :: t_a4CK[tau:1] (CHoleCan: toZ3) [W] toZ3_a4Dx :: t_a4Dw[tau:1] (CHoleCan: toZ3)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 10:15:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 10:15:02 -0000 Subject: [GHC] #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs In-Reply-To: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> References: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> Message-ID: <057.b08ef8bc5503ffc85273526339321f3c@haskell.org> #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: gdb, | debugging Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nicolast): I guess setting the `MADV_DONTDUMP` flag on the region using `madvise(2)`, then resetting the flag when chunks of said memory are being used, could work. Not sure about the performance impact of setting and resetting that flag over and over... May make sense to do it over chunks of, say, 32MB at a time, which would still result in 'large' (though likely very compressable) coredumps for small programs, yet manageable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 10:17:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 10:17:31 -0000 Subject: [GHC] #14194: ghci 8.0.2 panics In-Reply-To: <050.3fdc1276bc8b76dfe3b9eb2eacc28125@haskell.org> References: <050.3fdc1276bc8b76dfe3b9eb2eacc28125@haskell.org> Message-ID: <065.14010a6628dfb9b2780d38295a8ccb7d@haskell.org> #14194: ghci 8.0.2 panics -------------------------------------+------------------------------------- Reporter: jakubdaniel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by jakubdaniel: Old description: > I know it is rather hard to replicate but (I currently cannot check > whether it still occurs in 8.0.2+): > > git clone https://github.com/jakubdaniel/expressions > git clone https://github.com/jakubdaniel/expressions-z3 > hg clone https://bitbucket.org/jd823592/z3-haskell > > cd expressions-z3 > cabal sandbox init > cabal sandbox add-source ../expression > cabal sandbox add-source ../z3-haskell > cabal install && cabal exec ghci > > λ> -- forget to :set -XTypeInType > λ> :m Z3.Monad Data.Expression > λ> -- forget to :m Data.Expression.Z3 > λ> evalZ3 $ astToString =<< toZ3 (forall [var "x" :: Var 'IntegralSort] > (exists [var "y" :: Var 'IntegralSort] (var "x" .+. var "y" .=. cnst 0)) > :: Lia 'BooleanSort) > > ghc: panic! (the 'impossible' happened) > (GHC version 8.0.2 for x86_64-unknown-linux): > initTc: unsolved constraints > WC {wc_insol = > [W] toZ3_a4CL :: t_a4CK[tau:1] (CHoleCan: toZ3) > [W] toZ3_a4Dx :: t_a4Dw[tau:1] (CHoleCan: toZ3)} > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug New description: I know it is rather hard to reproduce but (I currently cannot check whether it still occurs in 8.0.2+): git clone https://github.com/jakubdaniel/expressions git clone https://github.com/jakubdaniel/expressions-z3 hg clone https://bitbucket.org/jd823592/z3-haskell cd expressions-z3 cabal sandbox init cabal sandbox add-source ../expression cabal sandbox add-source ../z3-haskell cabal install && cabal exec ghci λ> -- forget to :set -XTypeInType λ> :m Z3.Monad Data.Expression λ> -- forget to :m Data.Expression.Z3 λ> evalZ3 $ astToString =<< toZ3 (forall [var "x" :: Var 'IntegralSort] (exists [var "y" :: Var 'IntegralSort] (var "x" .+. var "y" .=. cnst 0)) :: Lia 'BooleanSort) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] toZ3_a4CL :: t_a4CK[tau:1] (CHoleCan: toZ3) [W] toZ3_a4Dx :: t_a4Dw[tau:1] (CHoleCan: toZ3)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 11:10:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 11:10:51 -0000 Subject: [GHC] #14194: ghci 8.0.2 panics In-Reply-To: <050.3fdc1276bc8b76dfe3b9eb2eacc28125@haskell.org> References: <050.3fdc1276bc8b76dfe3b9eb2eacc28125@haskell.org> Message-ID: <065.df2f9c22b4609e4bde3cf4d10e7204f2@haskell.org> #14194: ghci 8.0.2 panics -------------------------------------+------------------------------------- Reporter: jakubdaniel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by jakubdaniel: Old description: > I know it is rather hard to reproduce but (I currently cannot check > whether it still occurs in 8.0.2+): > > git clone https://github.com/jakubdaniel/expressions > git clone https://github.com/jakubdaniel/expressions-z3 > hg clone https://bitbucket.org/jd823592/z3-haskell > > cd expressions-z3 > cabal sandbox init > cabal sandbox add-source ../expression > cabal sandbox add-source ../z3-haskell > cabal install && cabal exec ghci > > λ> -- forget to :set -XTypeInType > λ> :m Z3.Monad Data.Expression > λ> -- forget to :m Data.Expression.Z3 > λ> evalZ3 $ astToString =<< toZ3 (forall [var "x" :: Var 'IntegralSort] > (exists [var "y" :: Var 'IntegralSort] (var "x" .+. var "y" .=. cnst 0)) > :: Lia 'BooleanSort) > > ghc: panic! (the 'impossible' happened) > (GHC version 8.0.2 for x86_64-unknown-linux): > initTc: unsolved constraints > WC {wc_insol = > [W] toZ3_a4CL :: t_a4CK[tau:1] (CHoleCan: toZ3) > [W] toZ3_a4Dx :: t_a4Dw[tau:1] (CHoleCan: toZ3)} > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug New description: I know it is rather hard to replicate but (I currently cannot check whether it still occurs in 8.0.2+): {{{ git clone https://github.com/jakubdaniel/expressions git clone https://github.com/jakubdaniel/expressions-z3 hg clone https://bitbucket.org/jd823592/z3-haskell wget https://github.com/Z3Prover/z3/releases/download/z3-4.4.1/z3-4.4.1-x64-ubuntu-14.04.zip unzip z3-4.4.1-x64-ubuntu-14.04.zip cd expressions-z3 cabal sandbox init cabal sandbox add-source ../expression cabal sandbox add-source ../z3-haskell cabal install --extra-include- dirs=$PWD/../z3-4.4.1-x64-ubuntu-14.04/include --extra-lib- dirs=$PWD/../z3-4.4.1-x64-ubuntu-14.04/bin && cabal exec ghci λ> -- forget to :set -XTypeInType λ> :m Z3.Monad Data.Expression λ> -- forget to :m Data.Expression.Z3 λ> evalZ3 $ astToString =<< toZ3 (forall [var "x" :: Var 'IntegralSort] (exists [var "y" :: Var 'IntegralSort] (var "x" .+. var "y" .=. cnst 0)) :: Lia 'BooleanSort) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] toZ3_a4CL :: t_a4CK[tau:1] (CHoleCan: toZ3) [W] toZ3_a4Dx :: t_a4Dw[tau:1] (CHoleCan: toZ3)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 11:11:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 11:11:14 -0000 Subject: [GHC] #14194: ghci 8.0.2 panics In-Reply-To: <050.3fdc1276bc8b76dfe3b9eb2eacc28125@haskell.org> References: <050.3fdc1276bc8b76dfe3b9eb2eacc28125@haskell.org> Message-ID: <065.f253288475fe7e186ca47b5814e70c26@haskell.org> #14194: ghci 8.0.2 panics -------------------------------------+------------------------------------- Reporter: jakubdaniel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by jakubdaniel: Old description: > I know it is rather hard to replicate but (I currently cannot check > whether it still occurs in 8.0.2+): > > {{{ > git clone https://github.com/jakubdaniel/expressions > git clone https://github.com/jakubdaniel/expressions-z3 > hg clone https://bitbucket.org/jd823592/z3-haskell > wget > https://github.com/Z3Prover/z3/releases/download/z3-4.4.1/z3-4.4.1-x64-ubuntu-14.04.zip > unzip z3-4.4.1-x64-ubuntu-14.04.zip > > cd expressions-z3 > cabal sandbox init > cabal sandbox add-source ../expression > cabal sandbox add-source ../z3-haskell > cabal install --extra-include- > dirs=$PWD/../z3-4.4.1-x64-ubuntu-14.04/include --extra-lib- > dirs=$PWD/../z3-4.4.1-x64-ubuntu-14.04/bin && cabal exec ghci > > λ> -- forget to :set -XTypeInType > λ> :m Z3.Monad Data.Expression > λ> -- forget to :m Data.Expression.Z3 > λ> evalZ3 $ astToString =<< toZ3 (forall [var "x" :: Var > 'IntegralSort] (exists [var "y" :: Var 'IntegralSort] (var "x" .+. var > "y" .=. cnst 0)) :: Lia 'BooleanSort) > ghc: panic! (the 'impossible' happened) > (GHC version 8.0.2 for x86_64-unknown-linux): > initTc: unsolved constraints > WC {wc_insol = > [W] toZ3_a4CL :: t_a4CK[tau:1] (CHoleCan: toZ3) > [W] toZ3_a4Dx :: t_a4Dw[tau:1] (CHoleCan: toZ3)} > > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > }}} New description: I know it is rather hard to reproduce but (I currently cannot check whether it still occurs in 8.0.2+): {{{ git clone https://github.com/jakubdaniel/expressions git clone https://github.com/jakubdaniel/expressions-z3 hg clone https://bitbucket.org/jd823592/z3-haskell wget https://github.com/Z3Prover/z3/releases/download/z3-4.4.1/z3-4.4.1-x64-ubuntu-14.04.zip unzip z3-4.4.1-x64-ubuntu-14.04.zip cd expressions-z3 cabal sandbox init cabal sandbox add-source ../expression cabal sandbox add-source ../z3-haskell cabal install --extra-include- dirs=$PWD/../z3-4.4.1-x64-ubuntu-14.04/include --extra-lib- dirs=$PWD/../z3-4.4.1-x64-ubuntu-14.04/bin && cabal exec ghci λ> -- forget to :set -XTypeInType λ> :m Z3.Monad Data.Expression λ> -- forget to :m Data.Expression.Z3 λ> evalZ3 $ astToString =<< toZ3 (forall [var "x" :: Var 'IntegralSort] (exists [var "y" :: Var 'IntegralSort] (var "x" .+. var "y" .=. cnst 0)) :: Lia 'BooleanSort) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] toZ3_a4CL :: t_a4CK[tau:1] (CHoleCan: toZ3) [W] toZ3_a4Dx :: t_a4Dw[tau:1] (CHoleCan: toZ3)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 11:13:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 11:13:35 -0000 Subject: [GHC] #14194: ghci 8.0.2 panics In-Reply-To: <050.3fdc1276bc8b76dfe3b9eb2eacc28125@haskell.org> References: <050.3fdc1276bc8b76dfe3b9eb2eacc28125@haskell.org> Message-ID: <065.66dd8b2bc0685ffe9f06edc5dd00b46e@haskell.org> #14194: ghci 8.0.2 panics -------------------------------------+------------------------------------- Reporter: jakubdaniel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by jakubdaniel: Old description: > I know it is rather hard to reproduce but (I currently cannot check > whether it still occurs in 8.0.2+): > > {{{ > git clone https://github.com/jakubdaniel/expressions > git clone https://github.com/jakubdaniel/expressions-z3 > hg clone https://bitbucket.org/jd823592/z3-haskell > wget > https://github.com/Z3Prover/z3/releases/download/z3-4.4.1/z3-4.4.1-x64-ubuntu-14.04.zip > unzip z3-4.4.1-x64-ubuntu-14.04.zip > > cd expressions-z3 > cabal sandbox init > cabal sandbox add-source ../expression > cabal sandbox add-source ../z3-haskell > cabal install --extra-include- > dirs=$PWD/../z3-4.4.1-x64-ubuntu-14.04/include --extra-lib- > dirs=$PWD/../z3-4.4.1-x64-ubuntu-14.04/bin && cabal exec ghci > > λ> -- forget to :set -XTypeInType > λ> :m Z3.Monad Data.Expression > λ> -- forget to :m Data.Expression.Z3 > λ> evalZ3 $ astToString =<< toZ3 (forall [var "x" :: Var > 'IntegralSort] (exists [var "y" :: Var 'IntegralSort] (var "x" .+. var > "y" .=. cnst 0)) :: Lia 'BooleanSort) > ghc: panic! (the 'impossible' happened) > (GHC version 8.0.2 for x86_64-unknown-linux): > initTc: unsolved constraints > WC {wc_insol = > [W] toZ3_a4CL :: t_a4CK[tau:1] (CHoleCan: toZ3) > [W] toZ3_a4Dx :: t_a4Dw[tau:1] (CHoleCan: toZ3)} > > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > }}} New description: I know it is rather hard to reproduce but (I currently cannot check whether it still occurs in 8.0.2+): {{{ git clone https://github.com/jakubdaniel/expressions git clone https://github.com/jakubdaniel/expressions-z3 hg clone https://bitbucket.org/jd823592/z3-haskell wget https://github.com/Z3Prover/z3/releases/download/z3-4.4.1/z3-4.4.1-x64-ubuntu-14.04.zip unzip z3-4.4.1-x64-ubuntu-14.04.zip cd expressions-z3 cabal sandbox init cabal sandbox add-source ../expressions cabal sandbox add-source ../z3-haskell cabal install --extra-include- dirs=$PWD/../z3-4.4.1-x64-ubuntu-14.04/include --extra-lib- dirs=$PWD/../z3-4.4.1-x64-ubuntu-14.04/bin && cabal exec ghci λ> -- forget to :set -XTypeInType λ> :m Z3.Monad Data.Expression λ> -- forget to :m Data.Expression.Z3 λ> evalZ3 $ astToString =<< toZ3 (forall [var "x" :: Var 'IntegralSort] (exists [var "y" :: Var 'IntegralSort] (var "x" .+. var "y" .=. cnst 0)) :: Lia 'BooleanSort) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] toZ3_a4CL :: t_a4CK[tau:1] (CHoleCan: toZ3) [W] toZ3_a4Dx :: t_a4Dw[tau:1] (CHoleCan: toZ3)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 11:58:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 11:58:36 -0000 Subject: [GHC] #14190: Typeable imposes seemingly redundant constraints on polykinded instances In-Reply-To: <045.10ac00c982131e42012d99b318054ca4@haskell.org> References: <045.10ac00c982131e42012d99b318054ca4@haskell.org> Message-ID: <060.8b8db65af636fe35e71f726f3c1b8809@haskell.org> #14190: Typeable imposes seemingly redundant constraints on polykinded instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | TypeableReflection Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 12:52:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 12:52:17 -0000 Subject: [GHC] #14194: ghci 8.0.2 panics In-Reply-To: <050.3fdc1276bc8b76dfe3b9eb2eacc28125@haskell.org> References: <050.3fdc1276bc8b76dfe3b9eb2eacc28125@haskell.org> Message-ID: <065.b458280689d80e92229d882810ad3a48@haskell.org> #14194: ghci 8.0.2 panics -------------------------------------+------------------------------------- Reporter: jakubdaniel | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13106 Comment: Thanks for the bug report. This is a duplicate of #13106, which has been fixed in GHC 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 13:00:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 13:00:07 -0000 Subject: [GHC] #14190: Typeable imposes seemingly redundant constraints on polykinded instances In-Reply-To: <045.10ac00c982131e42012d99b318054ca4@haskell.org> References: <045.10ac00c982131e42012d99b318054ca4@haskell.org> Message-ID: <060.bbaf0a6f75d93842fc304875b9c21bac@haskell.org> #14190: Typeable imposes seemingly redundant constraints on polykinded instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | TypeableReflection Operating System: 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 reason you need a `Typeable k` constraint is quite simple: `k` is just as much of a type as `a` or `b`, so in order to obtain a proper `TypeRep` for `Const`, you need to also obtain the `TypeRep`s for `a`, `b`, and `k`, requiring them all to be `Typeable` instances: {{{ λ> typeRep :: TypeRep (Const String Type) Const * [Char] * λ> typeRep :: TypeRep (Const String (Nothing :: Maybe Bool)) Const (Maybe Bool) [Char] ('Nothing Bool) }}} I don't see a bug here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 13:07:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 13:07:08 -0000 Subject: [GHC] #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs In-Reply-To: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> References: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> Message-ID: <057.dce6ea41536b6c84693be0b7500c7d53@haskell.org> #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: gdb, | debugging Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I'm surprised this is an issue, I'm sure I've core-dumped processes with the 1TB address space without any problems. The core files look huge, but they're sparse. I wonder what's being dumped. We could easily add a flag to change the size of the region, but adding a flag to disable the region completely would add a performance overhead because we'd have to check the flag repeatedly in the inner loop of the GC, so I'd really like to avoid that if possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 14:09:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 14:09:56 -0000 Subject: [GHC] #14190: Typeable imposes seemingly redundant constraints on polykinded instances In-Reply-To: <045.10ac00c982131e42012d99b318054ca4@haskell.org> References: <045.10ac00c982131e42012d99b318054ca4@haskell.org> Message-ID: <060.ff793eaa20ffa60912983cd1d7d5468f@haskell.org> #14190: Typeable imposes seemingly redundant constraints on polykinded instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | TypeableReflection Operating System: 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): Ryan, my point is that the `TypeRep k` can be extracted from the `TypeRep b` to simplify the constraint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 14:34:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 14:34:37 -0000 Subject: [GHC] #14190: Typeable imposes seemingly redundant constraints on polykinded instances In-Reply-To: <045.10ac00c982131e42012d99b318054ca4@haskell.org> References: <045.10ac00c982131e42012d99b318054ca4@haskell.org> Message-ID: <060.85479bf9500f5708b4587d8258c188c9@haskell.org> #14190: Typeable imposes seemingly redundant constraints on polykinded instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | TypeableReflection Operating System: 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): Sorry, I think I woefully misunderstood the point you were making. You're not arguing that we shouldn't require `k` to be a `Typeable` instance, but rather than if you have `Typeable (a :: k)`, then that //implies// `Typeable k`. I must admit I wasn't aware of the `weGotThis` trick you showed off above. Here's a version that doesn't depend on the `constraints` library: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeInType #-} import Type.Reflection hm :: forall k (a :: k). Typeable a => TypeRep k hm = withTypeable (typeRepKind (typeRep @a)) (typeRep @k) }}} In light of this, your suggestion to make `Typeable k` a superclass of `Typeable (a :: k)` makes much more sense. In fact, there was some [https://github.com/ghc-proposals/ghc- proposals/pull/16#issuecomment-255645119 discussion] about this on the corresponding GHC proposal, but it didn't seem to make it into [http://git.haskell.org/ghc.git/blob/055d73c6576bed2affaf96ef6a6b89aeb2cd2e9f:/libraries/base/Data/Typeable/Internal.hs#l458 GHC's implementation] of it. Ben, do you know what became of this idea? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 14:35:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 14:35:41 -0000 Subject: [GHC] #14190: Typeable imposes seemingly redundant constraints on polykinded instances In-Reply-To: <045.10ac00c982131e42012d99b318054ca4@haskell.org> References: <045.10ac00c982131e42012d99b318054ca4@haskell.org> Message-ID: <060.0f4472c485199f65b45353a0aa420d3e@haskell.org> #14190: Typeable imposes seemingly redundant constraints on polykinded instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Typeable Operating System: 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: TypeableReflection => Typeable * cc: RyanGlScott (added) Comment: (Changing to the much more frequently used "Typeable" keyword.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 14:42:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 14:42:58 -0000 Subject: [GHC] #14190: Typeable imposes seemingly redundant constraints on polykinded instances In-Reply-To: <045.10ac00c982131e42012d99b318054ca4@haskell.org> References: <045.10ac00c982131e42012d99b318054ca4@haskell.org> Message-ID: <060.a9439de021510134a1693d58b2cb5444@haskell.org> #14190: Typeable imposes seemingly redundant constraints on polykinded instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Typeable Operating System: 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): While the superclass approach probably has the best ergonomics, it makes the dictionary heavier. My suggestion was to extract the typerep-of-kind information as required in the `DFun`s. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 15:10:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 15:10:42 -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.ebd7de4aaaee6bd5d97291c75f4b567a@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: | -------------------------------------+------------------------------------- Changes (by magesh.b): * cc: magesh.b (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 15:12:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 15:12:30 -0000 Subject: [GHC] #14195: Generalize makeStableName# Message-ID: <049.9cdce35d0fc3965f8b68b9c3a7f8a10d@haskell.org> #14195: Generalize makeStableName# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The function `makeStableName#` has the following type: {{{ makeStableName# :: a -> State# RealWorld -> (#State# RealWorld, StableName# a#) }}} I believe that it could safely be changed to: {{{ makeStableName# :: a -> State# s -> (#State# s, StableName# a#) }}} Currently, I have some code that looks like this: {{{ {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} module Example ( Stable , stabilize , destabilize ) where import GHC.Prim import GHC.ST data Stable s a = Stable (StableName# a) a stabilize :: a -> ST s (Stable s a) stabilize a = ST $ \ s -> case makeStableName# a (unsafeCoerce# s) of (# s', sn #) -> (# unsafeCoerce# s', Stable sn a #) destabilize :: Stable s a -> a destabilize (Stable _ a) = a instance Eq a => Eq (Stable s a) where Stable sn1 a1 == Stable sn2 a2 = case eqStableName# sn1 sn2 of 0# -> a1 == a2 _ -> True }}} I want to be working in `ST`, not in `IO`, and I believe that this use of `unsafeCoerce#` is safe. However, it would be nice to not have to use it at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 15:43:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 15:43:12 -0000 Subject: [GHC] #14152: Float exit paths out of recursive functions In-Reply-To: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> References: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> Message-ID: <061.41755684eb79853560741bfbb5f922c1@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | 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: #14137 #10918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Looking at some of the performance changes observed. The two benchmarks with allocation changes show differences in Core, as expected. (Thunks previously bound outside a `joinrec` are now inlined.) About those runtime changes: All of these have unchanged Core! So the change must be in the libraries… Did not dig deeper yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 16:11:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 16:11:41 -0000 Subject: [GHC] #8583: Associated pattern synonyms In-Reply-To: <045.39184734af9bc44765e305261b59a6ed@haskell.org> References: <045.39184734af9bc44765e305261b59a6ed@haskell.org> Message-ID: <060.9af0416cd24db9a4df85a7ecdcf8c7dd@haskell.org> #8583: Associated pattern synonyms -------------------------------------+------------------------------------- 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: 5144 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Shayan-Najd): * cc: Shayan-Najd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 16:17:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 16:17:20 -0000 Subject: [GHC] #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs In-Reply-To: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> References: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> Message-ID: <057.d48b879ddfec17d0162cd2a3ad3d3684@haskell.org> #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: gdb, | debugging Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): @simonmar Could you try to reproduce? Try this: {{{ import Control.Concurrent main = threadDelay 1000000000 }}} Compile with `ghc --make thefile.hs` (8.0.2), pet the pid with `ps`, `sudo gdb -p thepid`, `generate-core-file`. For me (Ubuntu 16.04) that runs forever, writing GB after GB to `core.*` in gdb's working directory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 16:19:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 16:19:05 -0000 Subject: [GHC] #14152: Float exit paths out of recursive functions In-Reply-To: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> References: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> Message-ID: <061.d497506a9e32660ec0fbf2949a80a6fc@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | 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: #14137 #10918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Digging deeper: For `CSD`, `-ticky`, even with all of base instrumted, does not not show anything. Same for `cryptarithm1`. Judging from the module sizes, in base only `Data.Semigroup`, `GHC.Arr` and `GHC.Float` are affected (but maybe floating a let binding can happen with equally sized output binary.). A quick look at the core difference shows that some thunks are floated inside a `joinrec`, or even inlined completely, e.g. in `Arr`’s `(//)` and `accum`. None of these look as if they’d affect a benchmark like `CSD`. It must be the weather, or the constellation of the stars. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 16:31:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 16:31:02 -0000 Subject: [GHC] #8583: Associated pattern synonyms In-Reply-To: <045.39184734af9bc44765e305261b59a6ed@haskell.org> References: <045.39184734af9bc44765e305261b59a6ed@haskell.org> Message-ID: <060.dc0b334db7caf67bf6e1ef000d8d1abe@haskell.org> #8583: Associated pattern synonyms -------------------------------------+------------------------------------- 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: 5144 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Shayan-Najd): I am writing to resurrect this ticket! Nowadays, we can use `COMPLETE` pragmas to group together an arbitrary collection of synonyms. Why not also grouping the so called polymorphic pattern synonyms under type classes and having the totality condition derived from the association? (seems the most natural place for `COMPLETE`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 16:39:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 16:39:41 -0000 Subject: [GHC] #14152: Float exit paths out of recursive functions In-Reply-To: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> References: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> Message-ID: <061.ef3acc60e48a2acd55dbbc260983d662@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: patch 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: #14137 #10918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch Comment: Anyways, this is ready for review, either on https://phabricator.haskell.org/D3903 or in git, branch `wip/T14152`. The latter has the advantage that the basic patch can be inspected independent of the on-the-fly-CSE addition (which maybe be nice due to smaller Core, but may not be worth the slight complication of the code). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 18:06:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 18:06:15 -0000 Subject: [GHC] #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs In-Reply-To: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> References: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> Message-ID: <057.8fb37238fe37e68db372b02cae763bcd@haskell.org> #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: gdb, | debugging Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed I can reproduce this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 18:13:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 18:13:23 -0000 Subject: [GHC] #14195: Generalize makeStableName# In-Reply-To: <049.9cdce35d0fc3965f8b68b9c3a7f8a10d@haskell.org> References: <049.9cdce35d0fc3965f8b68b9c3a7f8a10d@haskell.org> Message-ID: <064.a2cb37e454f569976b82e85e3151acf3@haskell.org> #14195: Generalize makeStableName# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: patch Priority: low | 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): Phab:D3928 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3928 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 18:13:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 18:13:38 -0000 Subject: [GHC] #14195: Generalize makeStableName# In-Reply-To: <049.9cdce35d0fc3965f8b68b9c3a7f8a10d@haskell.org> References: <049.9cdce35d0fc3965f8b68b9c3a7f8a10d@haskell.org> Message-ID: <064.78963ee67375d0a786a9c9b860ce6269@haskell.org> #14195: Generalize makeStableName# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: patch Priority: low | 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): Phab:D3928 Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > The function `makeStableName#` has the following type: > > {{{ > makeStableName# :: a -> State# RealWorld -> (#State# RealWorld, > StableName# a#) > }}} > > I believe that it could safely be changed to: > > {{{ > makeStableName# :: a -> State# s -> (#State# s, StableName# a#) > }}} > > Currently, I have some code that looks like this: > > {{{ > {-# LANGUAGE MagicHash #-} > {-# LANGUAGE UnboxedTuples #-} > module Example > ( Stable > , stabilize > , destabilize > ) where > > import GHC.Prim > import GHC.ST > > data Stable s a = Stable (StableName# a) a > > stabilize :: a -> ST s (Stable s a) > stabilize a = ST $ \ s -> > case makeStableName# a (unsafeCoerce# s) of (# s', sn #) -> (# > unsafeCoerce# s', Stable sn a #) > > destabilize :: Stable s a -> a > destabilize (Stable _ a) = a > > instance Eq a => Eq (Stable s a) where > Stable sn1 a1 == Stable sn2 a2 = case eqStableName# sn1 sn2 of > 0# -> a1 == a2 > _ -> True > }}} > > I want to be working in `ST`, not in `IO`, and I believe that this use of > `unsafeCoerce#` is safe. However, it would be nice to not have to use it > at all. New description: The function `makeStableName#` has the following type: {{{#!hs makeStableName# :: a -> State# RealWorld -> (#State# RealWorld, StableName# a#) }}} I believe that it could safely be changed to: {{{#!hs makeStableName# :: a -> State# s -> (#State# s, StableName# a#) }}} Currently, I have some code that looks like this: {{{ {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} module Example ( Stable , stabilize , destabilize ) where import GHC.Prim import GHC.ST data Stable s a = Stable (StableName# a) a stabilize :: a -> ST s (Stable s a) stabilize a = ST $ \ s -> case makeStableName# a (unsafeCoerce# s) of (# s', sn #) -> (# unsafeCoerce# s', Stable sn a #) destabilize :: Stable s a -> a destabilize (Stable _ a) = a instance Eq a => Eq (Stable s a) where Stable sn1 a1 == Stable sn2 a2 = case eqStableName# sn1 sn2 of 0# -> a1 == a2 _ -> True }}} I want to be working in `ST`, not in `IO`, and I believe that this use of `unsafeCoerce#` is safe. However, it would be nice to not have to use it at all. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 19:38:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 19:38:07 -0000 Subject: [GHC] #14196: Replace ArrayArray# with either UnliftedArray# or Array# Message-ID: <049.e6e8e74aa5747261fafcac4ff3c72b33@haskell.org> #14196: Replace ArrayArray# with either UnliftedArray# or Array# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Just to be clear, there currently is nothing named `UnliftedArray#`. I would like to propose that such a thing possibly be added, with the long- term goal of deprecating and removing `ArrayArray#`. The interface for it would look like this: {{{#!hs data UnliftedArray# (a :: TYPE 'UnliftedRep) data MutableUnliftedArray# s (a :: TYPE 'UnliftedRep) indexUnliftedArray# :: forall (a :: TYPE 'UnliftedRep). UnliftedArray# a -> Int# -> a writeUnliftedArray# :: forall (a :: TYPE 'UnliftedRep). MutableUnliftedArray# s a -> Int# -> a -> State# s -> State# s readUnliftedArray# :: forall (a :: TYPE 'UnliftedRep). MutableUnliftedArray# s a -> Int# -> State# s -> (# State# s, a #) unsafeFreezeUnliftedArray# :: forall (a :: TYPE 'UnliftedRep). MutableUnliftedArray# s a -> State# s -> (#State# s, UnliftedArray# a#) newUnliftedArray# :: forall (a :: TYPE 'UnliftedRep). Int# -> a -> State# s -> (# State# s, MutableUnliftedArray# s a #) }}} You would also have a few other things like `sameMutableUnliftedArray#`, `sizeofMutableArray#`, `unsafeThawUnliftedArray#`, `copyUnliftedArray#`, etc. The main difficulty that I see in doing this is that I'm not sure if you can tell a primop that it takes a polymorphic argument whose kind is something other than `TYPE LiftedRep`. The bodies of all of the functions I listed above could simply be copied from the `ArrayArray#` functions. There are a few alternatives I've heard discussed. One is to make `Array#` accepted both boxed or unboxed types. There is a brief discussion of this in the UnliftedDataTypes proposal [#point0 (0)]. Indeed, it appears that some have managed to smuggle unlifted data into `Array#` already, with the caveats one would expect [#point1 (1)]. This interface would look like: {{{#!hs data Array# (a :: TYPE k) data MutableArray# s (a :: TYPE k) indexArray# :: Array# a -> Int -> a -- same as before indexUnliftedArray# :: forall (a :: TYPE UnliftedRep). Array# a -> Int -> a }}} So instead of having `Array#` and `UnliftedArray#` as separate data types, we could have `Array#` handle both cases, but we would need to make a duplicate of every function that operates on `Array#`. This follows all of the appropriate rules for when levity polymorphism is allowed, and it should be backwards-compatible with the previous non-levity-polymorphic definition of `Array#`. I'm not sure how many things in the GHC runtime assume that the values inside an array are lifted, so this might cause a bunch of problems. If it is possible, this approach would be kind of neat because then `SmallArray#` could be similarly adapted. Anyway, I just wanted to get this out there. I would be happy to try implementing the first proposal (involving `UnliftedArray#`) at some point in the next six months. Any feedback on the idea would be appreciated. Also, any comments on how appropriate this is for someone new to contributing to GHC would be appreciated as well. Thanks. * [=#point0 (0)] https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes#Parametricity * [=#point0 (1)] https://www.reddit.com/r/haskell/comments/6v9rmg/an_unified_array_interface/dlyph4i/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 19:53:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 19:53:34 -0000 Subject: [GHC] #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs In-Reply-To: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> References: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> Message-ID: <057.d670d95d94191dc2ee43185b725972ce@haskell.org> #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: gdb, | debugging Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nicolast): * cc: nicolast (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 21:35:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 21:35:13 -0000 Subject: [GHC] #14197: Flag "dump-rn-ast" only dumps the declarations, not the whole RenamedSource Message-ID: <044.cc22bc6c087d1948925080ce049a8ac5@haskell.org> #14197: Flag "dump-rn-ast" only dumps the declarations, not the whole RenamedSource -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `RenamedSource` is defined as {{{#!hs type RenamedSource = ( HsGroup Name , [LImportDecl Name] , Maybe [LIE Name] , Maybe LHsDocString) }}} The current behaviour when `dump-rn-ast` is set is to only dump the first component of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 21:35:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 21:35:41 -0000 Subject: [GHC] #14197: Flag "dump-rn-ast" only dumps the declarations, not the whole RenamedSource In-Reply-To: <044.cc22bc6c087d1948925080ce049a8ac5@haskell.org> References: <044.cc22bc6c087d1948925080ce049a8ac5@haskell.org> Message-ID: <059.6db9d2d5333de7b73ec72febf81dfa34@haskell.org> #14197: Flag "dump-rn-ast" only dumps the declarations, not the whole RenamedSource -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz 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: | -------------------------------------+------------------------------------- Changes (by alanz): * owner: (none) => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 21:46:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 21:46:29 -0000 Subject: [GHC] #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) In-Reply-To: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> References: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> Message-ID: <057.4cf7426201c70c2260b5992aaef0b849@haskell.org> #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: libraries/base | 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: #10365 | Differential Rev(s): phab:D3927 Wiki Page: | prime:Libraries/Proposals/SemigroupMonoid| -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"8ae263ceb3566a7c82336400b09cb8f381217405/ghc" 8ae263c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8ae263ceb3566a7c82336400b09cb8f381217405" Make Semigroup a superclass of Monoid (re #14191) Unfortunately, this requires introducing a couple of .hs-boot files to break up import cycles (mostly to provide class & typenames in order to be able to write type signatures). This does not yet re-export `(<>)` from Prelude (while the class-name `Semigroup` is reexported); that will happen in a future commit. Test Plan: local ./validate passed Reviewers: ekmett, austin, bgamari, erikd, RyanGlScott Reviewed By: ekmett, RyanGlScott GHC Trac Issues: #14191 Differential Revision: https://phabricator.haskell.org/D3927 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 21:55:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 21:55:30 -0000 Subject: [GHC] #13943: Compiler infinite loop with GHC-8.2 In-Reply-To: <048.054af5c39346b78fae836436fb73b68c@haskell.org> References: <048.054af5c39346b78fae836436fb73b68c@haskell.org> Message-ID: <063.b51a5a1fe7e91e9a0eb54cc7e22d613f@haskell.org> #13943: Compiler infinite loop with GHC-8.2 -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12791 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I think it's basically wrong for the specializer to select a top-level instance that might be overlapped by one that's given. However, it would be very sad to lose this important optimization in the overwhelmingly more common no-overlap case. I think the right goal is this: neither the type checker nor the optimizer should have to bend over backwards to worry about overlapping instances in the common case that there aren't any. I believe that we can look at the future in a few stages: ==== Short term ==== When a potential instance is given, don't specialize to a top-level instance if any of the following hold: - The instance is marked `OVERLAPPABLE` or `OVERLAPS`. - The instance is polymorphic, appears in a module declaring `OverlappingInstances`, and is not marked `INCOHERENT`. - There is a visible overlapping instance that might match. This short-term change doesn't fix the problem in all cases, because an instance declared in a module that doesn't mention overlapping can be overlapped in an importing module anyway. So we should probably add an option to avoid specializing to ''any'' non-`INCOHERENT` polymorphic instance when a given could possibly match. ==== Short-medium term ==== Only allow an instance to be overlapped if it's explicitly marked `OVERLAPPABLE` or `OVERLAPS`. This is a breaking change, and people will gripe, but I don't think there's any less-invasive way to make this even ''moderately'' robust. Most of the rest of this comment is about trying to make things robust even in the more complicated context of `GADTs`, `RankNTypes`, and `ConstraintKinds`. Add a `NO_OVERLAP` class declaration pragma to allow users to decree that overlapping instances for a particular class are prohibited. Question: should the pragma be per-class or per-parameter? I think probably per- parameter. Given {{{#!hs class Foo a {-# NO_OVERLAP #-} b }}} a constraint like `Foo Int b` is much better behaved than one like `Foo a b`. ==== Medium-long term ==== Only allow overlapping instances of a class if the definition of that class is explicitly marked with a pragma. There can be two pragmas, distinguishing ''semantically significant'' overlap from ''performance- only'' overlap. A class allowing semantically significant overlap is really for meta-programming only; trying to do anything fancy with it will ultimately lead to headaches. My guess is that only *monomorphic* constraints involving such a class should be allowed to instantiate constraint variables, appear in GADT constructor constraints, or appear in higher-rank types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 22:24:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 22:24:22 -0000 Subject: [GHC] #8583: Associated pattern synonyms In-Reply-To: <045.39184734af9bc44765e305261b59a6ed@haskell.org> References: <045.39184734af9bc44765e305261b59a6ed@haskell.org> Message-ID: <060.6ab000dc0b933d6d4bff253435d352c2@haskell.org> #8583: Associated pattern synonyms -------------------------------------+------------------------------------- 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: 5144 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Given our new ghc-proposals process, I think this should go via that route. The process seems to working well, and I know I have benefited through submitting my own proposals there and getting helpful feedback. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 22:39:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 22:39:26 -0000 Subject: [GHC] #14195: Generalize makeStableName# In-Reply-To: <049.9cdce35d0fc3965f8b68b9c3a7f8a10d@haskell.org> References: <049.9cdce35d0fc3965f8b68b9c3a7f8a10d@haskell.org> Message-ID: <064.229337d6c52e2487d494fdf55f51358b@haskell.org> #14195: Generalize makeStableName# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: patch Priority: low | 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): Phab:D3928 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: simonmar (added) Comment: Hang on. Making a new stable name has an I/O effect: it modifies a single, shared stable name table. When things have an I/O effect we put them in the IO monad. To put it more concretely, with the new signature I could say {{{ mks v :: a -> StableName# a mks v = runST (mkStableName# v) }}} But as the original paper points out, making a fresh stable name is not a pure operation. Copying Simon Marlow -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 22:45:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 22:45:08 -0000 Subject: [GHC] #14196: Replace ArrayArray# with either UnliftedArray# or Array# In-Reply-To: <049.e6e8e74aa5747261fafcac4ff3c72b33@haskell.org> References: <049.e6e8e74aa5747261fafcac4ff3c72b33@haskell.org> Message-ID: <064.d522e745bfd384fd841c97ed633974f4@haskell.org> #14196: Replace ArrayArray# with either UnliftedArray# or Array# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What is the problem you are trying to solve here? I'm lost. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 22:49:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 22:49:16 -0000 Subject: [GHC] #14175: Panic repSplitTyConApp_maybe In-Reply-To: <045.2fc9be96fc161afbef29226fbd9e3b46@haskell.org> References: <045.2fc9be96fc161afbef29226fbd9e3b46@haskell.org> Message-ID: <060.6786ce0618611746c9df8403f714329f@haskell.org> #14175: Panic repSplitTyConApp_maybe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.2.1 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: #13910 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Other than the kind signature in the second full line of the error message there, it looks reasonable to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 7 23:58:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Sep 2017 23:58:32 -0000 Subject: [GHC] #14196: Replace ArrayArray# with either UnliftedArray# or Array# In-Reply-To: <049.e6e8e74aa5747261fafcac4ff3c72b33@haskell.org> References: <049.e6e8e74aa5747261fafcac4ff3c72b33@haskell.org> Message-ID: <064.f6a1a4d005a266fee8097039b08cbe73@haskell.org> #14196: Replace ArrayArray# with either UnliftedArray# or Array# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): It looks like I forgot to provide the motivation for this. There are two problems with the current `ArrayArray#` interface: (1) Duplicated code and (2) lack of expressiveness, which pushes `unsafeCoerce#` onto end users. I'll go into both of these. Several of the primops for `ArrayArray#` have two variants. For example: {{{#!hs indexByteArrayArray# :: ArrayArray# -> Int# -> ByteArray# indexArrayArrayArray# :: ArrayArray# -> Int# -> ArrayArray# }}} We see the same thing for the read and write operations on `MutableArrayArray#` except that now we've got four variants: {{{#!hs readByteArrayArray# :: MutableArrayArray# s -> Int# -> State# s -> (#State# s, ByteArray##) readMutableByteArrayArray# :: MutableArrayArray# s -> Int# -> State# s -> (#State# s, MutableByteArray# s#) readArrayArrayArray# :: MutableArrayArray# s -> Int# -> State# s -> (#State# s, ArrayArray##) readMutableArrayArrayArray# :: MutableArrayArray# s -> Int# -> State# s -> (#State# s, MutableArrayArray# s#) }}} Under the hood, all four of these have the exact same implementation as we can see in [https://github.com/ghc/ghc/blob/8ae263ceb3566a7c82336400b09cb8f381217405/compiler/codeGen/StgCmmPrim.hs#L407-L416]: {{{#!hs emitPrimOp _ [res] ReadArrayArrayOp_ByteArray [obj,ix] = doReadPtrArrayOp res obj ix emitPrimOp _ [res] ReadArrayArrayOp_MutableByteArray [obj,ix] = doReadPtrArrayOp res obj ix emitPrimOp _ [res] ReadArrayArrayOp_ArrayArray [obj,ix] = doReadPtrArrayOp res obj ix emitPrimOp _ [res] ReadArrayArrayOp_MutableArrayArray [obj,ix] = doReadPtrArrayOp res obj ix }}} I consider this duplication a minor problem. It's not very costly, and it's easy to see what's going on. The real problem is that, despite the all the duplication, this interface still only captures a fraction of what `ArrayArray#` can really offer. The end user must explicitly use `unsafeCoerce#` to do a bunch of things (storing `MVar#`, `Array#`, etc.), and even when they want a `ByteArray#` (which the interface does safely allow), they must implicitly perform an unsafe coercion on every access (read/write/index) because the type system never really tells us what's in an `ArrayArray#`. In the `primitive` package, there is a lot of `unsafeCoerce#` that is required to make it work: [http://hackage.haskell.org/package/primitive-0.6.2.0/docs/src/Data- Primitive-UnliftedArray.html#PrimUnlifted]. Basically, the current interface interface doesn't take advantage of the type system. What we have are: * implicit unsafe coercion on every access * copying functions (`copyArrayArray#`, etc.) that don't ensure that the elements in both arrays are of the same type. * explicit `unsafeCoerce#` required whenever you want to: store `Array# a` inside of `ArrayArray#`, store `MutableByteArray# s` inside of `ArrayArray#`, store `MutVar# s a` inside of `ArrayArray#`, etc. For the most part, the advantages to having `UnliftedArray# a` are similar to the advantages of having `Array#` having the type variable `a`. `Array#` doesn't suffer from any of the aforementioned problems. Imagine if the interface for `Array#` looked like this: {{{#!hs data Array# data MutableArray# s indexArray# :: Array# -> Int -> a readMutableArray# :: MutableArray# s -> Int -> a -> State# s -> State# s }}} This would be terrible, and I'm glad it wasn't done that way. `ArrayArray#` was done that way because prior to GHC 8.0, type variables could only have lifted runtime representations. But now that we've had this for a while, I think it's time to look at cleaning up this interface. Plus, in the future, it might be worth having something like `SmallArray#` but for unlifted data. I wouldn't want to see the same bulky-but- inexpressive interface show up again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 00:26:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 00:26:47 -0000 Subject: [GHC] #14198: Inconsistent treatment of implicitly bound kind variables as free-floating Message-ID: <050.fc7092bf8815668ee061af436c2c49de@haskell.org> #14198: Inconsistent treatment of implicitly bound kind variables as free-floating -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #7873 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (Spun off from the discussion starting at https://phabricator.haskell.org/D3872#109927.) This program is accepted: {{{#!hs {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} import Data.Proxy data Foo = MkFoo (forall a. Proxy a) }}} There's something interesting going on here, however. Because `PolyKinds` is enabled, the kind of `a` is generalized to `k`. But where does `k` get quantified? It turns out that it's implicitly quantified as an existential type variable to `MkFoo`: {{{ λ> :i Foo data Foo = forall k. MkFoo (forall (a :: k). Proxy a) }}} This was brought up some time ago in #7873, where the conclusion was to keep this behavior. But to make things stranger, it you write out the kind of `a` explicitly: {{{#!hs {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} import Data.Proxy data Foo2 = MkFoo2 (forall (a :: k). Proxy a) }}} Then GHC will reject it: {{{ Bug.hs:7:1: error: Kind variable ‘k’ is implicitly bound in data type ‘Foo2’, but does not appear as the kind of any of its type variables. Perhaps you meant to bind it (with TypeInType) explicitly somewhere? | 7 | data Foo2 = MkFoo2 (forall (a :: k). Proxy a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} So GHC's treatment is inconsistent. What should GHC do? We could: * Have both be an error. * Have both be accepted, and implicitly quantify `k` as an existential type variable * Have both be accepted, and implicitly quantify `k` in the `forall` itself. That is: {{{#!hs MkFoo :: (forall {k} (a :: k). Proxy k a) -> Foo }}} * Something else. When you try a similar trick with type synonyms: {{{#!hs {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} import Data.Proxy type Foo3 = forall a. Proxy a }}} Instead of generalizing the kind of `a`, its kind will default to `Any`: {{{ λ> :i Foo3 type Foo3 = forall (a :: GHC.Types.Any). Proxy a }}} Would that be an appropriate trick for data types as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 00:27:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 00:27:46 -0000 Subject: [GHC] #14195: Generalize makeStableName# In-Reply-To: <049.9cdce35d0fc3965f8b68b9c3a7f8a10d@haskell.org> References: <049.9cdce35d0fc3965f8b68b9c3a7f8a10d@haskell.org> Message-ID: <064.0cc4ff2a0749d75fa2f064e26f2c2048@haskell.org> #14195: Generalize makeStableName# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: patch Priority: low | 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): Phab:D3928 Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): You're right. To actually make this be safe, we would have to redefine `StableName#` as well: {{{#!hs data StableName# s a makeStableName# :: a -> State# s -> (#State# s, StableName# s a#) }}} And now you can't use `runST` create a `StableName` at the top level like you did before. But, now this becomes a more annoying change to make. I'm going to go ahead and close this because, as you've pointed out, it's not as simple to do as I thought, and because I've realized that I don't actually need to use `StableName` to accomplish the thing I was originally planning on doing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 00:28:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 00:28:16 -0000 Subject: [GHC] #14195: Generalize makeStableName# In-Reply-To: <049.9cdce35d0fc3965f8b68b9c3a7f8a10d@haskell.org> References: <049.9cdce35d0fc3965f8b68b9c3a7f8a10d@haskell.org> Message-ID: <064.f55f1d2d1b55015580f366f197c005fe@haskell.org> #14195: Generalize makeStableName# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: closed Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3928 Wiki Page: | -------------------------------------+------------------------------------- Changes (by andrewthad): * status: patch => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 00:43:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 00:43:48 -0000 Subject: [GHC] #14140: Better treatment for dataToTag In-Reply-To: <046.9a79626424ac111932e061637da60868@haskell.org> References: <046.9a79626424ac111932e061637da60868@haskell.org> Message-ID: <061.4aebf2756c8760701e4141f58add8792@haskell.org> #14140: Better treatment for dataToTag -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): https://git.haskell.org/ghc.git/blob/HEAD:/compiler/prelude/PrelRules.hs#l903 ("b" case) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 03:55:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 03:55:32 -0000 Subject: [GHC] #14163: Stack Overflow with ApplicativeDo In-Reply-To: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> References: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> Message-ID: <062.3420b5d67198fb00fceb069aeb26f132@haskell.org> #14163: Stack Overflow with ApplicativeDo -------------------------------------+------------------------------------- Reporter: lippling | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo 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): Phab:D3900 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"011e15aa2d6949fc56126f1028ea25d5497196d9/ghc" 011e15aa/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="011e15aa2d6949fc56126f1028ea25d5497196d9" Deal with unbreakable blocks in Applicative Do The renamer wasn't able to deal with more than a couple strict patterns in a row with `ApplicativeDo` when using the heuristic splitter. Update it to work with them properly. Reviewers: simonmar, austin, bgamari, hvr Reviewed By: simonmar Subscribers: RyanGlScott, lippling, rwbarton, thomie GHC Trac Issues: #14163 Differential Revision: https://phabricator.haskell.org/D3900 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 04:06:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 04:06:41 -0000 Subject: [GHC] #14163: Stack Overflow with ApplicativeDo In-Reply-To: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> References: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> Message-ID: <062.b6f50f68053fc454c014de05566f4db1@haskell.org> #14163: Stack Overflow with ApplicativeDo -------------------------------------+------------------------------------- Reporter: lippling | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo 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): Phab:D3900 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 04:27:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 04:27:42 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.07e2b32b4f440b65ca3e63b93efcbc66@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D854 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * keywords: => datacon-tags -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 04:36:07 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 04:36:07 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.dc3cb39978f0ffb9d557473dc50efca3@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D854 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): This doesn't really have much to do with datacon tags, but it seems to relate to several of those tickets, so I tagged it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 04:45:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 04:45:15 -0000 Subject: [GHC] #14199: Document Type.Reflection better (Fun and Con') Message-ID: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> #14199: Document Type.Reflection better (Fun and Con') -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Keywords: Typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The pattern synonym `Type.Reflection.Fun` is not documented at all. Since it seems a bit subtle (`(->)` being more than just a type constructor), I think it actually deserves ''extra'' documentation, with examples. The pattern synonym `Type.Reflection.Con'` is insufficiently documented. Some examples would probably help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 05:23:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 05:23:57 -0000 Subject: [GHC] #14199: Document Type.Reflection better (Fun and Con') In-Reply-To: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> References: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> Message-ID: <060.5afcb3d90c3fb8456104890b3da89488@haskell.org> #14199: Document Type.Reflection better (Fun and Con') -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * component: Compiler => Core Libraries -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 06:30:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 06:30:23 -0000 Subject: [GHC] #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs In-Reply-To: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> References: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> Message-ID: <057.1245a75f027b016ce4123d7be864fe44@haskell.org> #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: gdb, | debugging Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Ah, so this is something to do with gdb's generate-core-file. Ordinary core dumps work just fine, e.g. if I send SIGQUIT to the process by hitting `^\`: {{{ > ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.2 > ghc foo.hs > ./foo ^\Quit (core dumped) > ls -l core -rw------- 1 smarlow smarlow 1589248 Sep 8 07:26 core > gdb foo core GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from foo...done. [New LWP 21001] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `./foo'. Program terminated with signal SIGQUIT, Quit. #0 0x00007fcd7124c573 in __select_nocancel () at ../sysdeps/unix/syscall- template.S:84 84 ../sysdeps/unix/syscall-template.S: No such file or directory. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 06:42:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 06:42:31 -0000 Subject: [GHC] #14193: Add RTS flag to disable 1TB address space allocaiton In-Reply-To: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> References: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> Message-ID: <057.1ee592f6358de5421c8a72e7a57c5d57@haskell.org> #14193: Add RTS flag to disable 1TB address space allocaiton -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9706, #14192 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): This seems to suggest that we should use PROT_NONE instead of MAP_NORESERVE to work around issues with overcommit: https://lwn.net/Articles/627557/ As I said over in #14192, adding a flag to disable the large address space would have a performance cost, because we'd have to check the flag in the inner loop of the GC, so I'd rather avoid that if at all possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 06:49:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 06:49:21 -0000 Subject: [GHC] #14193: Add RTS flag to disable 1TB address space allocaiton In-Reply-To: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> References: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> Message-ID: <057.0c902809ab7703063babbd87688a6745@haskell.org> #14193: Add RTS flag to disable 1TB address space allocaiton -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9706, #14192 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Patch to solve the same problem in webkit, here it looks like using PROT_NONE to reserve and mprotect() to commit works around the overcommit issue: http://trac.webkit.org/changeset/137994/webkit -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 08:04:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 08:04:16 -0000 Subject: [GHC] #14200: Deprecate WrappedMonad Message-ID: <051.447cff6d6c1ed5d45ef4810f633d37c6@haskell.org> #14200: Deprecate WrappedMonad -------------------------------------+------------------------------------- Reporter: siddhanathan | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: | Version: 8.2.1 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: -------------------------------------+------------------------------------- I believe that `Control.Applicative.WrappedMonad` is obsolete now that AMP is implemented. I would propose deprecating `WrappedMonad` as a result. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 09:02:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 09:02:18 -0000 Subject: [GHC] #14140: Better treatment for dataToTag In-Reply-To: <046.9a79626424ac111932e061637da60868@haskell.org> References: <046.9a79626424ac111932e061637da60868@haskell.org> Message-ID: <061.1f7ef6672d7c7e4425043bde64bb9205@haskell.org> #14140: Better treatment for dataToTag -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: 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): hysl20 is right. Doing stuff in `PrelRules` works if the rewrite we want is something like `dataToTag True ---> 1`. But for this ticket we don't want that. What we know is negative information: `dataToTag x` cannot be `16#`. This is carried by the `OtherCon` uunfolding for `x`. So the place to implement this ticket (if that is behind your question) is `SimplUtils.prepareAlts`. We want to say "if the scrutinee is `dataToTag x` and `x` has an unfolding of `OtherCon [A,B,C]`, then eliminate any alternatives that match those constructors". Something like this in `prepareAlts` {{{ imposs_cons = case scrut of Var v -> otherCons (idUnfolding v) -- as now App dataToTag (Var v) -> map (LitCon . conToTag) (otherCons (idUnfolding v)) _ -> [] }}} That is, * If the scrutinee is `dataToTag v` * And v cannot be `[A,C,F]` * Then we know that `dataToTag v` cannot be `[1#, 3#, 6#]` * And so we can make a suitable `imposs_cons` Does that help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 10:08:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 10:08:27 -0000 Subject: [GHC] #14198: Inconsistent treatment of implicitly bound kind variables as free-floating In-Reply-To: <050.fc7092bf8815668ee061af436c2c49de@haskell.org> References: <050.fc7092bf8815668ee061af436c2c49de@haskell.org> Message-ID: <065.62d060dfffba6522381c87f537a1ac73@haskell.org> #14198: Inconsistent treatment of implicitly bound kind variables as free-floating -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7873 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > (Spun off from the discussion starting at > https://phabricator.haskell.org/D3872#109927.) > > This program is accepted: > > {{{#!hs > {-# LANGUAGE ExistentialQuantification #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE RankNTypes #-} > > import Data.Proxy > > data Foo = MkFoo (forall a. Proxy a) > }}} > > There's something interesting going on here, however. Because `PolyKinds` > is enabled, the kind of `a` is generalized to `k`. But where does `k` get > quantified? It turns out that it's implicitly quantified as an > existential type variable to `MkFoo`: > > {{{ > λ> :i Foo > data Foo = forall k. MkFoo (forall (a :: k). Proxy a) > }}} > > This was brought up some time ago in #7873, where the conclusion was to > keep this behavior. > > But to make things stranger, it you write out the kind of `a` explicitly: > > {{{#!hs > {-# LANGUAGE ExistentialQuantification #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE RankNTypes #-} > > import Data.Proxy > > data Foo2 = MkFoo2 (forall (a :: k). Proxy a) > }}} > > Then GHC will reject it: > > {{{ > Bug.hs:7:1: error: > Kind variable ‘k’ is implicitly bound in data type > ‘Foo2’, but does not appear as the kind of any > of its type variables. Perhaps you meant > to bind it (with TypeInType) explicitly somewhere? > | > 7 | data Foo2 = MkFoo2 (forall (a :: k). Proxy a) > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > }}} > > So GHC's treatment is inconsistent. What should GHC do? We could: > > * Have both be an error. > * Have both be accepted, and implicitly quantify `k` as an existential > type variable > * Have both be accepted, and implicitly quantify `k` in the `forall` > itself. That is: > > {{{#!hs > MkFoo :: (forall {k} (a :: k). Proxy k a) -> Foo > }}} > * Something else. When you try a similar trick with type synonyms: > > {{{#!hs > {-# LANGUAGE ExistentialQuantification #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE RankNTypes #-} > > import Data.Proxy > > type Foo3 = forall a. Proxy a > }}} > > Instead of generalizing the kind of `a`, its kind will default to > `Any`: > > {{{ > λ> :i Foo3 > type Foo3 = forall (a :: GHC.Types.Any). Proxy a > }}} > > Would that be an appropriate trick for data types as well? New description: (Spun off from the discussion starting at https://phabricator.haskell.org/D3872#109927.) This program is accepted: {{{#!hs {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} import Data.Proxy data Foo = MkFoo (forall a. Proxy a) }}} There's something interesting going on here, however. Because `PolyKinds` is enabled, the kind of `a` is generalized to `k`. But where does `k` get quantified? It turns out that it's implicitly quantified as an existential type variable to `MkFoo`: {{{ λ> :i Foo data Foo = forall k. MkFoo (forall (a :: k). Proxy a) }}} This was brought up some time ago in #7873, where the conclusion was to keep this behavior. But it's strange becuase the `k` is existential, so the definition is probably unusable. But to make things stranger, it you write out the kind of `a` explicitly: {{{#!hs {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} import Data.Proxy data Foo2 = MkFoo2 (forall (a :: k). Proxy a) }}} Then GHC will reject it: {{{ Bug.hs:7:1: error: Kind variable ‘k’ is implicitly bound in data type ‘Foo2’, but does not appear as the kind of any of its type variables. Perhaps you meant to bind it (with TypeInType) explicitly somewhere? | 7 | data Foo2 = MkFoo2 (forall (a :: k). Proxy a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} So GHC's treatment is inconsistent. What should GHC do? We could: * Have both be an error. * Have both be accepted, and implicitly quantify `k` as an existential type variable * Have both be accepted, and implicitly quantify `k` in the `forall` itself. That is: {{{#!hs MkFoo :: (forall {k} (a :: k). Proxy k a) -> Foo }}} * Something else. When you try a similar trick with type synonyms: {{{#!hs {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} import Data.Proxy type Foo3 = forall a. Proxy a }}} Instead of generalizing the kind of `a`, its kind will default to `Any`: {{{ λ> :i Foo3 type Foo3 = forall (a :: GHC.Types.Any). Proxy a }}} Would that be an appropriate trick for data types as well? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 10:35:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 10:35:18 -0000 Subject: [GHC] #14196: Replace ArrayArray# with either UnliftedArray# or Array# In-Reply-To: <049.e6e8e74aa5747261fafcac4ff3c72b33@haskell.org> References: <049.e6e8e74aa5747261fafcac4ff3c72b33@haskell.org> Message-ID: <064.b25947dba413b428b1cd17b9c89aaeff@haskell.org> #14196: Replace ArrayArray# with either UnliftedArray# or Array# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK now I get it. I had to look at [https://downloads.haskell.org/~ghc/7.4.2/docs/html/libraries/ghc- prim-0.2.0.0/GHC-Prim.html#v:indexArrayArrayArray-35- the documentation for ArrayArray#]. If I may say it like this: The current primitive data type `ArrayArray#` is a heap-allocated array of pointers to unlifted objects. Any kind of unlifted objects would be fine, provide they are represented by a pointer. Specifically, we can put both `Array#` and `ByteArray#` (and I suppose another `ArrayArray#`) inside an `ArrayArray#`. But doing so is jolly awkwerd because `ArrayArray#` is not a parameterised type. Why isn't it parameterised? Becuase previously we had no way to quantify over unlifted types. But now we do. So we can make `ArrayArray#` into a paremterised type, namely your new {{{ data UnliftedArray# (a :: TYPE 'UnliftedRep) }}} Your idea here is that `UniftedArray#` is an array of pointers to ''unlifted'' values. Cool, I like it. Levity polymorphism is great. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 12:34:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 12:34:53 -0000 Subject: [GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" Message-ID: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- = The basic Ideas Currently GHC uses Augustssons algorithm for pattern matching which was published in 85 which works fine for many cases. However there has been research on how to do better than that for a while now. Most notably by Maranget in "Compiling Pattern Matching to Good Decision Trees". I plan to look into applying his ideas to GHC for my undergraduate thesis. Thanks to imprecise exceptions we should be able to reorder argument evaluation as long as this doesn't make our programs more strict. Proofing that is high on my bucket list but hasn't been done yet. = Pros and Cons **Advantages** would be: * It should lead to equal or better code for the vast majority of patterns. * It might reduce compile times for cases were we can desugar directly to good code. **Disadvantages**: * Desugaring gets more complex. It' obvious that since the underlying algorithm is more complex the desugarer would also grow in complexity in accordance. It is hard to say in advance how much of a difference it will make but I hope it won't be too bad. Depending on the runtime of the new algorithm compared to the old one this might also speed up compilation for cases where the old algorithm generated code that had to be heavily optimized by the simplifier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 12:35:14 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 12:35:14 -0000 Subject: [GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" In-Reply-To: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> References: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> Message-ID: <062.eff8ae4ad70f4cc5bf80a62c638fd36d@haskell.org> #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * owner: (none) => AndreasK -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 13:08:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 13:08:16 -0000 Subject: [GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" In-Reply-To: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> References: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> Message-ID: <062.d47b9ab22e1b905eda1cf73d0b402b2b@haskell.org> #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Be careful not to change the strictness of the function. That's what has prevent most such attempts in the past. (But perhaps strict data constructors, if the program uses them, may help.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 13:17:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 13:17:23 -0000 Subject: [GHC] #14200: Deprecate WrappedMonad In-Reply-To: <051.447cff6d6c1ed5d45ef4810f633d37c6@haskell.org> References: <051.447cff6d6c1ed5d45ef4810f633d37c6@haskell.org> Message-ID: <066.5ce2f3177b445be7c160347901b0feff@haskell.org> #14200: Deprecate WrappedMonad -------------------------------------+------------------------------------- Reporter: siddhanathan | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | 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: #13876 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: hvr, ekmett, core-libraries-committee@… (added) * related: => #13876 Comment: I'm inclined to agree here. At one point in time, where `return` was a canonical class method of `Monad`, it was commonplace to define `Applicative` and `Functor` methods entirely in terms of `Monad` methods. But now `return = pure`, and there are [https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn plans] to eventually remove `return` as a class method of `Monad` entirely. When this happens, `WrappedMonad` won't be nearly as useful as it once was, since one won't be able to define `Applicative(pure)` from an arbitrary `Monad` instance anymore (see also #13876). This makes the utility of a `WrappedMonad` newtype dubious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 13:18:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 13:18:04 -0000 Subject: [GHC] #13876: Check 'pure' method of 'Applicative (WrappedMonad m)' In-Reply-To: <051.5c5537466ef9d8fe586780eff30179d7@haskell.org> References: <051.5c5537466ef9d8fe586780eff30179d7@haskell.org> Message-ID: <066.172a2801c665d69f67b8035377f8cb55@haskell.org> #13876: Check 'pure' method of 'Applicative (WrappedMonad m)' -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14200 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #14200 Comment: Note that there is talk of deprecating `WrappedMonad` entirely, which may make this ticket moot. See #14200. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 13:28:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 13:28:26 -0000 Subject: [GHC] #14200: Deprecate WrappedMonad In-Reply-To: <051.447cff6d6c1ed5d45ef4810f633d37c6@haskell.org> References: <051.447cff6d6c1ed5d45ef4810f633d37c6@haskell.org> Message-ID: <066.0fb730937c2daef9fcebe4e31aa4f68f@haskell.org> #14200: Deprecate WrappedMonad -------------------------------------+------------------------------------- Reporter: siddhanathan | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | 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: #13876 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): I am inclined to agree -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 13:35:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 13:35:34 -0000 Subject: [GHC] #14193: Add RTS flag to disable 1TB address space allocaiton In-Reply-To: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> References: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> Message-ID: <057.945f578f940539ec92b7e9b78c77413c@haskell.org> #14193: Add RTS flag to disable 1TB address space allocaiton -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9706, #14192 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Is this really the same problem? We already map with `PROT_NONE` when reserving. The only real difference between WebKit after that patch and us is the use of `madvise(MADV_DONTNEED)` after reservation; I wonder if this affects the core dump logic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 13:38:59 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 13:38:59 -0000 Subject: [GHC] #14193: Add RTS flag to disable 1TB address space allocaiton In-Reply-To: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> References: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> Message-ID: <057.f5b2d79e39622ebb9396198eaecf06d5@haskell.org> #14193: Add RTS flag to disable 1TB address space allocaiton -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: feature request | 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: #9706, #14192 | Differential Rev(s): Phab:D3929 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3929 Comment: Here is a patch trying this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 14:09:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 14:09:02 -0000 Subject: [GHC] #14202: Haskell Admin install Message-ID: <049.db61b4c513e7fe95e1a2fd966f773248@haskell.org> #14202: Haskell Admin install --------------------------------------+---------------------------- Reporter: acraig4csc | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------- I am preparing an image for deployment in a Windows teaching computer suite. Need to do a Haskell Platform install for ALL users. What permissions does stack require? Installing to default location (%AppData%\Roaming\local\bin\)is not appropriate for us, can this be installed to C:\Program Files\Haskell Platform\Stack\ ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 14:24:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 14:24:28 -0000 Subject: [GHC] #14203: GHC-inferred type signature doesn't actually typecheck Message-ID: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> #14203: GHC-inferred type signature doesn't actually typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code typechecks: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind data TyFun :: * -> * -> * type a ~> b = TyFun a b -> * infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 data family Sing :: k -> * data Sigma (a :: *) :: (a ~> *) -> * where MkSigma :: forall (a :: *) (p :: a ~> *) (x :: a). Sing x -> Apply p x -> Sigma a p data instance Sing (z :: Sigma a p) where SMkSigma :: Sing sx -> Sing px -> Sing (MkSigma sx px) }}} I was curious to know what the full type signature of `SMkSigma` was, so I asked GHCi what the inferred type is: {{{ λ> :i SMkSigma data instance Sing z where SMkSigma :: forall a (p :: a ~> *) (x :: a) (sx :: Sing x) (px :: Apply p x). (Sing sx) -> (Sing px) -> Sing ('MkSigma sx px) }}} I attempted to incorporate this newfound knowledge into the program: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind data TyFun :: * -> * -> * type a ~> b = TyFun a b -> * infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 data family Sing :: k -> * data Sigma (a :: *) :: (a ~> *) -> * where MkSigma :: forall (a :: *) (p :: a ~> *) (x :: a). Sing x -> Apply p x -> Sigma a p data instance Sing (z :: Sigma a p) where SMkSigma :: forall a (p :: a ~> *) (x :: a) (sx :: Sing x) (px :: Apply p x). Sing sx -> Sing px -> Sing (MkSigma sx px) }}} But to my surprise, adding this inferred type signature causes the program to no longer typecheck! {{{ GHCi, version 8.3.20170907: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:23:31: error: • Expected kind ‘Apply p0 x’, but ‘px’ has kind ‘Apply p1 x’ • In the first argument of ‘Sing’, namely ‘px’ In the type ‘Sing px’ In the definition of data constructor ‘SMkSigma’ | 23 | Sing sx -> Sing px -> Sing (MkSigma sx px) | ^^ }}} I'm showing the output of GHC HEAD here, but this bug can be reproduced all the way back to GHC 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 14:58:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 14:58:01 -0000 Subject: [GHC] #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs In-Reply-To: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> References: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> Message-ID: <057.1cad2594f4c06655277621f4c91cf3ae@haskell.org> #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: gdb, | debugging Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ahh, so it does. Well this is unfortunate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 15:17:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 15:17:57 -0000 Subject: [GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" In-Reply-To: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> References: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> Message-ID: <062.f1fdcd6a6d04a93988e59a6d26fdc697@haskell.org> #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): Indeed. My plan currently is to select columns in the pattern matrix such that we only choose from these strict in the first row. But my plan is to first formalize the interaction with imprecise exceptions. Then work out heuristics compatible with laziness. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 15:52:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 15:52:43 -0000 Subject: [GHC] #11767: Add @since annotations for base instances In-Reply-To: <046.80486230653199e8f5fef1dcd513180c@haskell.org> References: <046.80486230653199e8f5fef1dcd513180c@haskell.org> Message-ID: <061.9512f6752de613354de040d00e405de1@haskell.org> #11767: Add @since annotations for base instances -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11768 | Differential Rev(s): Phab:D2277 Wiki Page: | -------------------------------------+------------------------------------- Comment (by siddhanathan): As far as I can tell, there is no such thing as base 2.01 There is base 2.0, and there is base 2.1; the oldest version of base is 1.0 Easy check: `git log -L 2,2:base.cabal` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 16:11:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 16:11:10 -0000 Subject: [GHC] #14204: GHC bug - makeStatic: Unresolved static form at line 13, column 14. Message-ID: <044.608ae49365e437b7204c6823db40398f@haskell.org> #14204: GHC bug - makeStatic: Unresolved static form at line 13, column 14. -------------------------------------+------------------------------------- Reporter: jchia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Building and running the attached code results in the above error mesage. Enabling StaticPointers in the code makes the error go away. GHC should either reject the code or generate code that works properly at run-time, depending on the fine points of how TH is supposed to interact with StaticPointers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 16:12:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 16:12:11 -0000 Subject: [GHC] #14204: GHC bug - makeStatic: Unresolved static form at line 13, column 14. In-Reply-To: <044.608ae49365e437b7204c6823db40398f@haskell.org> References: <044.608ae49365e437b7204c6823db40398f@haskell.org> Message-ID: <059.7722d4a4bc360911d3e9e1f866ddf82b@haskell.org> #14204: GHC bug - makeStatic: Unresolved static form at line 13, column 14. -------------------------------------+------------------------------------- Reporter: jchia | 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: | -------------------------------------+------------------------------------- Changes (by jchia): * Attachment "staticPointerBug.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 16:13:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 16:13:20 -0000 Subject: [GHC] #14204: GHC bug - makeStatic: Unresolved static form at line 13, column 14. In-Reply-To: <044.608ae49365e437b7204c6823db40398f@haskell.org> References: <044.608ae49365e437b7204c6823db40398f@haskell.org> Message-ID: <059.523310e71f198cae70e8ff9f65899aa6@haskell.org> #14204: GHC bug - makeStatic: Unresolved static form at line 13, column 14. -------------------------------------+------------------------------------- Reporter: jchia | 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 jchia): This was reproduced under stack using nightly-2017-09-07. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 16:14:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 16:14:10 -0000 Subject: [GHC] #14204: GHC bug - makeStatic: Unresolved static form at line 13, column 14. In-Reply-To: <044.608ae49365e437b7204c6823db40398f@haskell.org> References: <044.608ae49365e437b7204c6823db40398f@haskell.org> Message-ID: <059.4d94f26e1df27b7b86004cd4e00a52e8@haskell.org> #14204: GHC bug - makeStatic: Unresolved static form at line 13, column 14. -------------------------------------+------------------------------------- Reporter: jchia | 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: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jchia): * failure: None/Unknown => Runtime crash -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 16:15:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 16:15:27 -0000 Subject: [GHC] #14204: GHC bug - makeStatic: Unresolved static form at line 13, column 14. In-Reply-To: <044.608ae49365e437b7204c6823db40398f@haskell.org> References: <044.608ae49365e437b7204c6823db40398f@haskell.org> Message-ID: <059.a2410b434401109ad4552ed0a2abae86@haskell.org> #14204: GHC bug - makeStatic: Unresolved static form at line 13, column 14. -------------------------------------+------------------------------------- Reporter: jchia | 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: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by jchia: Old description: > Building and running the attached code results in the above error mesage. > Enabling StaticPointers in the code makes the error go away. > > GHC should either reject the code or generate code that works properly at > run-time, depending on the fine points of how TH is supposed to interact > with StaticPointers. New description: Building and running the attached code results in the above crash error mesage. Enabling StaticPointers in the code makes the error go away. GHC should either reject the code or generate code that works properly at run-time, depending on the fine points of how TH is supposed to interact with the enablement of StaticPointers. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 17:36:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 17:36:19 -0000 Subject: [GHC] #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs In-Reply-To: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> References: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> Message-ID: <057.b1e7ec4fd193d6bba19eb7bc35f91bbc@haskell.org> #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: gdb, | debugging Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): It there another way to take a core dump of a running program without terminating it that could be used in this situation? Also, is it known why the gdb approach doesn't work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 18:01:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 18:01:34 -0000 Subject: [GHC] #13709: Drop GCC Driver In-Reply-To: <044.530378a7ad6f5c3b791a9c874c84177d@haskell.org> References: <044.530378a7ad6f5c3b791a9c874c84177d@haskell.org> Message-ID: <059.ffbe2fa5ac081c8fc33724dc4975de01@haskell.org> #13709: Drop GCC Driver ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3592 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by siddhanathan): * status: new => closed * resolution: => fixed Comment: Closing the issue. Please reopen if this was an error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 18:32:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 18:32:06 -0000 Subject: [GHC] #14140: Better treatment for dataToTag In-Reply-To: <046.9a79626424ac111932e061637da60868@haskell.org> References: <046.9a79626424ac111932e061637da60868@haskell.org> Message-ID: <061.770728fb4ba891a2511e0fa23586a220@haskell.org> #14140: Better treatment for dataToTag -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: 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): Yes, that's exactly what I was looking for. I'm trying it now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 18:39:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 18:39:00 -0000 Subject: [GHC] #14204: GHC bug - makeStatic: Unresolved static form at line 13, column 14. In-Reply-To: <044.608ae49365e437b7204c6823db40398f@haskell.org> References: <044.608ae49365e437b7204c6823db40398f@haskell.org> Message-ID: <059.f87da76c9ff0ccc2bb357bc5735f4140@haskell.org> #14204: GHC bug - makeStatic: Unresolved static form at line 13, column 14. -------------------------------------+------------------------------------- Reporter: jchia | 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: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here's a much more minimal example: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Bug where import GHC.StaticPtr import Language.Haskell.TH main :: IO () main = putStrLn (deRefStaticPtr $(pure (StaticE (LitE (StringL "wat"))))) }}} I don't know too much about the subtleties of static pointers, but perhaps the simplest fix would be to add an extra check to see if `-XStaticPointers` is enabled before using them in Template Haskell? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 18:57:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 18:57:40 -0000 Subject: [GHC] #13709: Drop GCC Driver In-Reply-To: <044.530378a7ad6f5c3b791a9c874c84177d@haskell.org> References: <044.530378a7ad6f5c3b791a9c874c84177d@haskell.org> Message-ID: <059.5b756ea28abcc63adc63d683e06ad0a4@haskell.org> #13709: Drop GCC Driver ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3592 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * status: closed => new * resolution: fixed => Comment: This patch was reverted. So the issue is still open. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 19:15:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 19:15:23 -0000 Subject: [GHC] #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs In-Reply-To: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> References: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> Message-ID: <057.893ccc3c3555060a810c72f6e5a6afcc@haskell.org> #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: gdb, | debugging Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nicolast): May also depend on GDB version: https://sourceware.org/bugzilla/show_bug.cgi?id=16092 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 19:20:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 19:20:35 -0000 Subject: [GHC] #14193: Add RTS flag to disable 1TB address space allocation (was: Add RTS flag to disable 1TB address space allocaiton) In-Reply-To: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> References: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> Message-ID: <057.8c79ee34c52ce151f21c7008410f8e98@haskell.org> #14193: Add RTS flag to disable 1TB address space allocation -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: feature request | 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: #9706, #14192 | Differential Rev(s): Phab:D3929 Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 19:33:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 19:33:31 -0000 Subject: [GHC] #14193: Add RTS flag to disable 1TB address space allocation In-Reply-To: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> References: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> Message-ID: <057.1ec7514ec26afd99b18b2c5dc6b992b0@haskell.org> #14193: Add RTS flag to disable 1TB address space allocation -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: feature request | 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: #9706, #14192 | Differential Rev(s): Phab:D3929 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Replying to [comment:1 simonmar]: > adding a flag to disable the large address space would have a performance cost, because we'd have to check the flag in the inner loop of the GC @simonmar do you recall if the impact of this was already measured when the new allocator was introduced, or would there be value in me giving it a try? I have some wishful thinking that if branch prediction and pipelining are on our side, we might not be able to measure the additional check -- and if it were so I'd welcome the ability to switch it without recompilation (of ghc, or even better, the program). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 19:45:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 19:45:34 -0000 Subject: [GHC] #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs In-Reply-To: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> References: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> Message-ID: <057.0ea1c280e96f588c764f07f92f06fe9d@haskell.org> #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: gdb, | debugging Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): > May also depend on GDB version: https://sourceware.org/bugzilla/show_bug.cgi?id=16092 My gdb (>= 7.11.1) certainly has the feature; I found it can be checked with `show use-coredump-filter`. There must be more smarts or difference in behaviour that Linux has but GDB doesn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 19:46:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 19:46:27 -0000 Subject: [GHC] #14204: GHC bug - makeStatic: Unresolved static form at line 13, column 14. In-Reply-To: <044.608ae49365e437b7204c6823db40398f@haskell.org> References: <044.608ae49365e437b7204c6823db40398f@haskell.org> Message-ID: <059.5f3d18aef7f15ba6ab2b98f98d165760@haskell.org> #14204: GHC bug - makeStatic: Unresolved static form at line 13, column 14. -------------------------------------+------------------------------------- Reporter: jchia | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3931 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => StaticPointers * status: new => patch * differential: => Phab:D3931 * component: Compiler => Template Haskell Comment: With Phab:D3931, the attached program now fails with a sensible error message: {{{ staticPointerBug.hs:13:14: error: • Illegal static expression: static foo Use StaticPointers to enable this extension • In the untyped splice: $(cstatic 'foo) | 13 | let cl = $(cstatic 'foo) | ^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 20:21:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 20:21:40 -0000 Subject: [GHC] #14140: Better treatment for dataToTag In-Reply-To: <046.9a79626424ac111932e061637da60868@haskell.org> References: <046.9a79626424ac111932e061637da60868@haskell.org> Message-ID: <061.2ef7502b50491382ade9bee194622e68@haskell.org> #14140: Better treatment for dataToTag -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3932 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D3932 Comment: I think I probably did that right... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 21:37:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 21:37:27 -0000 Subject: [GHC] #14140: Better treatment for dataToTag In-Reply-To: <046.9a79626424ac111932e061637da60868@haskell.org> References: <046.9a79626424ac111932e061637da60868@haskell.org> Message-ID: <061.20f15c3a7a095d7afcabb2b4183ef734@haskell.org> #14140: Better treatment for dataToTag -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3932 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Argh! I should have checked this against HEAD. It seems this was already fixed, in 193664d42dbceadaa1e4689dfa17ff1cf5a405a0. We now rewrite {{{#!hs case dataToTag b of 16# -> True _ -> False }}} to {{{#!hs case b of OtherOS _ -> True _ -> False }}} which has always been good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 22:07:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 22:07:48 -0000 Subject: [GHC] #13910: Inlining a definition causes GHC to panic (repSplitTyConApp_maybe) In-Reply-To: <050.14bd55ba33332ff15d7c16c4f0c73fad@haskell.org> References: <050.14bd55ba33332ff15d7c16c4f0c73fad@haskell.org> Message-ID: <065.75b3beef211eba77dcb9d2a3b4f18e91@haskell.org> #13910: Inlining a definition causes GHC to panic (repSplitTyConApp_maybe) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: 14119 | Blocking: Related Tickets: #13877, #14038, | Differential Rev(s): #14175 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Richard, I need your help on this. I don't know whtether this problem is ultimately the source of the crash, but with my stage-1 compiler I get a earlier ASSERT failure, and some investigation shows that a type-family reduction is leading to an entirely bogus result. It's like this. We have an axiom {{{ forall (k1 :: Type) (k2 :: Type) (f :: k1 ~> k2) (x :: k1). App k1 (':~>) k2 (f |> Sym (D:R:Funk1:~>k2{tc r14K}[0] _N _N)) x = @@ k1 k2 f x }}} But then we come across a call which we give to `reduceTyFamApp_maybe`: {{{ App w_a2c6 (':~>) Type ((p :: t ~> Type) |> HoleCo {a2cb}) w_a2c6 }}} This is alraedy odd. I expected the arguments to be zonked before this attempt to do type-family reduction, but they aren't. In this case `w_a2c6` is already unified with `p`. But it gets worse. When we reduce the application, we get a result looking like {{{ @@ w_a2c6 Type (p |> Sym (Sym (D:R:Funk1:~>k2 _N _N) ; Sym (HoleCo {a2cb}))) w_a2ca }}} Yes, you saw it right. The `k1` and `k2` from the LHS of the axiom have shown up in the result!!! Turns out that this is because of the treatment of cases in matching. In `Unify.hs` we see {{{ unify_ty env ty1 ty2 kco -- TODO: More commentary needed here | CastTy ty1' co <- ty1 = unify_ty env ty1' ty2 (co `mkTransCo` kco) | CastTy ty2' co <- ty2 = unify_ty env ty1 ty2' (kco `mkTransCo` mkSymCo co) }}} So coercions from the LHS and RHS both end up mixed together in that `kco`; and it ultimately shows up in the result subsitution. I'm not sure what the fix is. Maybe we can just apply the ambient substition to the `co`; but what if template variables it mentions have not yet been bound yet? Or maybe we need to take the fixpoint of the returned substitution; we do this for unification, maybe we need it for matching too? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 22:09:39 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 22:09:39 -0000 Subject: [GHC] #14090: Static pointers are not being registered under certain conditions In-Reply-To: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> References: <047.12f3e0de1a9e7f13fc1f3fb0daf8fe15@haskell.org> Message-ID: <062.7a0be4e87d4f0640ab28e9441e1f401c@haskell.org> #14090: Static pointers are not being registered under certain conditions -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: bug | Status: patch 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): Phab:D3843 Wiki Page: | Phab:D3933 -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * differential: Phab:D3843 => Phab:D3843 Phab:D3933 Comment: I documented better {{{staticPtrKeys}}} in D3933. Let me know if more documentation is needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 22:14:39 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 22:14:39 -0000 Subject: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file. In-Reply-To: <046.5a1fb6c2a5c75e33d964893f8930e4ec@haskell.org> References: <046.5a1fb6c2a5c75e33d964893f8930e4ec@haskell.org> Message-ID: <061.4132949983d2895572b5e68648c349b0@haskell.org> #6132: Can't use both shebang line and #ifdef declarations in the same file. -------------------------------------+------------------------------------- Reporter: gfxmonk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.0.4 (Parser) | Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: runghc/T6132 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 22:14:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 22:14:41 -0000 Subject: [GHC] #14140: Better treatment for dataToTag In-Reply-To: <046.9a79626424ac111932e061637da60868@haskell.org> References: <046.9a79626424ac111932e061637da60868@haskell.org> Message-ID: <061.cb50ea5acc4bb86f41a0feb90e18c2c6@haskell.org> #14140: Better treatment for dataToTag -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3932 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Huh, you are right. And that is a better place to do it. So, why isn't it working? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 22:22:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 22:22:45 -0000 Subject: [GHC] #14140: Better treatment for dataToTag In-Reply-To: <046.9a79626424ac111932e061637da60868@haskell.org> References: <046.9a79626424ac111932e061637da60868@haskell.org> Message-ID: <061.dc3a4ac6b1d545d606aeaeed0c7553f1@haskell.org> #14140: Better treatment for dataToTag -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3934 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * differential: Phab:D3932 => Phab:D3934 Comment: I think it ''is'' working, unless it broke very very recently. I've just changed the linked differential to a test case. When I compiled various versions of your code under GHC HEAD (September 1 edition or so), I got exactly what we want. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 8 22:34:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Sep 2017 22:34:20 -0000 Subject: [GHC] #14205: GHCI freaked out when I tryed to load a program and told me to report it as a bug. Message-ID: <046.9b92bcd16a11ec3b6a997f8e9f0df6dc@haskell.org> #14205: GHCI freaked out when I tryed to load a program and told me to report it as a bug. -------------------------------------+------------------------------------- Reporter: Ebanflo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] %_a2g7 :: t_a2g6[tau:1] (CHoleCan: %)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 00:52:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 00:52:22 -0000 Subject: [GHC] #14205: GHCI freaked out when I tryed to load a program and told me to report it as a bug. In-Reply-To: <046.9b92bcd16a11ec3b6a997f8e9f0df6dc@haskell.org> References: <046.9b92bcd16a11ec3b6a997f8e9f0df6dc@haskell.org> Message-ID: <061.35b39dc3008dd5f01cc9a7059dd7cf98@haskell.org> #14205: GHCI freaked out when I tryed to load a program and told me to report it as a bug. -------------------------------------+------------------------------------- Reporter: Ebanflo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13106 Comment: Thanks for the bug report. This is a duplicate of #13106, which has been fixed in GHC 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 10:33:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 10:33:27 -0000 Subject: [GHC] #14140: Better treatment for dataToTag In-Reply-To: <046.9a79626424ac111932e061637da60868@haskell.org> References: <046.9a79626424ac111932e061637da60868@haskell.org> Message-ID: <061.7e29f8e42333a5302cd6fc156410d867@haskell.org> #14140: Better treatment for dataToTag -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3934 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I think it is working, unless it broke very very recently You are right. How mysterious. I can't account for why I ever saw the bad code. But indeed it seems fixed. I recompiled `libraries/Cabal/Cabal/Distribution/System.hs` and it looks fine. Close when you commit the test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 11:26:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 11:26:25 -0000 Subject: [GHC] #14206: Add bit deposit and bit extraction primops Message-ID: <047.2543734720307265ea1bddd575e5fddb@haskell.org> #14206: Add bit deposit and bit extraction primops -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Modern CPUs (on x86, Haswell and newer) have a PDEP instruction for efficient bit deposit and a PEXT instruction for efficient bit extraction. These instructions can be used to implement various data structures. I propose we add the following set of primops {{{#!hs pdep8# :: Word# -> Word# -> Word# pdep16# :: Word# -> Word# -> Word# pdep32# :: Word# -> Word# -> Word# pdep64# :: Word64# -> Word64# -> Word64# pdep# :: Word# -> Word# -> Word# pext8# :: Word# -> Word# -> Word# pext16# :: Word# -> Word# -> Word# pext32# :: Word# -> Word# -> Word# pext64# :: Word64# -> Word64# -> Word64# pext# :: Word# -> Word# -> Word# }}} Each primop compiles into either a single PDEP/PEXT instruction or a call to some fallback function, implemented in C. For reference, see the following library that implements FFI wrapper 32-bit and 64-bit functions for these instructions: https://github.com/haskell-works/hw-prim-bits -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 12:44:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 12:44:31 -0000 Subject: [GHC] #14207: Levity polymorphic GADT requires extra type signatures Message-ID: <049.707faaf04201531d0b28d397d3904370@haskell.org> #14207: Levity polymorphic GADT requires extra type signatures -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This does not compile: {{{#!hs data Foo s (a :: TYPE k) where FooC :: Foo s Int# }}} However, this does: {{{#!hs data Foo (s :: Type) (a :: TYPE k) where FooC :: Foo s Int# }}} This also works: {{{#!hs data Foo (s :: j) (a :: TYPE k) where FooC :: Foo s Int# }}} These are all of the language pragmas I have enabled: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE BangPatterns #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE UnboxedSums #-} {-# LANGUAGE UnboxedTuples #-} {-# LANGUAGE MagicHash #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} }}} This is pretty easy to work around, but I think it's an incorrect behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 13:18:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 13:18:24 -0000 Subject: [GHC] #14208: Performance with -O2 is worse than with -O0 which is worse than runghc Message-ID: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> #14208: Performance with -O2 is worse than with -O0 which is worse than runghc -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- In this particular case `-O2` is 2x slower than `-O0` and `-O0` is 2x slower than `runghc`. Please see the github repo: https://github.com /harendra-kumar/ghc-perf to reproduce the issue. Readme file in the repo has instructions to reproduce. The issue seems to occur when the code is placed in a different module. When all the code is in the same module the problem does not occur. In that case `-O2` is faster than `-O0`. However, when the code is split into two modules the performance gets inverted. Also, it does not occur always, when I tried to change the code to make it simpler for repro the problem did not occur. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 13:39:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 13:39:17 -0000 Subject: [GHC] #14208: Performance with -O2 is worse than with -O0 which is worse than runghc In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.d75854e5c6fc0e1d81d63ddf6a34d82b@haskell.org> #14208: Performance with -O2 is worse than with -O0 which is worse than runghc -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): I added a branch named `does-not-occur` in the repo with a simpler case where the problem does not occur even when the code is split across modules. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 17:03:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 17:03:32 -0000 Subject: [GHC] #14207: Levity polymorphic GADT requires extra type signatures In-Reply-To: <049.707faaf04201531d0b28d397d3904370@haskell.org> References: <049.707faaf04201531d0b28d397d3904370@haskell.org> Message-ID: <064.ac5d87467d2454ecc526210395f95657@haskell.org> #14207: Levity polymorphic GADT requires extra type signatures -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13365 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: LevityPolymorphism => TypeInType * status: new => closed * resolution: => duplicate * related: => #13365 Comment: This is expected behavior, and moreover, this has nothing to do with levity polymorphism. A simpler example of what's going on is this: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeInType #-} module Foo where data Foo s (a :: k) where FooC :: Foo s Int }}} {{{ Foo.hs:6:17: error: • Expected kind ‘k’, but ‘Int’ has kind ‘*’ • In the second argument of ‘Foo’, namely ‘Int’ In the type ‘Foo s Int’ In the definition of data constructor ‘FooC’ | 6 | FooC :: Foo s Int | ^^^ }}} As you noted, this fails to compile, but adding a kind signature to `s` makes it compile. What is happening is that the original definition of `Foo` lacks a **c**omplete, **u**ser-**s**upplied **k**ind signature (or CUSK), because not all type variables are given kinds. See the [https://downloads.haskell.org/~ghc/8.2.1/docs/html/users_guide/glasgow_exts.html?highlight=cusk #complete-user-supplied-kind-signatures-and-polymorphic-recursion users' guide] for more information on what constitutes a CUSK. When `TypeInType` is enabled, GHC performs kind inference for a data type differently depending on whether is has a CUSK or not. When it doesn't have a CUSK, the kind of `a` becomes more rigid than it would otherwise be, preventing `(a :: k)` from unifying with `(Int :: *)`, which explains the error message. The error message with your levity polymorphic example is similar (although the presence of `TYPE` causes an overzealous "Expected a lifted type" error, see #14155). What would be nice is if GHC could warn you about the lack of a CUSK in such scenarios. That is the goal of #13365, so I'll close this ticket as a duplicate of that one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 17:04:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 17:04:33 -0000 Subject: [GHC] #13365: Kind-inference for poly-kinded GADTs In-Reply-To: <047.53ccade2bc7f7794ee330b834d4cc090@haskell.org> References: <047.53ccade2bc7f7794ee330b834d4cc090@haskell.org> Message-ID: <062.a58af106688fcd7b0e306b3eab75a6b1@haskell.org> #13365: Kind-inference for poly-kinded GADTs -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) 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: #14139, #14207 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #14139 => #14139, #14207 Comment: #14207 is another example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 17:28:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 17:28:48 -0000 Subject: [GHC] #14203: GHC-inferred type signature doesn't actually typecheck In-Reply-To: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> References: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> Message-ID: <065.d405a8d4ac8e428d06b822179e072a50@haskell.org> #14203: GHC-inferred type signature doesn't actually typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here's a slightly simpler example that doesn't use `singletons`. This compiles: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind data TyFun :: * -> * -> * type a ~> b = TyFun a b -> * infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 data Foo (z :: Apply (p :: a ~> *) (x :: a)) data Bar where MkBar :: Foo z -> Bar }}} And if you ask GHCi for the type of `MkBar`, you get: {{{ λ> :type +v MkBar MkBar :: forall a (p :: TyFun a * -> *) (x :: a) (z :: Apply p x). Foo z -> Bar }}} But if you try using that: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind data TyFun :: * -> * -> * type a ~> b = TyFun a b -> * infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 data Foo (z :: Apply (p :: a ~> *) (x :: a)) data Bar where MkBar :: forall a (p :: TyFun a * -> *) (x :: a) (z :: Apply p x). Foo z -> Bar }}} It fails: {{{ GHCi, version 8.3.20170907: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:19:16: error: • Expected kind ‘Apply p0 x0’, but ‘z’ has kind ‘Apply p x’ • In the first argument of ‘Foo’, namely ‘z’ In the type ‘Foo z’ In the definition of data constructor ‘MkBar’ | 19 | Foo z -> Bar | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 17:48:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 17:48:55 -0000 Subject: [GHC] #14205: GHCI freaked out when I tryed to load a program and told me to report it as a bug. In-Reply-To: <046.9b92bcd16a11ec3b6a997f8e9f0df6dc@haskell.org> References: <046.9b92bcd16a11ec3b6a997f8e9f0df6dc@haskell.org> Message-ID: <061.659a5e7546fcc4f06b8b6f97b4bce241@haskell.org> #14205: GHCI freaked out when I tryed to load a program and told me to report it as a bug. -------------------------------------+------------------------------------- Reporter: Ebanflo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ebanflo): Alright cool. I ran $sudo apt-get update and then tried to reinstall ghc, but it gave me 8.0.2 again. When will the updated version be available from this repository? If it isn't going to be soon how else can I download it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 17:56:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 17:56:42 -0000 Subject: [GHC] #14205: GHCI freaked out when I tryed to load a program and told me to report it as a bug. In-Reply-To: <046.9b92bcd16a11ec3b6a997f8e9f0df6dc@haskell.org> References: <046.9b92bcd16a11ec3b6a997f8e9f0df6dc@haskell.org> Message-ID: <061.129737046395705092e2f31fda022ca7@haskell.org> #14205: GHCI freaked out when I tryed to load a program and told me to report it as a bug. -------------------------------------+------------------------------------- Reporter: Ebanflo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:2 Ebanflo]: > When will the updated version be available from this repository? That's up to the people who maintain your Linux distribution—we aren't the ones who do that. > If it isn't going to be soon how else can I download it? You can find binary distribution of GHC 8.2.1 [https://www.haskell.org/ghc/download_ghc_8_2_1.html here]. Alternatively, if you use Ubuntu, you can also obtain GHC 8.2.1 from [https://launchpad.net/~hvr/+archive/ubuntu/ghc this Ubuntu PPA]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 19:13:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 19:13:38 -0000 Subject: [GHC] #14208: Performance with -O2 is worse than with -O0 which is worse than runghc In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.7ddb0d2ec02603454d74253eb7be37e6@haskell.org> #14208: Performance with -O2 is worse than with -O0 which is worse than runghc -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I can reproduce this. Thanks for the excellent test case. You can also build everything with `cabal new-build benchmarks`. Adding an `{- INLINABLE toList -}` improves the situation a lot but it is still slower than with -O0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 19:27:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 19:27:43 -0000 Subject: [GHC] #14203: GHC-inferred type signature doesn't actually typecheck In-Reply-To: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> References: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> Message-ID: <065.b8738fd6c97b9e9adaf31c2497d0ce96@haskell.org> #14203: GHC-inferred type signature doesn't actually typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The original programs should be rejected, I think. Looking at your simpler example, the declaration for `Foo` should be rejected as ambiguous. There's no way to tell from `z` what `a`, `x`, or `p` should be. When I continue my bug sweep, I'll take a look at this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 19:29:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 19:29:12 -0000 Subject: [GHC] #14207: Levity polymorphic GADT requires extra type signatures In-Reply-To: <049.707faaf04201531d0b28d397d3904370@haskell.org> References: <049.707faaf04201531d0b28d397d3904370@haskell.org> Message-ID: <064.33d809877e59371f530f0c91e4894fdd@haskell.org> #14207: Levity polymorphic GADT requires extra type signatures -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 8.2.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: #13365 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: TypeInType => TypeInType, CUSKs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 19:36:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 19:36:56 -0000 Subject: [GHC] #14203: GHC-inferred type signature doesn't actually typecheck In-Reply-To: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> References: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> Message-ID: <065.92bf4bcb428745bf8ffff382b6af32a8@haskell.org> #14203: GHC-inferred type signature doesn't actually typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I can accept that the second program (with `MkBar`) would be ambiguous, but I don't understand what is wrong with the original program (with `SMkSigma`), especially the form when an explicit `forall`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 19:45:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 19:45:48 -0000 Subject: [GHC] #14209: GHC 8.2.1 regression involving telescoping kind signature Message-ID: <050.d6ff01fd86ce7c8b5a28dc0adb6995b9@haskell.org> #14209: GHC 8.2.1 regression involving telescoping kind signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 (Type checker) | 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: -------------------------------------+------------------------------------- The following program typechecks in GHC 8.0.1 and 8.0.2: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeInType #-} module Bug where data MyProxy k (a :: k) = MyProxy data Foo (z :: MyProxy k (a :: k)) }}} But in GHC 8.2.1, it's rejected: {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:6:1: error: Kind variable ‘k’ is implicitly bound in datatype ‘Foo’, but does not appear as the kind of any of its type variables. Perhaps you meant to bind it explicitly somewhere? Type variables with inferred kinds: (k :: *) (a :: k) (z :: MyProxy k a) | 6 | data Foo (z :: MyProxy k (a :: k)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 19:48:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 19:48:20 -0000 Subject: [GHC] #14209: GHC 8.2.1 regression involving telescoping kind signature In-Reply-To: <050.d6ff01fd86ce7c8b5a28dc0adb6995b9@haskell.org> References: <050.d6ff01fd86ce7c8b5a28dc0adb6995b9@haskell.org> Message-ID: <065.adba8eae8be6c98b4882912d686fb1f2@haskell.org> #14209: GHC 8.2.1 regression involving telescoping kind signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.2.1 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: #13738 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13738 Comment: Actually, it turns out that this typechecks once again on GHC HEAD due to commit 0257dacf228024d0cc6ba247c707130637a25580 (`Refactor bindHsQTyVars and friends`). I can certainly add a test case, but this makes me wonder: should we merge 0257dacf228024d0cc6ba247c707130637a25580 into GHC 8.2.2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 19:52:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 19:52:37 -0000 Subject: [GHC] #14209: GHC 8.2.1 regression involving telescoping kind signature In-Reply-To: <050.d6ff01fd86ce7c8b5a28dc0adb6995b9@haskell.org> References: <050.d6ff01fd86ce7c8b5a28dc0adb6995b9@haskell.org> Message-ID: <065.04810fd440f89061ffda47a50c22a8b1@haskell.org> #14209: GHC 8.2.1 regression involving telescoping kind signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.2.1 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: #13738 | Differential Rev(s): Phab:D3936 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3936 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 20:31:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 20:31:32 -0000 Subject: [GHC] #13910: Inlining a definition causes GHC to panic (repSplitTyConApp_maybe) In-Reply-To: <050.14bd55ba33332ff15d7c16c4f0c73fad@haskell.org> References: <050.14bd55ba33332ff15d7c16c4f0c73fad@haskell.org> Message-ID: <065.01144dfb3a2e07b318358f61e0e63b15@haskell.org> #13910: Inlining a definition causes GHC to panic (repSplitTyConApp_maybe) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: 14119 | Blocking: Related Tickets: #13877, #14038, | Differential Rev(s): #14175 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Simon and I met over lunch at ICFP on this one, and I think he solved the immediate problem here... but then ran into another gorilla behind this one. I wait with bated breath to see what shape that gorilla has! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 20:37:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 20:37:28 -0000 Subject: [GHC] #14119: Refactor type patterns In-Reply-To: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> References: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> Message-ID: <062.4e66a8275de2cfa04269a3f8e5dc3c27@haskell.org> #14119: Refactor type patterns -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12564, 13910, | 13938, 14038 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: (none) => goldfire Comment: After a chat at ICFP, Simon and I agreed that this was worthwhile, but in a very different way than originally proposed: create a new datatype `TypePat`, which would be a ''Core'' type pattern, used in, e.g., `FamInst`. Such a type would have no casts, no type families, and no foralls. Casts can be gotten rid of because the pure unifier (the client of type patterns) never uses them, unless they wrap a variable. And in that case, we can just use a variable with a new, corrected kind, and substitute the new one in for the old one (casting appropriately in the, e.g., type family equation's RHS). This transformation would happen after kind-checking and desugaring. Incidentally, it turns out that the underlying problem that this ticket was originally opened for was fixed by a small fix in the unifier. (The matching substitution must be applied to any cast found in the type pattern.) But that fix might not catch every possible case, while the proposal in this comment should. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 20:52:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 20:52:14 -0000 Subject: [GHC] #14198: Inconsistent treatment of implicitly bound kind variables as free-floating In-Reply-To: <050.fc7092bf8815668ee061af436c2c49de@haskell.org> References: <050.fc7092bf8815668ee061af436c2c49de@haskell.org> Message-ID: <065.437573c8daa9c74ea18ac249de75fbcf@haskell.org> #14198: Inconsistent treatment of implicitly bound kind variables as free-floating -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7873 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > (Spun off from the discussion starting at > https://phabricator.haskell.org/D3872#109927.) > > This program is accepted: > > {{{#!hs > {-# LANGUAGE ExistentialQuantification #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE RankNTypes #-} > > import Data.Proxy > > data Foo = MkFoo (forall a. Proxy a) > }}} > > There's something interesting going on here, however. Because `PolyKinds` > is enabled, the kind of `a` is generalized to `k`. But where does `k` get > quantified? It turns out that it's implicitly quantified as an > existential type variable to `MkFoo`: > > {{{ > λ> :i Foo > data Foo = forall k. MkFoo (forall (a :: k). Proxy a) > }}} > > This was brought up some time ago in #7873, where the conclusion was to > keep this behavior. But it's strange becuase the `k` is existential, so > the definition is probably unusable. > > But to make things stranger, it you write out the kind of `a` explicitly: > > {{{#!hs > {-# LANGUAGE ExistentialQuantification #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE RankNTypes #-} > > import Data.Proxy > > data Foo2 = MkFoo2 (forall (a :: k). Proxy a) > }}} > > Then GHC will reject it: > > {{{ > Bug.hs:7:1: error: > Kind variable ‘k’ is implicitly bound in data type > ‘Foo2’, but does not appear as the kind of any > of its type variables. Perhaps you meant > to bind it (with TypeInType) explicitly somewhere? > | > 7 | data Foo2 = MkFoo2 (forall (a :: k). Proxy a) > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > }}} > > So GHC's treatment is inconsistent. What should GHC do? We could: > > * Have both be an error. > * Have both be accepted, and implicitly quantify `k` as an existential > type variable > * Have both be accepted, and implicitly quantify `k` in the `forall` > itself. That is: > > {{{#!hs > MkFoo :: (forall {k} (a :: k). Proxy k a) -> Foo > }}} > * Something else. When you try a similar trick with type synonyms: > > {{{#!hs > {-# LANGUAGE ExistentialQuantification #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE RankNTypes #-} > > import Data.Proxy > > type Foo3 = forall a. Proxy a > }}} > > Instead of generalizing the kind of `a`, its kind will default to > `Any`: > > {{{ > λ> :i Foo3 > type Foo3 = forall (a :: GHC.Types.Any). Proxy a > }}} > > Would that be an appropriate trick for data types as well? New description: (Spun off from the discussion starting at https://phabricator.haskell.org/D3872#109927.) This program is accepted: {{{#!hs {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} import Data.Proxy data Foo = MkFoo (forall a. Proxy a) }}} There's something interesting going on here, however. Because `PolyKinds` is enabled, the kind of `a` is generalized to `k`. But where does `k` get quantified? It turns out that it's implicitly quantified as an existential type variable to `MkFoo`: {{{ λ> :i Foo data Foo = forall k. MkFoo (forall (a :: k). Proxy a) }}} This was brought up some time ago in #7873, where the conclusion was to keep this behavior. But it's strange becuase the `k` is existential, so the definition is probably unusable. But to make things stranger, it you write out the kind of `a` explicitly: {{{#!hs {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} import Data.Proxy data Foo2 = MkFoo2 (forall (a :: k). Proxy a) }}} Then GHC will reject it: {{{ Bug.hs:7:1: error: Kind variable ‘k’ is implicitly bound in data type ‘Foo2’, but does not appear as the kind of any of its type variables. Perhaps you meant to bind it (with TypeInType) explicitly somewhere? | 7 | data Foo2 = MkFoo2 (forall (a :: k). Proxy a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} So GHC's treatment is inconsistent. What should GHC do? We could: 1. Have both be an error. 2. Have both be accepted, and implicitly quantify `k` as an existential type variable 3. Have both be accepted, and implicitly quantify `k` in the `forall` itself. That is: {{{#!hs MkFoo :: (forall {k} (a :: k). Proxy k a) -> Foo }}} 4. Something else. When you try a similar trick with type synonyms: {{{#!hs {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} import Data.Proxy type Foo3 = forall a. Proxy a }}} Instead of generalizing the kind of `a`, its kind will default to `Any`: {{{ λ> :i Foo3 type Foo3 = forall (a :: GHC.Types.Any). Proxy a }}} Would that be an appropriate trick for data types as well? -- Comment (by goldfire): Nice description of the problem. I'll respond to your proposed solutions. 1. Yes. 2. No. H98 syntax should not be in the business of guessing existential variables. Existentials are a bit strange and should be strictly opt-in (at least for H98 syntax). 3. No. We stopped inferring kind quantification anywhere nested within a type with GHC 8. 4. We could do this, but I doubt it's what the user wants. Indeed, I think it would be an improvement to reject that type synonym, which is probably not what the user wants at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 21:04:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 21:04:39 -0000 Subject: [GHC] #14198: Inconsistent treatment of implicitly bound kind variables as free-floating In-Reply-To: <050.fc7092bf8815668ee061af436c2c49de@haskell.org> References: <050.fc7092bf8815668ee061af436c2c49de@haskell.org> Message-ID: <065.767e54a735e2861230e474c7ae699468@haskell.org> #14198: Inconsistent treatment of implicitly bound kind variables as free-floating -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7873 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Going with option 1 (have both be an error) sounds fine to me. But I'm not quite sure what the error message should be when we encounter an inferred, free-floating kind variable, as in `data Foo = MkFoo (forall a. Proxy a)`, where the `k` in `(a :: k)` is inferred. We could go with the usual `Kind variable ‘k’ is implicitly bound in data type` fare, but users might find that befuddling. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 21:07:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 21:07:59 -0000 Subject: [GHC] #14198: Inconsistent treatment of implicitly bound kind variables as free-floating In-Reply-To: <050.fc7092bf8815668ee061af436c2c49de@haskell.org> References: <050.fc7092bf8815668ee061af436c2c49de@haskell.org> Message-ID: <065.6e2244d0affbcfc8a5178e18e366052e@haskell.org> #14198: Inconsistent treatment of implicitly bound kind variables as free-floating -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7873 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think we actually have the opportunity for a good error message here. I ''think'' we'll know that the `k` is not user-written, because it will be `Inferred`, not `Specified`. So we can say that the variable was inferred instead of just calling it an inscrutable `k0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 21:24:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 21:24:22 -0000 Subject: [GHC] #14198: Inconsistent treatment of implicitly bound kind variables as free-floating In-Reply-To: <050.fc7092bf8815668ee061af436c2c49de@haskell.org> References: <050.fc7092bf8815668ee061af436c2c49de@haskell.org> Message-ID: <065.5f87c9dd2508b33b60d9268b86f306da@haskell.org> #14198: Inconsistent treatment of implicitly bound kind variables as free-floating -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7873 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:4 goldfire]: > I ''think'' we'll know that the `k` is not user-written, because it will be `Inferred`, not `Specified`. So you wish to perform free-floating checks on `TyConBinder`s instead of `TyVar`s? That might work... but wait. How would this work for data family instances? IIUC, they don't have anything like `TyConBinders`, so I'm not sure how we'd perform this check there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 9 21:48:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Sep 2017 21:48:14 -0000 Subject: [GHC] #14198: Inconsistent treatment of implicitly bound kind variables as free-floating In-Reply-To: <050.fc7092bf8815668ee061af436c2c49de@haskell.org> References: <050.fc7092bf8815668ee061af436c2c49de@haskell.org> Message-ID: <065.029b43bf23add24bbaca6e64959e4087@haskell.org> #14198: Inconsistent treatment of implicitly bound kind variables as free-floating -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7873 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): OK. Perhaps I'm just wrong. I didn't look at the code to compose comment:4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 10 01:47:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Sep 2017 01:47:48 -0000 Subject: [GHC] #14210: bkp files cannot find TemplateHaskell symbols (even without Backpack features) Message-ID: <045.6c75626be1ce2a19e09ffe03c68c7b92@haskell.org> #14210: bkp files cannot find TemplateHaskell symbols (even without Backpack features) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | 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: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE TemplateHaskell #-} unit th where module TH where f = [d| x = True |] unit p where dependency th module B where import TH $(f) }}} When run, this gives: {{{ ghc: ^^ Could not load 'th_TH_f_closure', dependency unresolved. See top entry above. ByteCodeLink.lookupCE During interactive linking, GHCi couldn't find the following symbol: th_TH_f_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs at haskell.org }}} I am not sure how easy or hard the fix is. We should bump this priority up if we get more serious about supporting Template Haskell with Backpack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 10 02:32:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Sep 2017 02:32:47 -0000 Subject: [GHC] #13268: Backpack doesn't work with Template Haskell, even when it should In-Reply-To: <045.cd14580b3e7c600311b01bfb065b9b08@haskell.org> References: <045.cd14580b3e7c600311b01bfb065b9b08@haskell.org> Message-ID: <060.292f9e1af960dd65d74ab671cfc0b936@haskell.org> #13268: Backpack doesn't work with Template Haskell, even when it should -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: invalid | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): For reference, Cabal bug was https://github.com/haskell/cabal/pull/4363 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 10 02:37:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Sep 2017 02:37:14 -0000 Subject: [GHC] #14211: Compiler is unable to INLINE as well as the programmer can manually Message-ID: <047.2a53ecf1e57ab8268d4f765d1da08a61@haskell.org> #14211: Compiler is unable to INLINE as well as the programmer can manually -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- The test case is in this repo on the `inlining-issue` branch: https://github.com/harendra-kumar/ghc-perf/tree/inlining-issue. Performance with manually inlining a function is more than 10% faster compared to factoring out code and using INLINE pragma. `stack bench` for compiler inlined code {{{ time 46.71 ms (45.53 ms .. 47.79 ms) }}} `stack bench --flag ghc-perf:manual` for manually inlined code {{{ time 39.46 ms (38.92 ms .. 39.94 ms) }}} Here is the relevant code: {{{#!hs {-# 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 -> let run x = (runAsyncT x) Nothing stp yld yield a _ Nothing = run $ f a yield a _ (Just r) = run $ f a `k` (bindWith k r f) in m Nothing stp yield instance Monad m => Monad (AsyncT m) where return a = AsyncT $ \ctx _ yld -> yld a ctx Nothing #ifdef MANUAL_INLINE AsyncT m >>= f = AsyncT $ \_ stp yld -> let run x = (runAsyncT x) Nothing stp yld yield a _ Nothing = run $ f a yield a _ (Just r) = run $ f a <> (r >>= f) in m Nothing stp yield #else (>>=) = bindWith (<>) #endif }}} I have seen this many times. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 10 02:38:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Sep 2017 02:38:38 -0000 Subject: [GHC] #14212: Give better error message with non-supported Backpack/TH use Message-ID: <045.2a0dc1102cfe2e4dcff362b3e8c0f2df@haskell.org> #14212: Give better error message with non-supported Backpack/TH use -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.2.1 Haskell | 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: -------------------------------------+------------------------------------- This is something of a follow up to #13268. Suppose you have an indefinite package. If you use TemplateHaskell with a splice that was defined in the indefinite package itself, there is no reasonable way to expect this to work, since in general you can't have compiled the the imported module before you need to run the splice (and the splice needs to be run before you know how the holes are instantiated.) But say you try and do it anyway. GHC will give an error like this: {{{ ghc: ^^ Could not load 'qzm0zi1zminplacezmENEL5G3hx7IK2t0f6HloyH_A_f_closure', dependency unresolved. See top entry above. ByteCodeLink.lookupCE During interactive linking, GHCi couldn't find the following symbol: qzm0zi1zminplacezmENEL5G3hx7IK2t0f6HloyH_A_f_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs at haskell.org }}} This is not a good error message. A good error message would be to say that you can't use in a splice a function defined in an indefinite package (as per the current library.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 10 07:39:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Sep 2017 07:39:59 -0000 Subject: [GHC] #13115: missing data instances for IntPtr and WordPtr in base In-Reply-To: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> References: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> Message-ID: <060.fb1618a9e6b97324a14b43e6d4dd2779@haskell.org> #13115: missing data instances for IntPtr and WordPtr in base -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): Replying to [comment:3 RyanGlScott]: > Ah, OK. Thanks for clarifying! > > I don't think this would be too hard to accomplish, if someone wants to volunteer a patch. Hi, I am a newcomer to ghc-devs mailing list and I volunteer to fix this issue. Since base-4.10.0.0, the `IntPtr` and `WordPtr` are defined using `newtype` rather than `data` (as in base-4.9.1.0), is it enough for this issue that putting the following instance declarations to `Data.Data` module (with `GeneralizedNewtypeDeriving` enabled) ? {{{#!haskell deriving instance Data IntPtr deriving instance Data WordPtr }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 10 10:25:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Sep 2017 10:25:33 -0000 Subject: [GHC] #14211: Compiler is unable to INLINE as well as the programmer can manually In-Reply-To: <047.2a53ecf1e57ab8268d4f765d1da08a61@haskell.org> References: <047.2a53ecf1e57ab8268d4f765d1da08a61@haskell.org> Message-ID: <062.04a5e459eeb2e32aece40f2c4477dbe8@haskell.org> #14211: Compiler is unable to INLINE as well as the programmer can manually -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | StaticArgumentTransformation, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => StaticArgumentTransformation, Inlining Comment: `bindWith` is a self-recursive function so GHC won't inline it by itself. If you rewrite `bindWith` to {{{ bindWith :: (forall c. AsyncT m c -> AsyncT m c -> AsyncT m c) -> AsyncT m a -> (a -> AsyncT m b) -> AsyncT m b bindWith k m f = go m where go (AsyncT m) = AsyncT $ \_ stp yld -> let run x = (runAsyncT x) Nothing stp yld yield a _ Nothing = run $ f a yield a _ (Just r) = run $ f a `k` (go r) in m Nothing stp yield }}} so it delegates the recursion to the `go` function then it seems like the performance is the same. This is the transformation the static argument transformation is meant to achieve (turned on by `-fstatic-argument-transformation`). It didn't seem to work just by turning on this flag but I don't have time to investigate more now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 10 10:38:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Sep 2017 10:38:11 -0000 Subject: [GHC] #12025: Order of constraints forced (in pattern synonyms, type classes in comments) In-Reply-To: <051.f7825cd1538f4e1bd703526f61b3a749@haskell.org> References: <051.f7825cd1538f4e1bd703526f61b3a749@haskell.org> Message-ID: <066.d548fb2f474c15bad4910c3893410903@haskell.org> #12025: Order of constraints forced (in pattern synonyms, type classes in comments) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 11513, 10928 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think the pattern synonym problem is covered by [https://github.com/ghc- proposals/ghc-proposals/pull/42 this ghc-proposal] and that the GADT problem is covered by #11721. If that's the case, this ticket is redundant. Please close if you agree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 10 10:47:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Sep 2017 10:47:17 -0000 Subject: [GHC] #11721: GADT-syntax data constructors don't work well with TypeApplications In-Reply-To: <047.d3cda57aa918919c3cdf02eb21c0a581@haskell.org> References: <047.d3cda57aa918919c3cdf02eb21c0a581@haskell.org> Message-ID: <062.cca8c6e7dc7da450e5fbf5fa70c9b6b8@haskell.org> #11721: GADT-syntax data constructors don't work well with TypeApplications -------------------------------------+------------------------------------- Reporter: goldfire | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13848 | 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 Sun Sep 10 10:52:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Sep 2017 10:52:07 -0000 Subject: [GHC] #12025: Order of constraints forced (in pattern synonyms, type classes in comments) In-Reply-To: <051.f7825cd1538f4e1bd703526f61b3a749@haskell.org> References: <051.f7825cd1538f4e1bd703526f61b3a749@haskell.org> Message-ID: <066.4f033402735a4e3c2ee88877788300a6@haskell.org> #12025: Order of constraints forced (in pattern synonyms, type classes in comments) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: duplicate | TypeApplications PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 11513, 10928 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * status: new => closed * resolution: => duplicate Comment: Yes good -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 10 10:54:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Sep 2017 10:54:06 -0000 Subject: [GHC] #11721: GADT-syntax data constructors don't work well with TypeApplications In-Reply-To: <047.d3cda57aa918919c3cdf02eb21c0a581@haskell.org> References: <047.d3cda57aa918919c3cdf02eb21c0a581@haskell.org> Message-ID: <062.64f2d4b3097e9f817771cc5f5aa820c8@haskell.org> #11721: GADT-syntax data constructors don't work well with TypeApplications -------------------------------------+------------------------------------- Reporter: goldfire | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13848, #12025 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * related: #13848 => #13848, #12025 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 10 13:57:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Sep 2017 13:57:15 -0000 Subject: [GHC] #13115: missing data instances for IntPtr and WordPtr in base In-Reply-To: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> References: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> Message-ID: <060.23209c31506d9c4b4c8cf8278840ef27@haskell.org> #13115: missing data instances for IntPtr and WordPtr in base -------------------------------------+------------------------------------- Reporter: carter | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: (none) => sighingnow Comment: Replying to [comment:4 sighingnow]: > Hi, I am a newcomer to ghc-devs mailing list and I volunteer to fix this issue. Wonderful! > Since base-4.10.0.0, the `IntPtr` and `WordPtr` are defined using `newtype` rather than `data` (as in base-4.9.1.0), is it enough for this issue that putting the following instance declarations to `Data.Data` module (with `GeneralizedNewtypeDeriving` enabled) ? > > {{{#!haskell > deriving instance Data IntPtr > > deriving instance Data WordPtr > }}} Yes, I think that would work quite nicely. Feel free to ask any more questions here if they arise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 10 14:07:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Sep 2017 14:07:37 -0000 Subject: [GHC] #13115: missing data instances for IntPtr and WordPtr in base In-Reply-To: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> References: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> Message-ID: <060.c06c4265a80f591902e0d7632d6a326e@haskell.org> #13115: missing data instances for IntPtr and WordPtr in base -------------------------------------+------------------------------------- Reporter: carter | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I actually don't know that you need `GeneralizedNewtypeDeriving` here. The usual `DeriveDataTypeable` should do just fine I believe. Otherwise, yes. It looks like you have the right idea. Do make sure to add `@since` annotations in the Haddock documentation for the new instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 10 14:13:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Sep 2017 14:13:39 -0000 Subject: [GHC] #13738: TypeApplications-related GHC internal error In-Reply-To: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> References: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> Message-ID: <065.a055ef8869ab7da6770d0033d31bf8f1@haskell.org> #13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | polykinds/T13738 Blocked By: | Blocking: Related Tickets: #13985 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ryan encountered a related regression in 8.2.1, reported as #14209. Perhaps comment:17 should be merged. Unfortunately it's not a terribly small patch. What do you think, Simon? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 10 14:16:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Sep 2017 14:16:40 -0000 Subject: [GHC] #14213: Improve the documentation of seq function Message-ID: <043.053aa1ee2284ef7ad3446d36b517c5b3@haskell.org> #14213: Improve the documentation of seq function -------------------------------------+------------------------------------- Reporter: sibi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While the current documentation is fine, I think it would be better if it was mentioned explicitly that the first argument would be evaluated to `WHNF`. For a while, I was confused if it gets reduced to WHNF or NF. I can volunteer to send the patch if there is no objection to this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 10 14:20:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Sep 2017 14:20:55 -0000 Subject: [GHC] #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs In-Reply-To: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> References: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> Message-ID: <057.820feb997afcb742afd3ae4fbf4f0cc5@haskell.org> #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: gdb, | debugging Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It sounds like maybe we should be setting `MADV_DONTDUMP` where available (and later revert it with `MADV_DODUMP`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 10 14:23:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Sep 2017 14:23:40 -0000 Subject: [GHC] #14213: Improve the documentation of seq function In-Reply-To: <043.053aa1ee2284ef7ad3446d36b517c5b3@haskell.org> References: <043.053aa1ee2284ef7ad3446d36b517c5b3@haskell.org> Message-ID: <058.c39dbb5d1e0f5d3d2946ff9481c5d4f9@haskell.org> #14213: Improve the documentation of seq function -------------------------------------+------------------------------------- Reporter: sibi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [ticket:14213 sibi]: > I can volunteer to send the patch if there is no objection to this. Go for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 10 14:26:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Sep 2017 14:26:42 -0000 Subject: [GHC] #13115: missing data instances for IntPtr and WordPtr in base In-Reply-To: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> References: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> Message-ID: <060.6d7c54d1e8a60ffac35e153afe75a314@haskell.org> #13115: missing data instances for IntPtr and WordPtr in base -------------------------------------+------------------------------------- Reporter: carter | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): Thanks for your help. I have push a diff here Phab:D3938 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 10 14:28:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Sep 2017 14:28:25 -0000 Subject: [GHC] #13115: missing data instances for IntPtr and WordPtr in base In-Reply-To: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> References: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> Message-ID: <060.22b5d92a09c0d44b2e71436a5f3a4edb@haskell.org> #13115: missing data instances for IntPtr and WordPtr in base -------------------------------------+------------------------------------- Reporter: carter | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3938 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * differential: => Phab:D3938 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 10 14:33:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Sep 2017 14:33:25 -0000 Subject: [GHC] #13115: missing data instances for IntPtr and WordPtr in base In-Reply-To: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> References: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> Message-ID: <060.fec5a0165be4d6ed85250c52aefd7a69@haskell.org> #13115: missing data instances for IntPtr and WordPtr in base -------------------------------------+------------------------------------- Reporter: carter | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3938 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): Could anyone help me with the build failure of Phab:D3938 ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 10 14:34:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Sep 2017 14:34:49 -0000 Subject: [GHC] #13115: missing data instances for IntPtr and WordPtr in base In-Reply-To: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> References: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> Message-ID: <060.694c6ab487e9711ef79ef5a4b9337da8@haskell.org> #13115: missing data instances for IntPtr and WordPtr in base -------------------------------------+------------------------------------- Reporter: carter | Owner: sighingnow Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3938 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 10 17:25:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Sep 2017 17:25:53 -0000 Subject: [GHC] #14211: Compiler is unable to INLINE as well as the programmer can manually In-Reply-To: <047.2a53ecf1e57ab8268d4f765d1da08a61@haskell.org> References: <047.2a53ecf1e57ab8268d4f765d1da08a61@haskell.org> Message-ID: <062.63a70f00d37a316d8cdccb67cd4db098@haskell.org> #14211: Compiler is unable to INLINE as well as the programmer can manually -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | StaticArgumentTransformation, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): That information is a gem for optimization! I need to change how I code recursive functions. Every programmer must know that a static argument impacts performance significantly and can be easily optimized. It not only recovered the lost performance but gave a lot more because the manually inlined bind function also has a static argument which got removed in this version. I think the problem is not really inlining. GHC won't be able to inline the recursive call of a function to itself, of course, but it can still inline the whole function. So `bindWith` is likely getting inlined, I can see that with `-ddump-inlinings`. I guess, the problem is that we have added one more static argument which degrades the performance. The compiler is able to inline the function but it cannot undo that static argument. I see that the INLINE section in the GHC manual mentions mutually recursive and recursive functions, however it does not mention `-fstatic- argument-transformation`. It may be useful to mention because the programmer naively expects that inlining will give us equivalent code but in reality the added static argument is an overhead that cannot be reverted by the compiler. I have a few questions, suggestions: 1) The INLINE section of the manual should mention `-fstatic-argument- transformation` and how factoring out of code can add a static argument that cannot be undone by the compiler unless we use this option. Also, an example of how the programmer can manually perform static argument transformation and achieve what (s)he wants in case this option does not work. 2) Can we have a warning option which warns the programmer about missed inlining? If I have placed an INLINE pragma and the compiler is unable to inline the function for whatever reason I want to know. The `-ddump- inlinings` shows what got inlined but what did not get inlined will be more useful information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 10 23:31:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Sep 2017 23:31:44 -0000 Subject: [GHC] #14186: CSE fails to CSE two identical large top-level functions In-Reply-To: <046.69825e5d45135d4ed01bf5ccfdf86282@haskell.org> References: <046.69825e5d45135d4ed01bf5ccfdf86282@haskell.org> Message-ID: <061.be3d8a69796485af8b3111161f9eb413@haskell.org> #14186: CSE fails to CSE two identical large top-level functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3939 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D3939 Comment: Phab:D3939 has a flight train result. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 02:21:29 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 02:21:29 -0000 Subject: [GHC] #13870: Empty record construction for record-less constructor gives surprising runtime error (and surprisingly few warnings) In-Reply-To: <050.fc98e01b762a6c8eb62abc4b92b4d47b@haskell.org> References: <050.fc98e01b762a6c8eb62abc4b92b4d47b@haskell.org> Message-ID: <065.8e3855e1480b6a57ddab2a4a40bd0919@haskell.org> #13870: Empty record construction for record-less constructor gives surprising runtime error (and surprisingly few warnings) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer 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:D3940 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * owner: (none) => sighingnow * differential: => Phab:D3940 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 02:22:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 02:22:57 -0000 Subject: [GHC] #13870: Empty record construction for record-less constructor gives surprising runtime error (and surprisingly few warnings) In-Reply-To: <050.fc98e01b762a6c8eb62abc4b92b4d47b@haskell.org> References: <050.fc98e01b762a6c8eb62abc4b92b4d47b@haskell.org> Message-ID: <065.abc7f97b5e865bacbaace766b67f07f1@haskell.org> #13870: Empty record construction for record-less constructor gives surprising runtime error (and surprisingly few warnings) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | deSugar/should_compile/T13870 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3940 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * testcase: => deSugar/should_compile/T13870 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 02:44:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 02:44:13 -0000 Subject: [GHC] #14208: Performance with -O2 is worse than with -O0 which is worse than runghc In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.e28cc6207b2d78a35743ad7255a9a7b4@haskell.org> #14208: Performance with -O2 is worse than with -O0 which is worse than runghc -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): Earlier I thought the problem occurs with `-O2` but that is not the case, `-O2` is irrelevant. `-O2` gives the same performance as the default i.e. without any optimization flags. The difference is between `-O0` and the absence of it. Adding `-O0` improves performance drastically. I have updated the github repo and removed `-O2`. This is such an ironic case, `runghc` has the best performance, the next best is `-O0` and any optimization is the worst! Maybe we should just reverse the flags :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 02:48:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 02:48:14 -0000 Subject: [GHC] #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best (was: Performance with -O2 is worse than with -O0 which is worse than runghc) In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.28ba0e671c812cefb5d725e24aa3eaba@haskell.org> #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by harendra: Old description: > In this particular case `-O2` is 2x slower than `-O0` and `-O0` is 2x > slower than `runghc`. Please see the github repo: https://github.com > /harendra-kumar/ghc-perf to reproduce the issue. Readme file in the repo > has instructions to reproduce. > > The issue seems to occur when the code is placed in a different module. > When all the code is in the same module the problem does not occur. In > that case `-O2` is faster than `-O0`. However, when the code is split > into two modules the performance gets inverted. > > Also, it does not occur always, when I tried to change the code to make > it simpler for repro the problem did not occur. New description: In this particular case `-O2` or the default is 2x slower than `-O0` and `-O0` is 2x slower than `runghc`. Please see the github repo: https://github.com/harendra-kumar/ghc-perf to reproduce the issue. Readme file in the repo has instructions to reproduce. The issue seems to occur when the code is placed in a different module. When all the code is in the same module the problem does not occur. In that case `-O2` or the default is faster than `-O0`. However, when the code is split into two modules the performance gets inverted. Also, it does not occur always, when I tried to change the code to make it simpler for repro the problem did not occur. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 03:23:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 03:23:23 -0000 Subject: [GHC] #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.d8306085e4e3e95ff53e24571d22a5ba@haskell.org> #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): It was hard to find in the manual the difference between O0 and the default. The manual says "O0 is the default", which seems to be incorrect (NEED TO BE FIXED). So I had to turn to the GHC code. Alright, so O0 seems to ignore or omit "interface-pragmas" whatever the heck they are, from DynFlags.hs: {{{#!hs , ([0], Opt_IgnoreInterfacePragmas) , ([0], Opt_OmitInterfacePragmas) }}} When I used "-fignore-interface-pragmas" I got the same improvement in performance. The GHC manual documents this flag but says nothing about what this really means (NEED TO BE FIXED). I can only guess. Since this has to do something with the interface, this also explains why the performance is good when the whole code is in the same module and bad when the code is split into two modules. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 05:22:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 05:22:16 -0000 Subject: [GHC] #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.ec954401994f3b97050e5a419d8a03b8@haskell.org> #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): Alright, I guessed that ignoring the interface disables inlining so the problem has something to do with inlining. I looked at all the inlining options available and narrowed down the problem to `-fno-pre-inlining`. Just using `-fno-pre-inlining` brings us back to the performance that we are seeing with -O0. The fine manual does not say what pre-inlining is so I have to look at the GHC code again. I am confused by the fine manual. It says: {{{ -fno-pre-inlining Default: off }}} Does that mean pre-inlining is on by default? Can we make this clearer, explicit? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 06:22:18 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 06:22:18 -0000 Subject: [GHC] #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.12b9f588d92868eb402d40d9fafaecfc@haskell.org> #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harendra): * cc: simonpj (added) Comment: The pre-inlining flag maps to `pre_inline_unconditionally` in `SimplUtils.hs`. Ccing SPJ who seems to have touched it last via commit 33452dfc6cf. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 06:30:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 06:30:59 -0000 Subject: [GHC] #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.bd19dee4b268d3d3877e1943ad84edd4@haskell.org> #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): I can confirm that this problem does not manifest in GHC 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 07:22:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 07:22:44 -0000 Subject: [GHC] #14196: Replace ArrayArray# with either UnliftedArray# or Array# In-Reply-To: <049.e6e8e74aa5747261fafcac4ff3c72b33@haskell.org> References: <049.e6e8e74aa5747261fafcac4ff3c72b33@haskell.org> Message-ID: <064.51be47912a873cd446e3ce2545208ebb@haskell.org> #14196: Replace ArrayArray# with either UnliftedArray# or Array# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * cc: akio (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 07:22:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 07:22:50 -0000 Subject: [GHC] #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.f62647f9be397e781abf1a70c016698c@haskell.org> #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): I measured runghc vs ghc performance for this test case on 7.10.3, 8.0.2 and 8.2.1. It seems runghc has always been faster, though the difference was not much in 7.10.3, runghc seems to have improved a lot in 8.0 performing better than ghc. {{{ 7.10.3 ghc : time 11.43 ms (11.05 ms .. 11.75 ms) 7.10.3 runghc : time 10.55 ms (9.461 ms .. 11.46 ms) 8.0.2 ghc : time 11.00 ms (10.64 ms .. 11.38 ms) 8.0.2 runghc : time 6.441 ms (6.025 ms .. 6.790 ms) 8.2.1 ghc (O0) : time 8.986 ms (8.728 ms .. 9.313 ms) 8.2.1 runghc : time 4.598 ms (4.350 ms .. 4.890 ms) }}} It will be awesome if ghc can be as good as runghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 07:57:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 07:57:43 -0000 Subject: [GHC] #14193: Add RTS flag to disable 1TB address space allocation In-Reply-To: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> References: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> Message-ID: <057.339f8d60537595a8c28f350c67d9b826@haskell.org> #14193: Add RTS flag to disable 1TB address space allocation -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: feature request | 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: #9706, #14192 | Differential Rev(s): Phab:D3929 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): We didn't measure the effect of making it runtime-selectable. You're welcome to try measuring it, but my concern is that it's likely to be around 1% overall, and that's at the level where we care, but it's difficult to measure accurately given the benchmarks and tools we have. nofib almost certainly won't be able to measure it, because most of the programs in there don't do much GC. You can try nofib/parallel, but those tend to be a bit noisy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 07:58:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 07:58:14 -0000 Subject: [GHC] #14193: Add RTS flag to disable 1TB address space allocation In-Reply-To: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> References: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> Message-ID: <057.c5406f8924706c00e48a1fefc83cb492@haskell.org> #14193: Add RTS flag to disable 1TB address space allocation -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: feature request | 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: #9706, #14192 | Differential Rev(s): Phab:D3929 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Or there's nofib/gc of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 09:13:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 09:13:14 -0000 Subject: [GHC] #13738: TypeApplications-related GHC internal error In-Reply-To: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> References: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> Message-ID: <065.603daec4bec89c91712ce9e903bd26b6@haskell.org> #13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | polykinds/T13738 Blocked By: | Blocking: Related Tickets: #13985 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Hmm. * I think that there's an easy source-code workaround for #14209 (correct?), so fixing it isn't that urgent. Leaving 8.2 alone won't block anyone's progress. * While I doubt the patch will break anything, it is a non-local change so I'm not 100% confident of that claim. So I'd be inclined to merge it only if we can do a solid smoke-test against all of Hackage/Stackage to confirm the "no-break" claim. In the future that'll be easy to do; I'm not sure how hard it is today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 09:13:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 09:13:35 -0000 Subject: [GHC] #14213: Improve the documentation of seq function In-Reply-To: <043.053aa1ee2284ef7ad3446d36b517c5b3@haskell.org> References: <043.053aa1ee2284ef7ad3446d36b517c5b3@haskell.org> Message-ID: <058.dd78a4056146cf6b0ace38e05d1f52e8@haskell.org> #14213: Improve the documentation of seq function -------------------------------------+------------------------------------- Reporter: sibi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes please! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 09:49:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 09:49:06 -0000 Subject: [GHC] #14206: Add bit deposit and bit extraction primops In-Reply-To: <047.2543734720307265ea1bddd575e5fddb@haskell.org> References: <047.2543734720307265ea1bddd575e5fddb@haskell.org> Message-ID: <062.5c32549acd3f44cb0c17b8db86f926b9@haskell.org> #14206: Add bit deposit and bit extraction primops -------------------------------------+------------------------------------- Reporter: newhoggy | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Sounds useful to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 12:49:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 12:49:25 -0000 Subject: [GHC] #12822: Cleanup GHC verbosity flags In-Reply-To: <045.4d9fca09f9ab247dee7b220b1a06e9a9@haskell.org> References: <045.4d9fca09f9ab247dee7b220b1a06e9a9@haskell.org> Message-ID: <060.75b740021ca54fca9b7359814818cc6e@haskell.org> #12822: Cleanup GHC verbosity flags -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | newcomer,flags 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 captaintrunky): I'd like to work on this ticket. Regarding 2), is it enough just to rename corresponding flags or it could be better to add a new type, e.g. 'data ReportFlag'? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 13:14:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 13:14:11 -0000 Subject: [GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> References: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> Message-ID: <059.c3d0ff59bc63bddee6d3d8ebf8f635f7@haskell.org> #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 (Linker) | 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 bgamari): I tried bisecting this; unfortunately it seems the bisection went off-the rails at some point. Here is the (presumably incorrect, somewhere) log, {{{ git bisect start # good: [54ccf0c957a279c20e1a37a5a462612af8036739] remove dead function 'tcInstBinders' git bisect good 54ccf0c957a279c20e1a37a5a462612af8036739 # bad: [d08b9ccdf2812e8f8fa34d0c89275deee574524c] configure: Ensure that user's LD setting is respected git bisect bad d08b9ccdf2812e8f8fa34d0c89275deee574524c # bad: [927e7810f7dcea295c1f8e93535835e52da0edbb] typo: -XUndeci[d]ableInstances git bisect bad 927e7810f7dcea295c1f8e93535835e52da0edbb # bad: [905dc8bc74bebf5370eb9237cc8756cd9fe871ae] Make ':info Coercible' display an arbitrary string (fixes #12390) git bisect bad 905dc8bc74bebf5370eb9237cc8756cd9fe871ae # bad: [8f8d756c5a29217ff79154caa1696b6e572d186f] rts: Fix uninitialised variable uses git bisect bad 8f8d756c5a29217ff79154caa1696b6e572d186f # bad: [1ef4156e45dcb258f6ef05cfb909547b8e3beb0f] Prevent ApplicativeDo from applying to strict pattern matches (#13875) git bisect bad 1ef4156e45dcb258f6ef05cfb909547b8e3beb0f # bad: [7de2c07d61d8ff952164ee8e6948c1415514ee6d] users-guide: Document FFI safety guarantees git bisect bad 7de2c07d61d8ff952164ee8e6948c1415514ee6d # bad: [58c781da4861faab11e4c5804e07e6892908ef72] Revert "Remove the Windows GCC driver." git bisect bad 58c781da4861faab11e4c5804e07e6892908ef72 # bad: [3b0e7555fafe73b157a96ca48d8ddc04ad81b231] Fix lexically-scoped type variables git bisect bad 3b0e7555fafe73b157a96ca48d8ddc04ad81b231 # first bad commit: [3b0e7555fafe73b157a96ca48d8ddc04ad81b231] Fix lexically-scoped type variables }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 13:18:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 13:18:21 -0000 Subject: [GHC] #14199: Document Type.Reflection better (Fun and Con') In-Reply-To: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> References: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> Message-ID: <060.c54e49a72383a7933714c763c4ea04d4@haskell.org> #14199: Document Type.Reflection better (Fun and Con') -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 13:24:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 13:24:53 -0000 Subject: [GHC] #13738: TypeApplications-related GHC internal error In-Reply-To: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> References: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> Message-ID: <065.5c2aba42b0e1da62202cf3f50800b461@haskell.org> #13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | polykinds/T13738 Blocked By: | Blocking: Related Tickets: #13985 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): FWIW, I didn't notice #14209 in a package in the wild, only when stress- testing different ways of implicitly binding kind variables. And indeed, it doesn have a workaround. Instead of writing this: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeInType #-} module Bug where data MyProxy k (a :: k) = MyProxy data Foo (z :: MyProxy k (a :: k)) }}} You can write this: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeInType #-} module Bug where data MyProxy k (a :: k) = MyProxy data Foo (z :: MyProxy k a) }}} So I would be OK with not merging that patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 13:37:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 13:37:00 -0000 Subject: [GHC] #14199: Document Type.Reflection better (Fun and Con') In-Reply-To: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> References: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> Message-ID: <060.f0a3e53722cca24becfd4517b9bb535d@haskell.org> #14199: Document Type.Reflection better (Fun and Con') -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.2.2 Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3943 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3943 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 14:22:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 14:22:33 -0000 Subject: [GHC] #13738: TypeApplications-related GHC internal error In-Reply-To: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> References: <050.6d0747c7f7522a728d8f6e2eba2d84d5@haskell.org> Message-ID: <065.e80f1e0cadc54b48414d4cc8ffaba546@haskell.org> #13738: TypeApplications-related GHC internal error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | polykinds/T13738 Blocked By: | Blocking: Related Tickets: #13985 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.4.1 Comment: Let's not merge in that case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 14:23:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 14:23:48 -0000 Subject: [GHC] #14209: GHC 8.2.1 regression involving telescoping kind signature In-Reply-To: <050.d6ff01fd86ce7c8b5a28dc0adb6995b9@haskell.org> References: <050.d6ff01fd86ce7c8b5a28dc0adb6995b9@haskell.org> Message-ID: <065.afa8643d6ed85ad0e96799524004fcd8@haskell.org> #14209: GHC 8.2.1 regression involving telescoping kind signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 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: #13738 | Differential Rev(s): Phab:D3936 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.2 => 8.4.1 Comment: As discussed in ticket:13738#comment:20 we won't be merging the patch for 8.2.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 14:24:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 14:24:49 -0000 Subject: [GHC] #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.e4c7b9dc3eadcc995b30563b4e814be6@haskell.org> #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Interesting. From what you write, my guess would be that when all functions are inlined (e.g., everything is placed in the same module) or when none get inlined, performance is good, but some combination of inlined and not inlined functions causes the slowdown (such things do happen and they are impossible to avoid). If I was to try and minimize this example, I'd put everything in the same module and then explore all combinations of INLINE and NOINLINE pragmas on functions. BTW, does the slowdown vanish if you enable -fexpose-all-unfoldings (and -fspecialise- aggressively for a good measure)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 14:28:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 14:28:00 -0000 Subject: [GHC] #14214: Users guide lies about default optimization level Message-ID: <046.736805dbdfc6944b76008d4f99ba283f@haskell.org> #14214: Users guide lies about default optimization level -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- #14208 points out that the users guide claims that the default optimization level is `-O0`. However this apparently isn't true. We should decide whether this should be the default and, if so, identify and fix the differences. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 14:29:29 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 14:29:29 -0000 Subject: [GHC] #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.2852569af69c687b81b4f2b6308dfb4e@haskell.org> #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > It was hard to find in the manual the difference between `O0` and the default. The manual says "`O0` is the default", which seems to be incorrect (NEED TO BE FIXED). I've opened #14214 to track this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 14:30:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 14:30:24 -0000 Subject: [GHC] #14214: Users guide lies about default optimization level In-Reply-To: <046.736805dbdfc6944b76008d4f99ba283f@haskell.org> References: <046.736805dbdfc6944b76008d4f99ba283f@haskell.org> Message-ID: <061.857bbb85f3e60575627e818691952b38@haskell.org> #14214: Users guide lies about default optimization level -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > #14208 points out that the users guide claims that the default > optimization level is `-O0`. However this apparently isn't true. We > should decide whether this should be the default and, if so, identify and > fix the differences. New description: ticket:14208#comment:5 points out that the users guide claims that the default optimization level is `-O0`. However this apparently isn't true. We should decide whether this should be the default and, if so, identify and fix the differences. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 14:39:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 14:39:08 -0000 Subject: [GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> References: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> Message-ID: <059.d2742f013dc32a48234114918a34b169@haskell.org> #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 (Linker) | 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 bgamari): Simon says that this should in principle be covered by the `extinterp` testsuite way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 14:48:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 14:48:37 -0000 Subject: [GHC] #14215: Coordinate re Cabal-2.0.0.3 or Cabal-2.0.1 release Message-ID: <042.f2da5496c03c753cd8a87d1fc1022cfc@haskell.org> #14215: Coordinate re Cabal-2.0.0.3 or Cabal-2.0.1 release -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.2.2 Component: libraries | Version: 8.2.1 (other) | 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 Sep 11 14:48:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 14:48:59 -0000 Subject: [GHC] #14215: Coordinate re Cabal-2.0.0.3 or Cabal-2.0.1 release In-Reply-To: <042.f2da5496c03c753cd8a87d1fc1022cfc@haskell.org> References: <042.f2da5496c03c753cd8a87d1fc1022cfc@haskell.org> Message-ID: <057.c31a277c9f554de549bd66386bc30c32@haskell.org> #14215: Coordinate re Cabal-2.0.0.3 or Cabal-2.0.1 release -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: task | Status: upstream Priority: high | Milestone: 8.2.2 Component: libraries | Version: 8.2.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => upstream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 15:13:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 15:13:32 -0000 Subject: [GHC] #14213: Improve the documentation of seq function In-Reply-To: <043.053aa1ee2284ef7ad3446d36b517c5b3@haskell.org> References: <043.053aa1ee2284ef7ad3446d36b517c5b3@haskell.org> Message-ID: <058.981e236d2b3434c0e050036ab8502c63@haskell.org> #14213: Improve the documentation of seq function -------------------------------------+------------------------------------- Reporter: sibi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | 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 sibi): * status: new => patch Comment: https://phabricator.haskell.org/D3945 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 15:18:18 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 15:18:18 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.98498a99cec359be7924419ece850ecb@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9630 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => dfeuer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 15:19:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 15:19:07 -0000 Subject: [GHC] #12437: 20% regression in max_bytes_used for T1969 In-Reply-To: <047.090b2624111211cac9a272929b897b02@haskell.org> References: <047.090b2624111211cac9a272929b897b02@haskell.org> Message-ID: <062.c5bb46fa9eca77c844dc87fa7877d678@haskell.org> #12437: 20% regression in max_bytes_used for T1969 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: dfeuer Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: osa1 => dfeuer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 15:22:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 15:22:55 -0000 Subject: [GHC] #8583: Associated pattern synonyms In-Reply-To: <045.39184734af9bc44765e305261b59a6ed@haskell.org> References: <045.39184734af9bc44765e305261b59a6ed@haskell.org> Message-ID: <060.d9d820899efe52be22ab4a3436682186@haskell.org> #8583: Associated pattern synonyms -------------------------------------+------------------------------------- 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: 5144 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Quick reminder: I need this to work with GND. Using an `Int` instance of the above class {{{#!hs deriving instance HasZero Int }}} I want to be able to derive (`newtype`, not `anyclass`) {{{#!hs newtype USD = USD Int deriving newtype HasZero -- instance HasZero USD where -- pattern Zero :: USD -- pattern Zero <- (coerce -> Zero::Int) -- where Zero = coerce (Zero::Int) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 15:25:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 15:25:01 -0000 Subject: [GHC] #14216: Compare compiler performance of GHC 8.0.2 and 8.2.1 on Stackage Message-ID: <046.4d0ed9d9543dbb5060c848799f060d2d@haskell.org> #14216: Compare compiler performance of GHC 8.0.2 and 8.2.1 on Stackage -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Simon M. suggests that we take a sample of Stackage packages (perhaps the top 200 by Hackage download count) and compare their compiler performance statistics with GHC 8.0.2 and 8.2.1. We'll want to collect overall GHC wall clock time, as well as the per-pass metrics produced by `-v`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 15:25:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 15:25:42 -0000 Subject: [GHC] #14216: Compare compiler performance of GHC 8.0.2 and 8.2.1 on Stackage In-Reply-To: <046.4d0ed9d9543dbb5060c848799f060d2d@haskell.org> References: <046.4d0ed9d9543dbb5060c848799f060d2d@haskell.org> Message-ID: <061.1d9733f53a2ed4fa305c33939f7287a2@haskell.org> #14216: Compare compiler performance of GHC 8.0.2 and 8.2.1 on Stackage -------------------------------------+------------------------------------- Reporter: bgamari | Owner: dfeuer Type: task | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => dfeuer Comment: I'll try to get a dump of download counts from Hackage so David can run the experiment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 17:54:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 17:54:04 -0000 Subject: [GHC] #12178: Allow inline pragmas on pattern synonyms In-Reply-To: <049.c0b5177720c745c7c76b88f1c76a960e@haskell.org> References: <049.c0b5177720c745c7c76b88f1c76a960e@haskell.org> Message-ID: <064.4a96aca4d6998801fa8cb797281719c3@haskell.org> #12178: Allow inline pragmas on pattern synonyms -------------------------------------+------------------------------------- Reporter: mpickering | Owner: osa1 Type: feature request | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * owner: (none) => osa1 Comment: I have some time to work on GHC these days and I'll be working on this feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 18:50:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 18:50:02 -0000 Subject: [GHC] #14213: Improve the documentation of seq function In-Reply-To: <043.053aa1ee2284ef7ad3446d36b517c5b3@haskell.org> References: <043.053aa1ee2284ef7ad3446d36b517c5b3@haskell.org> Message-ID: <058.d9c83e07d62a36753feb7afa8d5f764a@haskell.org> #14213: Improve the documentation of seq function -------------------------------------+------------------------------------- Reporter: sibi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | 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:D3945 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => Phab:D3945 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 18:56:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 18:56:30 -0000 Subject: [GHC] #14217: Interface-file decls for large tuples Message-ID: <047.bf95f3f7deae12cdefb07151e87149c3@haskell.org> #14217: Interface-file decls for large tuples -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm in the process of updating a large code base for GHC 8.2, and I have the following error (with -ddump-if-trace): {{{ ... Starting fork { Declaration for $fCT2 Loading decl for $fCT2 updating EPS_ Considering whether to load GHC.Prim {- SYSTEM -} Considering whether to load GHC.Prim {- SYSTEM -} } ending fork Declaration for $fCT2 Need decl for (%,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,%) Considering whether to load GHC.Classes {- SYSTEM -} Considering whether to load GHC.Types {- SYSTEM -} checkWiredInTyCon Double Crypto.Lol.Applications.Tests.SHETests Considering whether to load GHC.Types {- SYSTEM -} Starting fork { Class op ip a ty } ending fork Class op ip a ty ... Can't find interface-file declaration for type constructor or class ghc- prim-0.5.1.0:GHC.Classes.(%,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,%) Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error }}} The code in question involves a poly-kinded, promoted 8-tuple, though I have no idea where GHC is coming up with a 64-tuple. Since I'm updating a large library, I've been unable to produce a small example so far. I can make the code compile by simplifying it in various ways, so aside from this problem, the code works with 8.2.1. This issue is currently preventing me from updating my code base to 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 21:13:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 21:13:53 -0000 Subject: [GHC] #14217: Interface-file decls for large tuples In-Reply-To: <047.bf95f3f7deae12cdefb07151e87149c3@haskell.org> References: <047.bf95f3f7deae12cdefb07151e87149c3@haskell.org> Message-ID: <062.d1a4726586ad5305329f486c2b4e63a0@haskell.org> #14217: Interface-file decls for large tuples -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Until a simplified version of this code emerges, can you post a link to the failing code as-is? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 11 21:54:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Sep 2017 21:54:59 -0000 Subject: [GHC] #14186: CSE fails to CSE two identical large top-level functions In-Reply-To: <046.69825e5d45135d4ed01bf5ccfdf86282@haskell.org> References: <046.69825e5d45135d4ed01bf5ccfdf86282@haskell.org> Message-ID: <061.3af1813483175eafd174d57d9ee34c3e@haskell.org> #14186: CSE fails to CSE two identical large top-level functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: CSE Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13589 | Differential Rev(s): Phab:D3939 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => CSE * related: => #13589 Old description: > Consider this code: > > {{{ > module CSEBug where > > data Succs a = Succs a [a] > > instance Functor Succs where > fmap f (Succs o s) = Succs (f o) (map f s) > > foo, bar :: (a -> b) -> (b -> c) -> Succs a -> Succs c > foo f g x = fmap (g . f) x > bar f g x = fmap (g . f) x > }}} > > If I compile this with `-O`, `foo` and `bar` are not CSEd, which can be > seen with `-ddump-cse`. > > Removing either the first or the second argument of `Succs` makes CSE > work. > > Is there a size limit on CSE? New description: Consider this code: {{{#!hs module CSEBug where data Succs a = Succs a [a] instance Functor Succs where fmap f (Succs o s) = Succs (f o) (map f s) foo, bar :: (a -> b) -> (b -> c) -> Succs a -> Succs c foo f g x = fmap (g . f) x bar f g x = fmap (g . f) x }}} If I compile this with `-O`, `foo` and `bar` are not CSEd, which can be seen with `-ddump-cse`. Removing either the first or the second argument of `Succs` makes CSE work. Is there a size limit on CSE? -- Comment: #131589 is also somewhat relevant here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 00:43:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 00:43:23 -0000 Subject: [GHC] #11671: Allow labels starting with uppercase with OverloadedLabels In-Reply-To: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> References: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> Message-ID: <059.e9ffbe0800a2a36326cd0e30e91c18a1@haskell.org> #11671: Allow labels starting with uppercase with OverloadedLabels -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 (Parser) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by glaebhoerl): * cc: glaebhoerl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 02:04:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 02:04:44 -0000 Subject: [GHC] #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.6fe7e8986bbcd3581c517fcb03128b41@haskell.org> #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): > my guess would be that when all functions are inlined (e.g., everything is placed in the same module) or when none get inlined, performance is good, That seems to be a correct observation. When everything is in the same module the simplifier can choose to inline any of the functions while when they are in different modules only those functions that are marked INLINE/INLINABLE get inlined. This is supported by the fact that when we mark the `toList` function INLINE the difference is eliminated to a large extent. Also, it does not go away with `-fexpose-all-unfoldings` but it goes away with `-fspecialise-aggressively`. I also suspect that there is an interaction of `foldr/build` fusion with the simplifier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 02:55:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 02:55:16 -0000 Subject: [GHC] #14218: GHC.Stack.HasCallStack not compatible with ConstraintKinds Message-ID: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> #14218: GHC.Stack.HasCallStack not compatible with ConstraintKinds -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The programs `Good` and `Bad` are the same, except that `Bad` uses a constraint synonym including `GHC.Stack.HasCallStack` whereas `Good` inlines the constraints. I expect them to produce the same output, but they don't: {{{ $ ./Good ["callStack","f"] $ ./Bad ["f"] }}} Here is the source for `Good.hs`: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} -- For nullary 'Trivial' class module Main where import qualified GHC.Stack as Ghc class Trivial where instance Trivial where -- | Print the functions on the call stack. callStack :: (Ghc.HasCallStack, Trivial) => IO () callStack = print $ map fst (Ghc.getCallStack Ghc.callStack) f :: (Ghc.HasCallStack, Trivial) => IO () f = callStack main :: IO () main = f -- Should print @["callStack", "f"]@. }}} Here is the source for `Bad.hs`: {{{#!hs {-# LANGUAGE ConstraintKinds #-} -- For 'C' {-# LANGUAGE MultiParamTypeClasses #-} -- For nullary 'Trivial' class module Main where import qualified GHC.Stack as Ghc class Trivial where instance Trivial where type C = (Ghc.HasCallStack, Trivial) -- | Print the functions on the call stack. callStack :: C => IO () callStack = print $ map fst (Ghc.getCallStack Ghc.callStack) f :: C => IO () f = callStack main :: IO () main = f -- Should print @["callStack", "f"]@. }}} Tested compiled and interpreted with GHC 8.2.1 and 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 02:55:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 02:55:46 -0000 Subject: [GHC] #14218: GHC.Stack.HasCallStack not compatible with ConstraintKinds In-Reply-To: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> References: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> Message-ID: <058.8513f08adaf17477304563e50ebf7ff4@haskell.org> #14218: GHC.Stack.HasCallStack not compatible with ConstraintKinds -------------------------------------+------------------------------------- Reporter: ntc2 | 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: | -------------------------------------+------------------------------------- Changes (by ntc2): * Attachment "Good.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 02:55:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 02:55:58 -0000 Subject: [GHC] #14218: GHC.Stack.HasCallStack not compatible with ConstraintKinds In-Reply-To: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> References: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> Message-ID: <058.e4705c8f896028696e5431d0a385da4b@haskell.org> #14218: GHC.Stack.HasCallStack not compatible with ConstraintKinds -------------------------------------+------------------------------------- Reporter: ntc2 | 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: | -------------------------------------+------------------------------------- Changes (by ntc2): * Attachment "Bad.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 03:00:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 03:00:10 -0000 Subject: [GHC] #14214: Users guide lies about default optimization level In-Reply-To: <046.736805dbdfc6944b76008d4f99ba283f@haskell.org> References: <046.736805dbdfc6944b76008d4f99ba283f@haskell.org> Message-ID: <061.5e5f697141b00b885f6f9f267d9ce27e@haskell.org> #14214: Users guide lies about default optimization level -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): There are a number of issues with the documentation of optimization options. I guess all those can be dealt with in this ticket. 1) The inconsistency described above in the ticket description is in the "Flag Reference" chapter: {{{ Flag Description Type Reverse -O0 Disable optimisations (default) dynamic -O }}} 2) I would also suggest that we have another column in the "6.6.15. Individual optimisations" section to indicate which optimization levels enable each option. It could be in the form "0, 1, 2". This will really help in quickly identifying the options applicable to a particular level. 3) 6.3.1. -O*: convenient “packages” of optimisation flags. This section should perhaps mention what is the default? 4) 6.3.1. -O*: convenient “packages” of optimisation flags. This section says: "The easiest way to see what -O (etc.) “really mean” is to run with -v, then stand back in amazement." But when I tried it "-v" did not tell me what options are enabled. 5) Some flags are documented like this: {{{ -fno-opt-coercion Default: off Turn off the coercion optimiser. }}} This is confusing. It says "Default: off", the double negation would mean that "-fopt-coercion" is "on". Is that the case? Is there a "-fopt- coercion"? If yes, can we document that instead? If not, we can be more explicit about the double negation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 03:20:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 03:20:02 -0000 Subject: [GHC] #14219: Include source location information in -ddump-rule-rewrites Message-ID: <047.c5d8fff0aa504d949deaebba16956b0e@haskell.org> #14219: Include source location information in -ddump-rule-rewrites -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Debugging) | 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: -------------------------------------+------------------------------------- Inlining is one of the most common and powerful optimizations and it interacts with rewrite-rules which is also common the libraries including base. When debugging a performance problem we are interacting with the rewrite-rules written by others hidden somewhere in some library that we are using. When I use the `-ddump-rule-rewrites` option I get an output like this: {{{ Rule fired Rule: Class op >>= Module: (BUILTIN) Before: GHC.Base.>>= TyArg GHC.Types.IO ValArg GHC.Base.$fMonadIO After: GHC.Base.$fMonadIO1 }}} This does not say where exactly this rule is defined in the source. It is sort of ok if this is my code I would perhaps know where this rule is. But when it is in some dependency that I am using it is hard to find. It will be really helpful if the source location information can be provided in this dump information, so that one can go and examine the source. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 03:26:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 03:26:49 -0000 Subject: [GHC] #14219: Include source location information in -ddump-rule-rewrites In-Reply-To: <047.c5d8fff0aa504d949deaebba16956b0e@haskell.org> References: <047.c5d8fff0aa504d949deaebba16956b0e@haskell.org> Message-ID: <062.9aa6cbe50194f68bc222ab5afe2accf1@haskell.org> #14219: Include source location information in -ddump-rule-rewrites -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Debugging) | 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: | -------------------------------------+------------------------------------- Comment (by harendra): I guess the problem is with GHC builtin rules only. Otherwise the Module name and the rule name will be good enough to identify where the rule is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 04:46:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 04:46:52 -0000 Subject: [GHC] #14219: Include source location information in -ddump-rule-rewrites In-Reply-To: <047.c5d8fff0aa504d949deaebba16956b0e@haskell.org> References: <047.c5d8fff0aa504d949deaebba16956b0e@haskell.org> Message-ID: <062.84af3d77474666de5c8e3d755fb1a5e4@haskell.org> #14219: Include source location information in -ddump-rule-rewrites -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Debugging) | 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: | -------------------------------------+------------------------------------- Comment (by harendra): A good way to address this could be to document the BUILTIN rules in the GHC manual. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 04:50:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 04:50:07 -0000 Subject: [GHC] #14217: Interface-file decls for large tuples In-Reply-To: <047.bf95f3f7deae12cdefb07151e87149c3@haskell.org> References: <047.bf95f3f7deae12cdefb07151e87149c3@haskell.org> Message-ID: <062.30906ba1280aae54b0ffe82850340c6d@haskell.org> #14217: Interface-file decls for large tuples -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, the tuple in question isn't a "regular" tuple but rather a constraint tuple. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 04:53:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 04:53:52 -0000 Subject: [GHC] #14220: GeneralizedNewtypeDeriving and polymorphic arguments don't play nicely together Message-ID: <044.47b5d9254ee70fb6ce7fb05ecd1cb26c@haskell.org> #14220: GeneralizedNewtypeDeriving and polymorphic arguments don't play nicely together --------------------------------------+--------------------------------- Reporter: ivanm | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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'm not sure if this is a bug per se, but ghci says to report it so here it is: test.hs: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} class NameOf a where nameOf :: proxy a -> String instance NameOf Int where nameOf _ = "Int" newtype MyInt = MyInt Int deriving (NameOf) }}} {{{ $ ghci test.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( test.hs, interpreted ) test.hs:10:13: warning: [-Wdeferred-type-errors] • Couldn't match representation of type ‘proxy1 Int’ with that of ‘proxy1 MyInt’ arising from a use of ‘GHC.Prim.coerce’ NB: We cannot know what roles the parameters to ‘proxy1’ have; we must assume that the role is nominal • In the expression: GHC.Prim.coerce @(forall (proxy :: TYPE GHC.Types.PtrRepLifted -> TYPE GHC.Types.PtrRepLifted). proxy Int -> String) @(forall (proxy :: TYPE GHC.Types.PtrRepLifted -> TYPE GHC.Types.PtrRepLifted). proxy MyInt -> String) nameOf In an equation for ‘nameOf’: nameOf = GHC.Prim.coerce @(forall (proxy :: TYPE GHC.Types.PtrRepLifted -> TYPE GHC.Types.PtrRepLifted). proxy Int -> String) @(forall (proxy :: TYPE GHC.Types.PtrRepLifted -> TYPE GHC.Types.PtrRepLifted). proxy MyInt -> String) nameOf When typechecking the code for ‘nameOf’ in a derived instance for ‘NameOf MyInt’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘NameOf MyInt’ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): opt_univ fell into a hole {a15j} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 06:36:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 06:36:42 -0000 Subject: [GHC] #14219: Include source location information in -ddump-rule-rewrites In-Reply-To: <047.c5d8fff0aa504d949deaebba16956b0e@haskell.org> References: <047.c5d8fff0aa504d949deaebba16956b0e@haskell.org> Message-ID: <062.e4c37481f42b94aceb9ace1080d6ca2e@haskell.org> #14219: Include source location information in -ddump-rule-rewrites -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Debugging) | 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: | -------------------------------------+------------------------------------- Comment (by harendra): Is it feasible/worth it to implement dumping the builtin rules via the `-ddump-rules` option? Then `-ddump-rule-rewrites` output can just refer to the rule-id of the rule dumped via the `-ddump-rules` option. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 07:57:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 07:57:54 -0000 Subject: [GHC] #14221: yaml-0.8.23.3 fails to build with -g Message-ID: <046.9dadad43b611bdb3c19cc87ee92d4f08@haskell.org> #14221: yaml-0.8.23.3 fails to build with -g -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (NCG) | 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: -------------------------------------+------------------------------------- `yaml-0.8.23.3` fails to build with an assembler error, {{{ $ cabal unpack yaml-0.8.23.3 $ ghc Data/Yaml/Internal.hs -O -g [1 of 2] Compiling Text.Libyaml ( Text/Libyaml.hs, Text/Libyaml.o ) [Data.Conduit changed] [2 of 2] Compiling Data.Yaml.Internal ( Data/Yaml/Internal.hs, Data/Yaml/Internal.o ) /tmp/ghc17780_0/ghc_9.s: Assembler messages: /tmp/ghc17780_0/ghc_9.s:64575:0: error: Error: can't resolve `.LcJO0_entry_end' {*UND* section} - `cJO0_entry' {*UND* section} | 64575 | .quad .LcJO0_entry_end-cJO0_entry | ^ `gcc' failed in phase `Assembler'. (Exit code: 1) }}} Strangely enough, the symbols `.LcJO0` and `.LcJO0_end` are defined in the resulting assembler, but not `.LcJO0_entry_end` nor `cJO0_entry`. I suspect the backend -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 08:17:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 08:17:05 -0000 Subject: [GHC] #14221: yaml-0.8.23.3 fails to build with -g In-Reply-To: <046.9dadad43b611bdb3c19cc87ee92d4f08@haskell.org> References: <046.9dadad43b611bdb3c19cc87ee92d4f08@haskell.org> Message-ID: <061.a7ed04927bb1a1155e698443e64426c7@haskell.org> #14221: yaml-0.8.23.3 fails to build with -g -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | 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: | -------------------------------------+------------------------------------- Old description: > `yaml-0.8.23.3` fails to build with an assembler error, > {{{ > $ cabal unpack yaml-0.8.23.3 > $ ghc Data/Yaml/Internal.hs -O -g > [1 of 2] Compiling Text.Libyaml ( Text/Libyaml.hs, Text/Libyaml.o ) > [Data.Conduit changed] > [2 of 2] Compiling Data.Yaml.Internal ( Data/Yaml/Internal.hs, > Data/Yaml/Internal.o ) > /tmp/ghc17780_0/ghc_9.s: Assembler messages: > > /tmp/ghc17780_0/ghc_9.s:64575:0: error: > Error: can't resolve `.LcJO0_entry_end' {*UND* section} - > `cJO0_entry' {*UND* section} > | > 64575 | .quad .LcJO0_entry_end-cJO0_entry > | ^ > `gcc' failed in phase `Assembler'. (Exit code: 1) > }}} > > Strangely enough, the symbols `.LcJO0` and `.LcJO0_end` are defined in > the resulting assembler, but not `.LcJO0_entry_end` nor `cJO0_entry`. I > suspect the backend New description: `yaml-0.8.23.3` fails to build with an assembler error, {{{ $ cabal unpack yaml-0.8.23.3 $ ghc Data/Yaml/Internal.hs -O -g -keep-tmp-files -ddump-cmm -ddump-to- file -ddump-stg -ddump-cmm-verbose [2 of 2] Compiling Data.Yaml.Internal ( Data/Yaml/Internal.hs, Data/Yaml/Internal.o ) /tmp/ghc26515_0/ghc_6.s: Assembler messages: /tmp/ghc26515_0/ghc_6.s:64491:0: error: Error: can't resolve `.LcsyP_entry_end' {*UND* section} - `csyP_entry' {*UND* section} | 64491 | .quad .LcsyP_entry_end-csyP_entry | ^ `gcc' failed in phase `Assembler'. (Exit code: 1) }}} Strangely enough, there are local symbols `.LcsyP` and `.LcsyP_end` are defined in the resulting assembler (as local labels within `DataziYamlziInternal_zdwisNumeric_info`), but not `.LcsyP_entry_end` nor `csyP_entry`. -- Comment (by bgamari): Here is a minimal reproducer, {{{#!hs module T14221 where import Data.Text as T isNumeric :: Text -> Bool isNumeric t = T.all isNumeric' t && T.any isNumber t where isNumber c = '0' <= c && c <= '9' isNumeric' c = isNumber c || c == 'e' || c == 'E' || c == '.' || c == '-' || c == '+' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 08:23:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 08:23:47 -0000 Subject: [GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> References: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> Message-ID: <059.681d7dd568e87aaebca6817dea0682b8@haskell.org> #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 (Linker) | 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 bgamari): * cc: JaffaCake (added) Comment: A second attempt at bisection (this time just within `rts/`) reveals that this is due to f9c6d53fe997f1c560cda6f346f4b201711df37c, {{{ git bisect start 'rts' # good: [54ccf0c957a279c20e1a37a5a462612af8036739] remove dead function 'tcInstBinders' git bisect good 54ccf0c957a279c20e1a37a5a462612af8036739 # bad: [d08b9ccdf2812e8f8fa34d0c89275deee574524c] configure: Ensure that user's LD setting is respected git bisect bad d08b9ccdf2812e8f8fa34d0c89275deee574524c # bad: [555e5cc48b6c2608ae8d4bd3b2a5bd2ef63236ab] rts: Address AP_STACK comment suggestion from Simon git bisect bad 555e5cc48b6c2608ae8d4bd3b2a5bd2ef63236ab # bad: [a6f3d1b00e9c37a56cd4db9e519309e94a65d181] rts: Fix isByteArrayPinned#'s treatment of large arrays git bisect bad a6f3d1b00e9c37a56cd4db9e519309e94a65d181 # bad: [f9c6d53fe997f1c560cda6f346f4b201711df37c] Tag the FUN before making a PAP (#13767) git bisect bad f9c6d53fe997f1c560cda6f346f4b201711df37c # good: [9b514dedf090c5e21e3be38d174cf1390e21879f] rts/RetainerProfile: Const-correctness fixes git bisect good 9b514dedf090c5e21e3be38d174cf1390e21879f # first bad commit: [f9c6d53fe997f1c560cda6f346f4b201711df37c] Tag the FUN before making a PAP (#13767) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 08:31:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 08:31:05 -0000 Subject: [GHC] #14222: Simple text fusion example results in rather duplicative code Message-ID: <046.acf3e774499e29f098fdca7495f195f8@haskell.org> #14222: Simple text fusion example results in rather duplicative code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this program, {{{#!hs module T14221 where import Data.Text as T isNumeric :: Text -> Bool isNumeric t = T.all isNumeric' t && T.any isNumber t where isNumber c = '0' <= c && c <= '9' isNumeric' c = isNumber c || c == 'e' || c == 'E' || c == '.' || c == '-' || c == '+' }}} Compiling with `-O` results in over 1 kilobyte of assembler. After looking at the simplified Core the issue becomes apparent: the case analysis of `isNumeric'` is duplicated six times, {{{#!hs case ww4_X2zB of { __DEFAULT -> GHC.Types.False; '+'# -> jump $wloop_all_s2z2 (GHC.Prim.+# ww3_s2z0 2#); '-'# -> jump $wloop_all_s2z2 (GHC.Prim.+# ww3_s2z0 2#); '.'# -> jump $wloop_all_s2z2 (GHC.Prim.+# ww3_s2z0 2#); 'E'# -> jump $wloop_all_s2z2 (GHC.Prim.+# ww3_s2z0 2#); 'e'# -> jump $wloop_all_s2z2 (GHC.Prim.+# ww3_s2z0 2#) }; }}} It seems to me that we would ideally try to share this bit. Of course, this may be quite tricky to do in practice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 08:37:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 08:37:17 -0000 Subject: [GHC] #14221: yaml-0.8.23.3 fails to build with -g In-Reply-To: <046.9dadad43b611bdb3c19cc87ee92d4f08@haskell.org> References: <046.9dadad43b611bdb3c19cc87ee92d4f08@haskell.org> Message-ID: <061.91f12caa9e5a057b823822b7009707e2@haskell.org> #14221: yaml-0.8.23.3 fails to build with -g -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | 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 bgamari): By contrast, a relatively naive translation to C compiled with `gcc -O0` requires less than half the code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 08:38:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 08:38:19 -0000 Subject: [GHC] #14222: Simple text fusion example results in rather duplicative code In-Reply-To: <046.acf3e774499e29f098fdca7495f195f8@haskell.org> References: <046.acf3e774499e29f098fdca7495f195f8@haskell.org> Message-ID: <061.e8f066d73cc4888074af062d2a68bfd8@haskell.org> #14222: Simple text fusion example results in rather duplicative code -------------------------------------+------------------------------------- Reporter: bgamari | 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 bgamari): By contrast, a relatively naive translation to C compiled with `gcc -O0` requires less than half the code, {{{#!c #include #include bool isNumber(uint16_t c) { return '0' <= c && c <= '9'; } bool isNumeric(uint16_t c) { if (isNumber(c)) return true; switch (c) { case 'e': case 'E': case '.': case '-': case '+': return true; default: return false; } } bool test(uint16_t *buf, int len) { for (int i=0; i GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 09:32:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 09:32:43 -0000 Subject: [GHC] #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) In-Reply-To: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> References: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> Message-ID: <057.1f5979b081225693f6dd8b2de66456e1@haskell.org> #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: libraries/base | 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: #10365 | Differential Rev(s): phab:D3927 Wiki Page: | prime:Libraries/Proposals/SemigroupMonoid| -------------------------------------+------------------------------------- Comment (by siddhanathan): Is deprecating `Data.Semigroup.Option` within the scope of this proposal? It should now be obsolete since Semigroup is a superclass of Monoid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 09:33:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 09:33:01 -0000 Subject: [GHC] #14220: GeneralizedNewtypeDeriving and polymorphic arguments don't play nicely together In-Reply-To: <044.47b5d9254ee70fb6ce7fb05ecd1cb26c@haskell.org> References: <044.47b5d9254ee70fb6ce7fb05ecd1cb26c@haskell.org> Message-ID: <059.9d669703fe1c19000deb3cb13d508c4f@haskell.org> #14220: GeneralizedNewtypeDeriving and polymorphic arguments don't play nicely together ---------------------------------+-------------------------------------- Reporter: ivanm | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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 Iceland_jack): Doesn't panic for 8.0.1 {{{ $ ghci -ignore-dot-ghci /tmp/a.hs GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( /tmp/a.hs, interpreted ) /tmp/a.hs:10:13: Could not coerce from ‘proxy Int’ to ‘proxy MyInt’ because ‘proxy Int’ and ‘proxy MyInt’ are different types. arising from the coercion of the method ‘nameOf’ from type ‘forall (proxy :: * -> *). proxy Int -> String’ to type ‘forall (proxy :: * -> *). proxy MyInt -> String’ Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (NameOf MyInt) Failed, modules loaded: none. Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 11:30:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 11:30:13 -0000 Subject: [GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> References: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> Message-ID: <059.9289150529e6e2ba07bad6a62d04dcac@haskell.org> #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 (Linker) | 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): That commit has been particularly problematic, as it's also responsible for #14036. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 11:39:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 11:39:44 -0000 Subject: [GHC] #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.57c90416aae2523b8fa9917c686897a0@haskell.org> #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): I added a much simpler example on the "simplified" branch in the same repo. I can paste it here as well: Main.hs {{{#!hs import List ... len :: IO Int len = do xs <- toList $ (foldr (<>) mempty $ map (\x -> Yield x Stop) [1..100000 :: Int]) return (length xs) }}} List.hs {{{#!hs module List where import Control.Monad (liftM) data List a = Stop | Yield a (List a) instance Monoid (List a) where mempty = Stop mappend x y = case x of Stop -> y Yield a r -> Yield a (mappend r y) toList :: Monad m => List a -> m [a] toList m = case m of Stop -> return [] Yield a r -> liftM (a :) (toList r) }}} It essentially generates a custom list in the main module and calls `toList` function from another module to covert it into a Haskell list. The perf difference is not as dramatic as the previous example but it is significant. All in the same module: {{{ -O0 : 14ms -O1 : 8ms -fno-pre-inlining: 4ms }}} Different modules: {{{ -O0 : 8ms -O1 : 14ms -fno-pre-inlining: 8ms INLINE toList : 4ms }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 11:54:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 11:54:15 -0000 Subject: [GHC] #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.7555915ca08943584b282156908ed0b2@haskell.org> #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): When I look at `-ddump-rewrite-rules` output the list fusion rules seem to get fired in the `-fno-pre-inlining` case but not in the `-O1` case. Specifically I do not see the "map" rule (and subsequent other rules triggered by it) in the `-O1` output. As long as we understand why it is happening and there is no easy way to fix it, I guess it is fine. But I hope this can be fixed so that we do not spend time wondering about and figuring out such things and manually tweaking options and pragmas to get to the right combination. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 12:15:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 12:15:35 -0000 Subject: [GHC] #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) In-Reply-To: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> References: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> Message-ID: <057.241c5176d7dd5cc986a912a017436187@haskell.org> #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: libraries/base | 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: #10365 | Differential Rev(s): phab:D3927 Wiki Page: | prime:Libraries/Proposals/SemigroupMonoid| -------------------------------------+------------------------------------- Comment (by Iceland_jack): The `Monoid` instances still differ {{{#!hs Semigroup a => Monoid (Option a) Monoid a => Monoid (Maybe a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 13:12:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 13:12:12 -0000 Subject: [GHC] #14220: GeneralizedNewtypeDeriving and polymorphic arguments don't play nicely together In-Reply-To: <044.47b5d9254ee70fb6ce7fb05ecd1cb26c@haskell.org> References: <044.47b5d9254ee70fb6ce7fb05ecd1cb26c@haskell.org> Message-ID: <059.40e3aa7576abb0a55b464dcd5f188813@haskell.org> #14220: GeneralizedNewtypeDeriving and polymorphic arguments don't play nicely together ---------------------------------+-------------------------------------- Reporter: ivanm | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12104 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by RyanGlScott): * related: => #12104 Comment: Thanks for the bug report. Note that this only happens when `-fdefer-type- errors` is on. This is a duplicate of #12104, which has been fixed in GHC 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 13:12:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 13:12:25 -0000 Subject: [GHC] #14220: GeneralizedNewtypeDeriving and polymorphic arguments don't play nicely together In-Reply-To: <044.47b5d9254ee70fb6ce7fb05ecd1cb26c@haskell.org> References: <044.47b5d9254ee70fb6ce7fb05ecd1cb26c@haskell.org> Message-ID: <059.042a31a86650fccaef6fc8a20202bf6f@haskell.org> #14220: GeneralizedNewtypeDeriving and polymorphic arguments don't play nicely together ---------------------------------+-------------------------------------- Reporter: ivanm | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12104 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 13:13:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 13:13:33 -0000 Subject: [GHC] #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) In-Reply-To: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> References: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> Message-ID: <057.e02cacef58d67b5c096f2cdef307f576@haskell.org> #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: libraries/base | 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: #10365 | Differential Rev(s): phab:D3927 Wiki Page: | prime:Libraries/Proposals/SemigroupMonoid| -------------------------------------+------------------------------------- Comment (by RyanGlScott): The subtext of that question is that there are eventual plans to change the `Monoid` instance for `Maybe` to be `instance Semigroup a => Monoid (Maybe a)` (i.e., to remove [http://git.haskell.org/ghc.git/blob/838a10fcad9168895b49b4709056b549f2888860:/libraries/base/GHC/Base.hs#l413 this piece] of documentation). When that happens, there really will be no substantial difference between `Option` and `Maybe`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 13:19:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 13:19:41 -0000 Subject: [GHC] #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) In-Reply-To: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> References: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> Message-ID: <057.1a3f85801211806f56143545dde7f427@haskell.org> #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: libraries/base | 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: #10365 | Differential Rev(s): phab:D3927 Wiki Page: | prime:Libraries/Proposals/SemigroupMonoid| -------------------------------------+------------------------------------- Comment (by Iceland_jack): I would love to see that happen if it doesn't cause BC problems (then maybe.. `Apply f => Applicative (Lift f)`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 13:23:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 13:23:50 -0000 Subject: [GHC] #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) In-Reply-To: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> References: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> Message-ID: <057.bd719bbf728393955e709a6a568b9006@haskell.org> #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: libraries/base | 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: #10365 | Differential Rev(s): phab:D3927 Wiki Page: | prime:Libraries/Proposals/SemigroupMonoid| -------------------------------------+------------------------------------- Comment (by RyanGlScott): The SMP is already a rather backwards //in//compatible change as it is (in the sense that many libraries are going to be broken until they catch up and add `Semigroup` instances), so I don't feel too shaken up about changing a `Monoid` constraint to a `Semigroup` one on top of that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 13:40:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 13:40:46 -0000 Subject: [GHC] #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) In-Reply-To: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> References: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> Message-ID: <057.bcc5781c6099d73ca12a39ab3803447b@haskell.org> #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: libraries/base | 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: #10365 | Differential Rev(s): phab:D3927 Wiki Page: | prime:Libraries/Proposals/SemigroupMonoid| -------------------------------------+------------------------------------- Comment (by Iceland_jack): Sounds good -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 13:45:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 13:45:33 -0000 Subject: [GHC] #14219: Include source location information in -ddump-rule-rewrites In-Reply-To: <047.c5d8fff0aa504d949deaebba16956b0e@haskell.org> References: <047.c5d8fff0aa504d949deaebba16956b0e@haskell.org> Message-ID: <062.2c2e34c8ea3f0eeb6d5685f5328286ec@haskell.org> #14219: Include source location information in -ddump-rule-rewrites -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Debugging) | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): > Is it feasible/worth it to implement dumping the builtin rules via the -ddump-rules option? Sadly built-in rules can do things that are hard to express using ordinary LHS/RHS pairs. Like rewriting `4+5` to `9`. That's why they are implemented in code, not pattern matching. It would be a worthy thing to document all the built-in rules in `PrelRules` in the manual. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 15:02:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 15:02:35 -0000 Subject: [GHC] #14186: CSE fails to CSE two identical large top-level functions In-Reply-To: <046.69825e5d45135d4ed01bf5ccfdf86282@haskell.org> References: <046.69825e5d45135d4ed01bf5ccfdf86282@haskell.org> Message-ID: <061.2f22501aa4724b835943c77b40b0c835@haskell.org> #14186: CSE fails to CSE two identical large top-level functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: CSE Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13589 | Differential Rev(s): Phab:D3939 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"fe04f3783b662c52c4a0ff36b2d62a7a575998a5/ghc" fe04f378/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fe04f3783b662c52c4a0ff36b2d62a7a575998a5" Allow CSE'ing of work-wrapped bindings (#14186) the worker/wrapper creates an artificial INLINE pragma, which caused CSE to not do its work. We now recognize such artificial pragmas by using `NoUserInline` instead of `Inline` as the `InlineSpec`. Differential Revision: https://phabricator.haskell.org/D3939 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 15:02:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 15:02:35 -0000 Subject: [GHC] #14186: CSE fails to CSE two identical large top-level functions In-Reply-To: <046.69825e5d45135d4ed01bf5ccfdf86282@haskell.org> References: <046.69825e5d45135d4ed01bf5ccfdf86282@haskell.org> Message-ID: <061.f706ee645700383b7bcdf6d3c0787d82@haskell.org> #14186: CSE fails to CSE two identical large top-level functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: CSE Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13589 | Differential Rev(s): Phab:D3939 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"fe35b85a8cc72582e0f98a3059be00a9a2318a4a/ghc" fe35b85a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fe35b85a8cc72582e0f98a3059be00a9a2318a4a" Add testcase for #14186 and move the generally useful helpers check_errmsg and grep_errmsg to testlib.py. Some documentation can be found on https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Adding }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 15:04:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 15:04:54 -0000 Subject: [GHC] #14222: Simple text fusion example results in rather duplicative code In-Reply-To: <046.acf3e774499e29f098fdca7495f195f8@haskell.org> References: <046.acf3e774499e29f098fdca7495f195f8@haskell.org> Message-ID: <061.4f4b8806e8ac9cdccf893610bfed5f03@haskell.org> #14222: Simple text fusion example results in rather duplicative code -------------------------------------+------------------------------------- Reporter: bgamari | 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 nomeata): Shouldn’t the common block elimination on the CMM level take care of that kind of duplication? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 15:09:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 15:09:32 -0000 Subject: [GHC] #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.edf52f4298cbf80e9f164a59046a492c@haskell.org> #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): Another question that I am seeking an answer for - is there a combination of options to make a multi-module program behave the same way as if all the code is in a single module, from the performance perspective? I expected that `-fexpose-all-unfoldings` will do that for me but it does not seem to be equivalent. I thought it is equivalent to making all functions INLINABLE but it does not seem to be doing that. Even when using this flag I need to mark a function INLINABLE to get it inlined. What exactly does this flag do? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 15:11:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 15:11:10 -0000 Subject: [GHC] #14217: Interface-file decls for large tuples In-Reply-To: <047.bf95f3f7deae12cdefb07151e87149c3@haskell.org> References: <047.bf95f3f7deae12cdefb07151e87149c3@haskell.org> Message-ID: <062.0a2ff877d21836fb31c90d9aca9e5afb@haskell.org> #14217: Interface-file decls for large tuples -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): Here's the code in question. {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE PartialTypeSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RebindableSyntax #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -fno-warn-partial-type-signatures #-} module Crypto.Lol.Applications.Tests.SHETests (tunnelTests) where import Control.Monad.Random import Crypto.Lol import Crypto.Lol.Applications.SymmSHE import Crypto.Lol.Tests import qualified Test.Framework as TF tunnelTests :: forall t r r' s s' zp zq gad . (_) => Proxy '(r,r',s,s',zp,zq) -> Proxy gad -> Proxy t -> TF.Test tunnelTests _ _ _ = let ptmr = Proxy::Proxy '(t,r,r',s,s',zp,zq,gad) in TF.testGroup (showType ptmr) [genTestArgs "Tunnel" prop_ringTunnel ptmr] prop_ringTunnel :: (TunnelHintCtx t e r s e' r' s' z zp zq gad, EncryptCtx t r r' z zp zq, DecryptUCtx t s s' z zp zq, e ~ FGCD r s) => PT (Cyc t r zp) -> SK (Cyc t r' z) -> SK (Cyc t s' z) -> Test '(t,r,r',s,s',zp,zq,gad) prop_ringTunnel x skin skout = undefined }}} bgamari: That's useful to know! The constraints on `prop_ringTunnel` (`TunnelHintCtx`, `EncryptCtx`, and `DecryptCtx`) are all (large) constraint synonyms. The offending line is actually `tunnelTests _ _ _ =`. Although the error in this ticket is killing compilation before I get a warning about the partial type signature (which would include the entire constraint list for `tunnelTests`), I know that the list is heinous -- that's why I'm using PTSs in the first place! It wouldn't surprise me at all to know it had 64 items in it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 16:07:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 16:07:28 -0000 Subject: [GHC] #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.6796d8593949db6560a578fb99e33741@haskell.org> #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Great job simplifying the example! Every bit of code eliminated helps GHC hackers immensely to tackle this (which may take a while anyway, especially given the busy time of year). Even if the contrived example looks nonsensical and silly. There is less noise, fewer suspects and the Core is less overwhelming. The combination of `-fexpose-all-unfoldings` and `-fspecialise- aggressively` is close to (or even equivalent) to putting everything in a single module. See https://ghc.haskell.org/trac/ghc/ticket/12463#comment:19 and other comments in that thread. The only drawback is that GHC takes much more memory. A hack around that (at least before 8.2.1) is to restart GHC during compilation when it hogs too much memory (or travis_retry after out-of-memory segfault in travis scripts). If you see worse fusion behaviour `-O1` than `-O0`, I guess here is hope it can be fine-tuned in that particular case or even that it's a bug. I wonder who is hacking on the fusion machinery these days... But in general, inlining (especially of only a subset of functions) that makes performance worse is a fact of life, though GHC strives hard not to _automatically_ inline in such suspect cases. I wonder, if you marked `toList` NOINLINE and the Monoid methods INLINE, but put everything in the same module, would you still have the bad behaviour? That would hint that the (partial) inlining inhibits fusion and would show which combination of inline decisions is responsible (so that GHC may be improved for that combination or may be prevented from automatically generating such partial inlining). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 16:52:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 16:52:29 -0000 Subject: [GHC] #10651: Type checking issue with existential quantification, rank-n types and constraint kinds In-Reply-To: <046.13e821c10925b9eff72404016930e9cc@haskell.org> References: <046.13e821c10925b9eff72404016930e9cc@haskell.org> Message-ID: <061.7410cece095e220e1d7a3305d03aa2bd@haskell.org> #10651: Type checking issue with existential quantification, rank-n types and constraint kinds -------------------------------------+------------------------------------- Reporter: Roboguy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Roboguy): It looks like the following works (on GHC 8.2.1 at least). Is this because the `Proxy b` makes it so that `b` is no longer untouchable? I also notice the explicit type annotation in the lambda argument is still necessary. {{{ constrMapM :: Monad m => (forall a. c a => a -> m b) -> ConstrList c -> m [b] constrMapM = ... constrMapM_ :: forall m c b. Monad m => (forall a. (c a) => a -> m b) -> Proxy b -> ConstrList c -> m () constrMapM_ f Proxy x = constrMapM f x >>= (\(x1 :: [b]) -> return ()) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 16:56:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 16:56:21 -0000 Subject: [GHC] #14203: GHC-inferred type signature doesn't actually typecheck In-Reply-To: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> References: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> Message-ID: <065.dcda3faa539e78dcdde00d1eedd8f445@haskell.org> #14203: GHC-inferred type signature doesn't actually typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The type of `SMkSigma` is also ambiguous. There's no way to infer `p` from the visible arguments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 17:29:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 17:29:20 -0000 Subject: [GHC] #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.8fa53dfec553f9e2f36e1734fc2bbb4c@haskell.org> #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): I guess some function getting inlined too early is preventing list fusion. The combination of `-fexpose-all-unfoldings` and `-fspecialise- aggressively` is not "exactly" equivalent to putting everything in the same module. O1 with everything in the same module finishes in 8ms while with the combination of these two finishes in 4ms. So they do something more. I guess the added effect is that they make everything INLINEABLE. When everything is in the same module and `toList` marked NOINLINE then it takes 14ms (i.e. the worst case) irrespective of the monoid functions being marked INLINE or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 17:36:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 17:36:00 -0000 Subject: [GHC] #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.354ccb68ce95482e2e549be71dedb496@haskell.org> #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Harendra, have you read my post about how this part of GHC works? It might be useful for you or at least useful to point other people to. Your tickets have good examples in, I will try to get back to them once I am back from holiday. http://mpickering.github.io/posts/2017-03-20-inlining-and- specialisation.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 18:38:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 18:38:10 -0000 Subject: [GHC] #14217: Interface-file decls for large tuples In-Reply-To: <047.bf95f3f7deae12cdefb07151e87149c3@haskell.org> References: <047.bf95f3f7deae12cdefb07151e87149c3@haskell.org> Message-ID: <062.661ec96eed3172bd5b47f24b61d4d64b@haskell.org> #14217: Interface-file decls for large tuples -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * priority: normal => high * milestone: => 8.2.2 Comment: Thanks crockeea, thanks was tremendously helpful. It turns out you can also trigger this error with this program (which has no external dependencies): {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} {-# OPTIONS_GHC -Wno-partial-type-signatures #-} module Bug where data Foo a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a16 a17 a18 a19 a20 a21 a22 a23 a24 a25 a26 a27 a28 a29 a30 a31 a32 a33 a34 a35 a36 a37 a38 a39 a40 a41 a42 a43 a44 a45 a46 a47 a48 a49 a50 a51 a52 a53 a54 a55 a56 a57 a58 a59 a60 a61 a62 a63 = MkFoo a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a16 a17 a18 a19 a20 a21 a22 a23 a24 a25 a26 a27 a28 a29 a30 a31 a32 a33 a34 a35 a36 a37 a38 a39 a40 a41 a42 a43 a44 a45 a46 a47 a48 a49 a50 a51 a52 a53 a54 a55 a56 a57 a58 a59 a60 a61 a62 a63 deriving Eq eqFoo :: _ => Foo a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a16 a17 a18 a19 a20 a21 a22 a23 a24 a25 a26 a27 a28 a29 a30 a31 a32 a33 a34 a35 a36 a37 a38 a39 a40 a41 a42 a43 a44 a45 a46 a47 a48 a49 a50 a51 a52 a53 a54 a55 a56 a57 a58 a59 a60 a61 a62 a63 -> Foo a1 a2 a3 a4 a5 a6 a7 a8 a9 a10 a11 a12 a13 a14 a15 a16 a17 a18 a19 a20 a21 a22 a23 a24 a25 a26 a27 a28 a29 a30 a31 a32 a33 a34 a35 a36 a37 a38 a39 a40 a41 a42 a43 a44 a45 a46 a47 a48 a49 a50 a51 a52 a53 a54 a55 a56 a57 a58 a59 a60 a61 a62 a63 -> Bool eqFoo = (==) }}} {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:37:1: error: Can't find interface-file declaration for type constructor or class GHC.Classes.(%,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,%) Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error | 37 | eqFoo = (==) | ^^^^^^^^^^^^ }}} As you observed, this error does not occur in GHC 8.0.1 or 8.0.2, so this is a regression. I'll bump the priority accordingly. (Interestingly, 63 appears to be the minimum constraint tuple size that GHC complains about, since removing `a63` from `Foo` causes it to compile again.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 18:52:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 18:52:28 -0000 Subject: [GHC] #14203: GHC-inferred type signature doesn't actually typecheck In-Reply-To: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> References: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> Message-ID: <065.1907f58599f2bb4e84a3a49101b0dbfe@haskell.org> #14203: GHC-inferred type signature doesn't actually typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Huh, that's interesting... how do you resolve such an ambiguity, then? Normally, my approach is to add proxies until the ambiguity is resolved, such as what I tried below: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind import Data.Proxy data TyFun :: * -> * -> * type a ~> b = TyFun a b -> * infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 data family Sing :: k -> * data Sigma (a :: *) :: (a ~> *) -> * where MkSigma :: forall (a :: *) (p :: a ~> *) (x :: a). Sing x -> Apply p x -> Sigma a p data instance Sing (z :: Sigma a p) where SMkSigma :: forall a (p :: a ~> *) (x :: a) (sx :: Sing x) (px :: Apply p x). Proxy a -> Proxy p -> Proxy x -> Sing sx -> Sing px -> Sing (MkSigma sx px) }}} But that still results in the same error. Adding `AllowAmbiguousTypes` doesn't help either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 18:54:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 18:54:28 -0000 Subject: [GHC] #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.bb21ffeb9bb9b73631a7cd99301123dd@haskell.org> #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Replying to [comment:17 harendra]: > The combination of `-fexpose-all-unfoldings` and `-fspecialise- aggressively` is not "exactly" equivalent to putting everything in the same module. O1 with everything in the same module finishes in 8ms while with the combination of these two finishes in 4ms. So they do something more. I guess the added effect is that they make everything INLINEABLE. Yep, forgot that bit. That's exactly what I use the two options for: to be able to split things among modules and to avoid INLINEABLE for every polymorphic function. With this, I only ever need an occasional INLINE in random places, but then it's not for specialization, but real inlining. > When everything is in the same module and `toList` marked NOINLINE then it takes 14ms (i.e. the worst case) irrespective of the monoid functions being marked INLINE or not. And what if they are marked NOINLINE? In any case, that means we now have an example of failed fusion that fits in one module. And additionally, we know that GHC can effectively generate such an example from innocently looking set of modules, by automatically inlining too much (or not enough). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 19:27:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 19:27:18 -0000 Subject: [GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" In-Reply-To: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> References: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> Message-ID: <062.1d694e451a68c176ec89cf50a2ff883f@haskell.org> #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): Some notes on exceptions so far: Given code like: {{{ data T = A | B | C | D f :: T -> T -> Int f A A = 1 f B A = 2 f C A = 3 f2 :: T -> T -> Int f2 A A = 1 f2 A B = 2 f2 A C = 3 }}} Ideally I would like to generate the same code for both variants. Check the A column first and then switch on the ABC column reducing the number of case statements. == The theory works out so far. For `f x A` with x = [ABC] we get a number out either way so that is fine. For `f (raisesException1) (raisesException2)` we get different exceptions depending on order of matching. If we break down the matching into case statements as defined in the Haskell Report and apply imprecise exceptions the implementation can choose either exception so this is somewhat ok too. For `f D (raisesException2)` the result is the Exception Set for (error "No Match") currently, changing to the union of (raisesException + error "No Match") if we change the order of evaluation. In theory that is ok. `error x` and undefined are both ⊥ according to the Haskell Report. So the result is the set of all exceptions either way. If we start with the first argument that is because error is equal to the set of all exceptions. If we check the second first we do the "execute all alternatives in exception mode" thing giving the same result as it comes across `error "No Match"` == Are there practical Problems with this approach? The theory only works for all cases if we treat `error` as non termination. With `PatternMatchFail` and `ErrorCall` one can easily distinguish these in practice. Catching failing pattern matches by default seems insane to me so I don't think returning another exception instead of MatchFail should break much that wasn't broken to begin with. Especially given that it only matters if another strict argument raises an exception first. While I can come up with a theoretical scenario where someone ends up with `f (raisesLaterCatchedException) (causesMatchFailure)` where changing the order would break the code personally I don't think that edge case is worth keeping. It depended on an implementation detail in the first place. Is unlikely to occur and when it happens easy to fix. But still I would like some feedback to judge if I underestimate the implications. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 21:19:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 21:19:46 -0000 Subject: [GHC] #14140: Better treatment for dataToTag In-Reply-To: <046.9a79626424ac111932e061637da60868@haskell.org> References: <046.9a79626424ac111932e061637da60868@haskell.org> Message-ID: <061.d1c7ca6888099d0a0f37a555dfec7fb5@haskell.org> #14140: Better treatment for dataToTag -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3934 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"0ebc8dc3525ddaa04a0c9e4c0c1aef70fd3fe725/ghc" 0ebc8dc3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0ebc8dc3525ddaa04a0c9e4c0c1aef70fd3fe725" Add a test for #14140 This issue seems to have been fixed by 193664d42dbceadaa1e4689dfa17ff1cf5a405a0 (Re-engineer caseRules to add tagToEnum/dataToTag) but I don't think anyone realized that. Reviewers: simonpj, austin, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #14140 Differential Revision: https://phabricator.haskell.org/D3934 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 21:31:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 21:31:37 -0000 Subject: [GHC] #14140: Better treatment for dataToTag In-Reply-To: <046.9a79626424ac111932e061637da60868@haskell.org> References: <046.9a79626424ac111932e061637da60868@haskell.org> Message-ID: <061.70198de48e804d88e05a43654504d2d5@haskell.org> #14140: Better treatment for dataToTag -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3934 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => closed * failure: None/Unknown => Runtime performance bug * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 21:40:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 21:40:36 -0000 Subject: [GHC] #14223: Casts get in the way of join points Message-ID: <046.c643afeaab71d296b8e8a944c5db87b5@haskell.org> #14223: Casts get in the way of join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was checking which of HLint’s rewirte rules are actually already known to the compiler in the sense that the simplifier can do them (using [ghc- proofs](http://hackage.haskell.org/package/ghc-proofs). I stumbled on this interesting case. `foldr @[] (&&) True xs` compiles down to this nice core {{{ joinrec { go [Occ=LoopBreaker] :: [Bool] -> Bool [LclId[JoinId(1)], Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [30] 44 20}] go (ds :: [Bool]) = case ds of { [] -> GHC.Types.True; : y ys -> case y of { False -> GHC.Types.False; True -> jump go ys } }; } in jump go xs }}} But `and @[] xs` (which HLint suggests to use instead, and we surely want people to use!) compiles down to {{{ go [Occ=LoopBreaker] :: [Bool] -> All [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [30] 60 20}] go = \ (ds :: [Bool]) -> case ds of { [] -> GHC.Types.True `cast` (Sym Data.Monoid.N:All[0] :: Coercible Bool All); : y ys -> case y of { False -> GHC.Types.False `cast` (Nth:3 (Nth:3 ((Sym Data.Monoid.N:All[0] -> Sym Data.Monoid.N:All[0] -> _R) ; (_R -> _R -> Sym Data.Monoid.N:All[0]))) :: Coercible Bool All); True -> go ys } }; } in (go xs) `cast` (Data.Monoid.N:All[0] :: Coercible All Bool) }}} If you squint and ignore all the casts, these two expressions are the same. So it would be very desirable to get a `joinrec` for `and xs` as well. Note that all “exit paths” of the return function cast from `Bool` to `All`, and the return value of the whole recursion casts back. That looks as if some smart floating of coercions could do the job. Maybe the common context transformation (https://mail.haskell.org/pipermail/ghc- devs/2013-December/003481.html)? Is this tied to GHC’s deviation of the paper to have a fixed return type for a join point? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 22:00:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 22:00:33 -0000 Subject: [GHC] #14223: Casts get in the way of join points In-Reply-To: <046.c643afeaab71d296b8e8a944c5db87b5@haskell.org> References: <046.c643afeaab71d296b8e8a944c5db87b5@haskell.org> Message-ID: <061.54512489a2ae4f8271b7ece22975ec10@haskell.org> #14223: Casts get in the way of join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Hmm. IF you float the `letrec go` inside the cast you'd get {{{ (letrec go = ... in go xs) |> blah }}} Now `go` is indeed a join point, and will be turned into a join point. And then the `|> blah` continuation will move into its RHS (becuase it's a join point). So really it should work fine right now. I wonder why that does not happen? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 22:01:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 22:01:12 -0000 Subject: [GHC] #14223: Casts get in the way of join points In-Reply-To: <046.c643afeaab71d296b8e8a944c5db87b5@haskell.org> References: <046.c643afeaab71d296b8e8a944c5db87b5@haskell.org> Message-ID: <061.8ad6e021fe66353a946d776618c885fd@haskell.org> #14223: Casts get in the way of join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Oh, wait, does loopification solve this? Let’s see. We start with {{{ letrec go :: [Bool] -> All go = \ (ds :: [Bool]) -> case ds of { [] -> GHC.Types.True `cast` (… :: Coercible Bool All) : y ys -> if y then go ys else GHC.Types.False `cast` (… :: Coercible Bool All) in (go xs) `cast` (… :: Coercible All Bool) }}} and loopify: {{{ let go :: [Bool] -> All go = \ (ds :: [Bool]) -> joinrec j :: [Bool] -> All j = \ds -> case ds of { [] -> GHC.Types.True `cast` (… :: Coercible Bool All) : y ys -> if y then jump j ys else GHC.Types.False `cast` (… :: Coercible Bool All) in jump j xs in (go xs) `cast` (… :: Coercible All Bool) }}} What now? Maybe `go` will inline: {{{ ( joinrec j :: [Bool] -> All j = \ds -> case ds of { [] -> GHC.Types.True `cast` (… :: Coercible Bool All) : y ys -> if y then jump j ys else GHC.Types.False `cast` (… :: Coercible Bool All) in jump j xs ) `cast` (… :: Coercible All Bool) }}} And surely there is a “`cast`-of-`joinrec`” transformation, right? Then we’ll get {{{ joinrec j :: [Bool] -> All j = \ds -> case ds of { [] -> GHC.Types.True `cast` (… :: Coercible Bool All) `cast` (… :: Coercible All Bool) : y ys -> if y then jump j ys else GHC.Types.False `cast` (… :: Coercible Bool All) `cast` (… :: Coercible All Bool) in jump j xs }}} and we can cancel the casts and get {{{ joinrec j :: [Bool] -> All j = \ds -> case ds of { [] -> GHC.Types.True : y ys -> if y then call j ys else GHC.Types.False in jump j xs }}} and all is well. So maybe #14068 is enough. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 22:04:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 22:04:58 -0000 Subject: [GHC] #14223: Casts get in the way of join points In-Reply-To: <046.c643afeaab71d296b8e8a944c5db87b5@haskell.org> References: <046.c643afeaab71d296b8e8a944c5db87b5@haskell.org> Message-ID: <061.7de5e5548030410cb0008909f0cec8a5@haskell.org> #14223: Casts get in the way of join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > IF you float the letrec `go` inside the cast you'd get With the stand-alone example {{{ module T14223 where foo :: [Bool] -> Bool foo xs = and xs }}} the `go` becomes top-level, so maybe that’s why? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 22:17:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 22:17:38 -0000 Subject: [GHC] #14223: Casts get in the way of join points In-Reply-To: <046.c643afeaab71d296b8e8a944c5db87b5@haskell.org> References: <046.c643afeaab71d296b8e8a944c5db87b5@haskell.org> Message-ID: <061.968c105c8f6fe38b85b22def46b1746f@haskell.org> #14223: Casts get in the way of join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > the go becomes top-level, so maybe that’s why? But then it wouldn't be a join point even if there was no cast. And comment:2 seems to be about a non-top-level letrec -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 22:26:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 22:26:30 -0000 Subject: [GHC] #14224: zipWith does not inline Message-ID: <045.ed8abb37df246f8ea9c4fff482d8cd1e@haskell.org> #14224: zipWith does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core | Version: 8.2.1 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: -------------------------------------+------------------------------------- `zipWith` is currently defined {{{#!hs zipWith :: (a->b->c) -> [a]->[b]->[c] zipWith _f [] _bs = [] zipWith _f _as [] = [] zipWith f (a:as) (b:bs) = f a b : zipWith f as bs }}} For now (I gather that might change soon?), the fact that it's recursive means that it will never inline. But we really want it to inline when applied to a function, for the same reasons we want `map` to inline. If `f` is something like `const`, `flip const`, or a lazy constructor, it's wasteful to create a thunk to apply it. All three of those cases are common. So unless/until we start inlining recursive functions, we probably want to use {{{#!hs zipWith f = go where go [] _ = [] go _ [] = [] go (x:xs) (y:ys) = f x y : go xs ys }}} There will probably be some regressions, of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 23:32:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 23:32:56 -0000 Subject: [GHC] #14223: Casts get in the way of join points In-Reply-To: <046.c643afeaab71d296b8e8a944c5db87b5@haskell.org> References: <046.c643afeaab71d296b8e8a944c5db87b5@haskell.org> Message-ID: <061.dd66fcc681f8b01295d6f7366e6f0cc9@haskell.org> #14223: Casts get in the way of join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): comment:2 would apply to a non-exported top-level thing just the same: Loopification works on the top level as well, and then `go` can potentially be inlined. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 23:35:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 23:35:17 -0000 Subject: [GHC] #14224: zipWith does not inline In-Reply-To: <045.ed8abb37df246f8ea9c4fff482d8cd1e@haskell.org> References: <045.ed8abb37df246f8ea9c4fff482d8cd1e@haskell.org> Message-ID: <060.4e03f637595d63eefb747b70f3e62aba@haskell.org> #14224: zipWith does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | 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 nomeata): Loopification in the current planned form does not apply here (zipWith is not tail-recursive), so if that is what you referring to: It won’t help here. The proposed form looks reasonable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 12 23:46:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Sep 2017 23:46:08 -0000 Subject: [GHC] #14217: Interface-file decls for large tuples In-Reply-To: <047.bf95f3f7deae12cdefb07151e87149c3@haskell.org> References: <047.bf95f3f7deae12cdefb07151e87149c3@haskell.org> Message-ID: <062.f8fb46e184f81429690efae0ee3e3893@haskell.org> #14217: Interface-file decls for large tuples -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) Comment: This regression first emerged in commit 15b9bf4ba4ab47e6809bf2b3b36ec16e502aea72 (`Improve typechecking of let- bindings`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 04:17:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 04:17:18 -0000 Subject: [GHC] #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.9cb338d6f9244af3bc6020b959a27f04@haskell.org> #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): Thanks Matthew, that post is a good reference and it confirmed a few things I was guessing about. Some of this can perhaps go into the GHC manual. Mikolaj, there is no difference when the Monoid instance functions are also marked NOINLINE in addition to `toList`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 07:17:09 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 07:17:09 -0000 Subject: [GHC] #14223: Casts get in the way of join points In-Reply-To: <046.c643afeaab71d296b8e8a944c5db87b5@haskell.org> References: <046.c643afeaab71d296b8e8a944c5db87b5@haskell.org> Message-ID: <061.eb7770a738f16665cf4335b5db289c74@haskell.org> #14223: Casts get in the way of join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Loopification works on the top level as well, and then go can potentially be inlined Ok but only if it's small. Perhaps float-in should be quite aggressive and float even top-level bindings inward (albeit perhaps not through a a lambda): {{{ rec f = ..f... nonrec h = ..f.. === nonrec h = ...(letrec f = ...f... in f)... }}} That would do the job here. Then maybe the final float-out pass can be a bit mor eager about floating things to top level -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 12:03:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 12:03:27 -0000 Subject: [GHC] #14129: GHC segfaults trying to use ANN code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.348618562e66743b0480359855424811@haskell.org> References: <044.348618562e66743b0480359855424811@haskell.org> Message-ID: <059.de8180e025a218efe68f5e0bda83d9cc@haskell.org> #14129: GHC segfaults trying to use ANN code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.4.1 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: #14115 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * cc: Jaffacake (added) * resolution: => duplicate * related: => #14115 Comment: I just noticed that this is very likely a duplicate of #14115; I was actually thinking these were the same ticket for the last several days. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 12:44:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 12:44:55 -0000 Subject: [GHC] #14129: GHC segfaults trying to use ANN code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.348618562e66743b0480359855424811@haskell.org> References: <044.348618562e66743b0480359855424811@haskell.org> Message-ID: <059.84245d3347aea0628581439fa043b764@haskell.org> #14129: GHC segfaults trying to use ANN code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.4.1 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: #14115 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): Maybe. I'm not 100% sure how ANN is implemented internally, people on #ghc suggested to submit all individual segfaults I can achieve. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 12:51:20 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 12:51:20 -0000 Subject: [GHC] #14197: Flag "dump-rn-ast" only dumps the declarations, not the whole RenamedSource In-Reply-To: <044.cc22bc6c087d1948925080ce049a8ac5@haskell.org> References: <044.cc22bc6c087d1948925080ce049a8ac5@haskell.org> Message-ID: <059.b7563a00018fc51eed4b418dbbb5ac28@haskell.org> #14197: Flag "dump-rn-ast" only dumps the declarations, not the whole RenamedSource -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch 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): Phab:D3949 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch * differential: => Phab:D3949 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 13:44:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 13:44:27 -0000 Subject: [GHC] #14204: GHC bug - makeStatic: Unresolved static form at line 13, column 14. In-Reply-To: <044.608ae49365e437b7204c6823db40398f@haskell.org> References: <044.608ae49365e437b7204c6823db40398f@haskell.org> Message-ID: <059.86ad1e80572459a01de3401db90f6e23@haskell.org> #14204: GHC bug - makeStatic: Unresolved static form at line 13, column 14. -------------------------------------+------------------------------------- Reporter: jchia | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3931 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"9ff9c35895ecc072f289c93addd1faad884bf122/ghc" 9ff9c35/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9ff9c35895ecc072f289c93addd1faad884bf122" Check if -XStaticPointers is enabled when renaming static expressions Summary: Trying to use `static` expressions without the `-XStaticPointers` extension enabled can lead to runtime errors. Normally, such a situation isn't possible, but Template Haskell provides a backdoor that allows it to happen, as shown in #14204. To prevent this, we ensure that `-XStaticPointers` is enabled when renaming `static` expressions. Test Plan: make test TEST=T14204 Reviewers: facundominguez, austin, bgamari, simonpj Reviewed By: facundominguez, simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #14204 Differential Revision: https://phabricator.haskell.org/D3931 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 13:44:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 13:44:27 -0000 Subject: [GHC] #14209: GHC 8.2.1 regression involving telescoping kind signature In-Reply-To: <050.d6ff01fd86ce7c8b5a28dc0adb6995b9@haskell.org> References: <050.d6ff01fd86ce7c8b5a28dc0adb6995b9@haskell.org> Message-ID: <065.4def78f07a9cfba087200697a0b8545b@haskell.org> #14209: GHC 8.2.1 regression involving telescoping kind signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 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: #13738 | Differential Rev(s): Phab:D3936 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"dafa0128950a6b18d79818881b3eeb6dc5c855b4/ghc" dafa0128/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dafa0128950a6b18d79818881b3eeb6dc5c855b4" Add regression test for #14209 Summary: Commit 0257dacf228024d0cc6ba247c707130637a25580 (`Refactor bindHsQTyVars and friends`) ended up fixing #14209. Let's add a regression test so that it stays fixed. Test Plan: make test TEST=T14209 Reviewers: austin, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14209 Differential Revision: https://phabricator.haskell.org/D3936 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 13:46:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 13:46:03 -0000 Subject: [GHC] #14204: GHC bug - makeStatic: Unresolved static form at line 13, column 14. In-Reply-To: <044.608ae49365e437b7204c6823db40398f@haskell.org> References: <044.608ae49365e437b7204c6823db40398f@haskell.org> Message-ID: <059.6033d99cd0e6fb8f134ffc923a170371@haskell.org> #14204: GHC bug - makeStatic: Unresolved static form at line 13, column 14. -------------------------------------+------------------------------------- Reporter: jchia | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Template Haskell | Version: 8.2.1 Resolution: fixed | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: th/T14204 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3931 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => th/T14204 * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 13:46:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 13:46:32 -0000 Subject: [GHC] #14209: GHC 8.2.1 regression involving telescoping kind signature In-Reply-To: <050.d6ff01fd86ce7c8b5a28dc0adb6995b9@haskell.org> References: <050.d6ff01fd86ce7c8b5a28dc0adb6995b9@haskell.org> Message-ID: <065.dbca737c46aecb699de4c99fd1d0da87@haskell.org> #14209: GHC 8.2.1 regression involving telescoping kind signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T14209 Blocked By: | Blocking: Related Tickets: #13738 | Differential Rev(s): Phab:D3936 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => polykinds/T14209 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 13:52:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 13:52:40 -0000 Subject: [GHC] #14225: "No module named ... is imported" message is a bit misleading with qualified imports Message-ID: <046.66ec7009ab5b4f5d3b72af6d147f4e53@haskell.org> #14225: "No module named ... is imported" message is a bit misleading with qualified imports -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems that the `No module named ... is imported` message produced in response to out-of-scope identifiers doesn't account for qualified imports. For instance, {{{ $ ghci GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ben/.ghci λ> import qualified Data.Maybe as M λ> M.fromJusr :2:1: error: Not in scope: ‘M.fromJusr’ Perhaps you meant ‘M.fromJust’ (imported from Data.Maybe) No module named ‘M’ is imported. λ> }}} I suppose there is the question of whether we consider `M` to be a "module" here; I would argue that I imported it and therefore the message is at very least a bit misleading. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 14:15:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 14:15:10 -0000 Subject: [GHC] #14223: Casts get in the way of join points In-Reply-To: <046.c643afeaab71d296b8e8a944c5db87b5@haskell.org> References: <046.c643afeaab71d296b8e8a944c5db87b5@haskell.org> Message-ID: <061.25edf571329b024dd6d42693ce7587d3@haskell.org> #14223: Casts get in the way of join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): BTW, https://ghc.haskell.org/trac/ghc/wiki/SequentCore should explain why casts are not considered tail-calls. Because they certainly look like tail-calls after type erasure… and if they were, this here would be a non- issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 14:25:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 14:25:21 -0000 Subject: [GHC] #14224: zipWith does not inline In-Reply-To: <045.ed8abb37df246f8ea9c4fff482d8cd1e@haskell.org> References: <045.ed8abb37df246f8ea9c4fff482d8cd1e@haskell.org> Message-ID: <060.ab6aec445c1bfd60cf68e8d94842428e@haskell.org> #14224: zipWith does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | 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 bgamari): I agree, separating out the recursive bit as proposed sounds quite reasonable. Would you care to offer a patch? It would be a good idea to mention this is the changelog of `base` while you are at it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 14:51:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 14:51:27 -0000 Subject: [GHC] #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc In-Reply-To: <049.42fb65c94c9d58534f92e7ad520e593b@haskell.org> References: <049.42fb65c94c9d58534f92e7ad520e593b@haskell.org> Message-ID: <064.350025b97767d9281ad7ece66025e386@haskell.org> #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13840, #13973, | Differential Rev(s): #14087 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): Maybe we should throw a type error when pattern name mismatch, rather than just panic. Use the case from #13973 as an example, {{{#!haskell -- Record.hs module Record (Record(..)) where data Record = Record { field1 :: Int, field2 :: Int } -- Test.hs module Test (foo) where import qualified Record as Rec field2 :: () field2 = () foo :: Rec.Record -> Int foo Rec.Record{field2 = field2} = field2 }}} In function `translateConPatVec` (in `compiler/deSugar/Check.hs`, during the desugar pass), we can't know whether the pattern label comes from the record fields, or just another ordinary symbol. When pattern name lookup (`lookup name zipped`) fails, **we could reach a conclusion** that `name` must not be one of the record fields. Then the compiler can throw an error like {{{ Test.hs:11:16: error: Record field not in scope: ‘field2’ Perhaps you meant one of these: ‘Rec.field1’ (imported from Record), ‘Rec.field2’ (imported from Record), }}} (Noticing that `Record field not in scope` has point out that the missing item is a record field label, rather than other ordinary variable, without causing any confusion.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 15:17:15 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 15:17:15 -0000 Subject: [GHC] #13115: missing data instances for IntPtr and WordPtr in base In-Reply-To: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> References: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> Message-ID: <060.c6e9162067ee7f23330f81db6a67efec@haskell.org> #13115: missing data instances for IntPtr and WordPtr in base -------------------------------------+------------------------------------- Reporter: carter | Owner: sighingnow Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3938 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"cbd491170818070aeb7edd8c547a2f0bfa891bf1/ghc" cbd4911/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cbd491170818070aeb7edd8c547a2f0bfa891bf1" Make IntPtr and WordPtr as instance of Data.Data typeclass, fix #13115 Test Plan: ./validate Reviewers: austin, hvr, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, thomie GHC Trac Issues: #13115 Differential Revision: https://phabricator.haskell.org/D3938 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 15:31:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 15:31:52 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks Message-ID: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (CodeGen) | 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 #14222 it was noted that something appears to be broken in `CmmCommonBlockElim`. Consider the program from that ticket, {{{#!hs module T14221 where import Data.Text as T isNumeric :: Text -> Bool isNumeric t = T.all isNumeric' t && T.any isNumber t where isNumber c = '0' <= c && c <= '9' isNumeric' c = isNumber c || c == 'e' || c == 'E' || c == '.' || c == '-' || c == '+' }}} This program produces six copies of a block of the form, {{{#!c c6JT: R2 = I64[R1 + 7]; R1 = P64[Sp + 8]; Sp = Sp + 16; call $wloop_all_s6CQ_info(R2, R1) args: 8, res: 0, upd: 8; }}} in the `-ddump-opt-cmm` output, which are manifest in the assembler as, {{{#!asm block_c6JT_info: _c6JT: movq 7(%rbx),%r14 movq 8(%rbp),%rbx addq $16,%rbp jmp $wloop_all_s6CQ_info }}} CBE really ought to be catching these. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 15:33:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 15:33:35 -0000 Subject: [GHC] #14222: Simple text fusion example results in rather duplicative code In-Reply-To: <046.acf3e774499e29f098fdca7495f195f8@haskell.org> References: <046.acf3e774499e29f098fdca7495f195f8@haskell.org> Message-ID: <061.5d5cba440477a24f5806bf5dd148f8e4@haskell.org> #14222: Simple text fusion example results in rather duplicative code -------------------------------------+------------------------------------- Reporter: bgamari | 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 bgamari): Replying to [comment:2 nomeata]: > Shouldn’t the common block elimination on the CMM level take care of that kind of duplication? Indeed I would have thought so but that is not what I observe. Initially I thought the problem was that the blocks differed in their source note ticks (which arise through unfoldings since I'm using the DWARF-enabled 8.2.1 binary distribution). I suspect that CBE (and indeed perhaps CSE in Core and STG) should learn to deal properly with such ticks. However, after switching back to a non-DWARF-enabled 8.0.2 build I found that I could still easily spot duplicate blocks. For instance, with the program above I see six blocks of the form, {{{#!asm block_c6K1_info: _c6K1: movq 7(%rbx),%r14 movq 8(%rbp),%rbx addq $16,%rbp jmp $wloop_all_s6CQ_info }}} If these were common'd up then that would also allow for a number of additional blocks which are currently distinct to be themselves common'd up (assuming our CBE pass runs to a fixed point). All-in-all it looks like something is broken in CBE. I've opened #14226 to track this. After this is fixed I should also make sure that CBE isn't defeated by the presence of source notes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 15:46:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 15:46:14 -0000 Subject: [GHC] #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms (was: GHC.Stack.HasCallStack not compatible with ConstraintKinds) In-Reply-To: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> References: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> Message-ID: <058.a30a40fb8c03079954efe1534e2b5356@haskell.org> #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms -------------------------------------+------------------------------------- Reporter: ntc2 | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: gridaphobe, simonpj (added) Comment: Hmm, yes, this is an unfortunate consequence of the implementation of the `HasCallStack` implementation. I suspect we find the `C` dictionary in scope when we solve for `callStack`'s constraints in `f`. Consequently we just pass it as a whole to `callStack` and the special callstack solver logic is never invoked. I honestly don't know how best to avoid this, but it certainly suggests that the status quo is rather fragile. I fear this issue may be somewhat intrinsic in the implementation strategy. If this is case we should at very least make sure this wrinkle is well-documented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 15:55:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 15:55:10 -0000 Subject: [GHC] #14206: Add bit deposit and bit extraction primops In-Reply-To: <047.2543734720307265ea1bddd575e5fddb@haskell.org> References: <047.2543734720307265ea1bddd575e5fddb@haskell.org> Message-ID: <062.f1e2b7cd1d145c4f4ba64a4443c478fd@haskell.org> #14206: Add bit deposit and bit extraction primops -------------------------------------+------------------------------------- Reporter: newhoggy | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed, it would be great to have these operations available. newhoggy, are you interested in offering a patch? I would be happy to advise. Let me know via email or IRC if you want to chat. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 16:10:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 16:10:49 -0000 Subject: [GHC] #12822: Cleanup GHC verbosity flags In-Reply-To: <045.4d9fca09f9ab247dee7b220b1a06e9a9@haskell.org> References: <045.4d9fca09f9ab247dee7b220b1a06e9a9@haskell.org> Message-ID: <060.60107c2ea15756de2735a70f0ea60453@haskell.org> #12822: Cleanup GHC verbosity flags -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | newcomer,flags 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): Let's discuss a concrete proposal before discussing implementation strategy. Which of the two parts listed in the ticket description would you like to take up? Both? If so, what concrete renaming are you proposing? For how long of a deprecation window do we want to keep the current flags around? Changes like these tend to inflict a small amount of pain on a lot of users for a long time, so I think we should be careful and deliberate in approaching this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 16:34:01 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 16:34:01 -0000 Subject: [GHC] #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms In-Reply-To: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> References: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> Message-ID: <058.efe9f42fa412268ced12e1e4db85a67b@haskell.org> #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms -------------------------------------+------------------------------------- Reporter: ntc2 | 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 gridaphobe): Oh dear.. Ben's explanation sounds plausible to me, though I didn't realize constraint synonyms worked this way. I would have expected them to be transparent to GHC like regular type synonyms, i.e. the `C` constraint would be expanded and we'd get two separate dictionaries rather than a compound dictionary. If this is actually how constraint synonyms work, a simple fix could be to expand them and treat the member constraints individually. But maybe there's a good reason for the current behavior? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 16:39:56 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 16:39:56 -0000 Subject: [GHC] #13115: missing data instances for IntPtr and WordPtr in base In-Reply-To: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> References: <045.3c03f12b026257b524097d2c4203ebdf@haskell.org> Message-ID: <060.c850414b9a70a268cc360bd3816ca9d1@haskell.org> #13115: missing data instances for IntPtr and WordPtr in base -------------------------------------+------------------------------------- Reporter: carter | Owner: sighingnow Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3938 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 16:42:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 16:42:40 -0000 Subject: [GHC] #14129: GHC segfaults trying to use ANN code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.348618562e66743b0480359855424811@haskell.org> References: <044.348618562e66743b0480359855424811@haskell.org> Message-ID: <059.348ae34f71b4d201003385e593eefec3@haskell.org> #14129: GHC segfaults trying to use ANN code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.4.1 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: #14115 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Don't worry, you absolutely did the right thing by opening separate tickets. However, my current thinking strongly leans towards these being the same issue as both `ANN` and TH use the interpreter, which seems to be failing here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 16:45:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 16:45:13 -0000 Subject: [GHC] #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms In-Reply-To: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> References: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> Message-ID: <058.873f3cbfb01ba0d793f420e71f1e5f11@haskell.org> #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms -------------------------------------+------------------------------------- Reporter: ntc2 | 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 bgamari): > Ben's explanation sounds plausible to me, though I didn't realize constraint synonyms worked this way. I actually didn't realize it either until I looked at the tc-trace output. I also don't know whether there is a good reason (other than efficiency) why they *must* be implemented this way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 16:46:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 16:46:47 -0000 Subject: [GHC] #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. In-Reply-To: <054.2188bb19676a701eab2890d90541afc2@haskell.org> References: <054.2188bb19676a701eab2890d90541afc2@haskell.org> Message-ID: <069.e74ab13bfc09501ce5adf3854574a8c1@haskell.org> #8532: Hyperbolic arc cosine fails on (-1) :: Complex r. -------------------------------------+------------------------------------- Reporter: leftaroundabout | Owner: alekzcb Type: bug | Status: closed Priority: low | Milestone: 8.4.1 Component: Core Libraries | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: numrun016 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3916 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 16:49:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 16:49:47 -0000 Subject: [GHC] #14202: Haskell Admin install In-Reply-To: <049.db61b4c513e7fe95e1a2fd966f773248@haskell.org> References: <049.db61b4c513e7fe95e1a2fd966f773248@haskell.org> Message-ID: <064.aa006755bd4b092bde4940f7fa111496@haskell.org> #14202: Haskell Admin install ----------------------------------+-------------------------------------- Reporter: acraig4csc | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid Comment: I'm afraid I don't know off hand. This is a packaging issue which you would probably be better off bringing up with the Stack maintainers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 17:03:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 17:03:05 -0000 Subject: [GHC] #14197: Flag "dump-rn-ast" only dumps the declarations, not the whole RenamedSource In-Reply-To: <044.cc22bc6c087d1948925080ce049a8ac5@haskell.org> References: <044.cc22bc6c087d1948925080ce049a8ac5@haskell.org> Message-ID: <059.076a1c3ad7844ce5289e46b9774f15b6@haskell.org> #14197: Flag "dump-rn-ast" only dumps the declarations, not the whole RenamedSource -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3949 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * milestone: => 8.2.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 17:05:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 17:05:12 -0000 Subject: [GHC] #14189: Renamer does not preserve location for IEThingWith list items In-Reply-To: <044.0c99d438de6c1244d5aee79758fc528d@haskell.org> References: <044.0c99d438de6c1244d5aee79758fc528d@haskell.org> Message-ID: <059.032cf6dbce54cfb0b30f9ff0ff02c477@haskell.org> #14189: Renamer does not preserve location for IEThingWith list items -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * milestone: => 8.2.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 17:38:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 17:38:05 -0000 Subject: [GHC] #14227: Add -fdefer-ffi-errors flag Message-ID: <048.d425d7353a8d9d520ea0edf2dab3c26a@haskell.org> #14227: Add -fdefer-ffi-errors flag -------------------------------------+------------------------------------- Reporter: tysonzero | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently when I do: {{{#!hs foreign import javascript unsafe "foo()" foo :: IO () }}} I understandably get: {{{ • The `javascript' calling convention is unsupported on this platform • When checking declaration: foreign import javascript unsafe "static foo()" foo :: IO () }}} However when I am developing with GHCJS I still want to use all my typical GHC tooling, a lot of which is not supported on GHCJS. So I need GHC to be able to compile my code even though I don't actually run it, currently I often have to do: {{{#!hs #ifdef __GHCJS__ foreign import javascript unsafe "foo()" foo :: IO () #else foo :: IO () foo = error "GHCJS required to use foo" #endif }}} Which is really noisy and annoying code to write, and it also does not help me with compiling external library code that does not do the above. It also pins me specifically to GHCJS and any future compiler that supports JS to any degree will need the code changed. The easiest solution to the problem seems to me to be a `-fdefer-ffi- errors` flag which replaces any unsupported ffi declaration with a runtime `error` call that gives a similar error message to the one currently given at compile time. I would also like a `-fdefer-ffi-errors-no-warn` flag to avoid my tooling complaining / emitting a bunch of warnings that don't actually help me much. This is not a very exciting request, but it would be a huge quality of life improvement for front end Haskell web development, and it does not seem overly difficult or dangerous to implement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 17:52:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 17:52:46 -0000 Subject: [GHC] #14197: Flag "dump-rn-ast" only dumps the declarations, not the whole RenamedSource In-Reply-To: <044.cc22bc6c087d1948925080ce049a8ac5@haskell.org> References: <044.cc22bc6c087d1948925080ce049a8ac5@haskell.org> Message-ID: <059.e63f155c92cdba87382e20b70a405ad4@haskell.org> #14197: Flag "dump-rn-ast" only dumps the declarations, not the whole RenamedSource -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3949 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"2fe6f6baba70de071c391bccc77197ab4f81064d/ghc" 2fe6f6b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2fe6f6baba70de071c391bccc77197ab4f81064d" Option "-ddump-rn-ast" dumps imports and exports too Summary: Previously the renamed source decls only were dumped, now the imports, exports and doc_hdr are too. Test Plan: ./validate Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14197 Differential Revision: https://phabricator.haskell.org/D3949 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 18:54:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 18:54:36 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks In-Reply-To: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> References: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> Message-ID: <061.465916deda4a54dd781536e8f577e1db@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (CodeGen) | Resolution: | Keywords: 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: > In #14222 it was noted that something appears to be broken in > `CmmCommonBlockElim`. Consider the program from that ticket, > {{{#!hs > module T14221 where > > import Data.Text as T > > isNumeric :: Text -> Bool > isNumeric t = > T.all isNumeric' t && T.any isNumber t > where > isNumber c = '0' <= c && c <= '9' > isNumeric' c = isNumber c > || c == 'e' > || c == 'E' > || c == '.' > || c == '-' > || c == '+' > }}} > This program produces six copies of a block of the form, > {{{#!c > c6JT: > R2 = I64[R1 + 7]; > R1 = P64[Sp + 8]; > Sp = Sp + 16; > call $wloop_all_s6CQ_info(R2, R1) args: 8, res: 0, upd: 8; > }}} > in the `-ddump-opt-cmm` output, which are manifest in the assembler as, > {{{#!asm > block_c6JT_info: > _c6JT: > movq 7(%rbx),%r14 > movq 8(%rbp),%rbx > addq $16,%rbp > jmp $wloop_all_s6CQ_info > }}} > > CBE really ought to be catching these. New description: In #14222 it was noted that something appears to be broken in `CmmCommonBlockElim`. Consider the program from that ticket, {{{#!hs module T14221 where import Data.Text as T isNumeric :: Text -> Bool isNumeric t = T.all isNumeric' t && T.any isNumber t where isNumber c = '0' <= c && c <= '9' isNumeric' c = isNumber c || c == 'e' || c == 'E' || c == '.' || c == '-' || c == '+' }}} This program produces six copies of a block of the form, {{{ c6JT: R2 = I64[R1 + 7]; R1 = P64[Sp + 8]; Sp = Sp + 16; call $wloop_all_s6CQ_info(R2, R1) args: 8, res: 0, upd: 8; }}} in the `-ddump-opt-cmm` output, which are manifest in the assembler as, {{{#!asm block_c6JT_info: _c6JT: movq 7(%rbx),%r14 movq 8(%rbp),%rbx addq $16,%rbp jmp $wloop_all_s6CQ_info }}} CBE really ought to be catching these. -- Comment (by bgamari): I had a quick look at this; it turns out that the reason that CBE doesn't work is 73f836f5d57a3106029b573c42f83d2039d21d89, which modifies the hash function to include local registers. This may sound familiar to you, nomeata, as you wrote it to address #10397. Sadly this means that our ability to CBE is quite limited. It seems like we should likely revisit this decision. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 18:55:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 18:55:51 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.02fe4180949e147cde7c62780f74e049@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: performance Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: see ticket Blocked By: | Blocking: Related Tickets: #14226 | Differential Rev(s): Phab:D892 Wiki Page: | Phab:D896 -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #14226 Comment: Unfortunately the commit from comment:28 severely reduces our ability to CBE. To call it "broken" may be a bit strong, but it's certainly a regression, which I am tracking as #14226. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 20:02:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 20:02:28 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks In-Reply-To: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> References: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> Message-ID: <061.5c814aa8f15368cf4fd055c641b85c1c@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (CodeGen) | Resolution: | Keywords: Operating System: 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): Oh, actually, never mind. On further reflection I suppose CBE actually must look at local registers since they may be live across blocks. Indeed nomeata's patch was merely a change in the hash, which is an optimization, not a change in the behavior of the pass. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 20:33:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 20:33:05 -0000 Subject: [GHC] #14228: PatternSynonyms Non-exhaustive with UnboxedSums Message-ID: <045.20b2cde42b5eb75c44e10e92ba8e9b86@haskell.org> #14228: PatternSynonyms Non-exhaustive with UnboxedSums -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: UnboxedSum, | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following implementation of `Maybe` using UnboxedSums results in `Non- exhaustive patterns in case`: (`Failure.hs` file) {{{#!haskell {-# LANGUAGE UnboxedSums #-} {-# LANGUAGE PatternSynonyms #-} type Maybe' t = (# t | () #) pattern Just' :: a -> Maybe' a pattern Just' x = (# x | #) pattern Nothing' :: Maybe' a pattern Nothing' = (# | () #) foo x = case x of Nothing' -> putStrLn "nothing" Just' _ -> putStrLn "just" main = do putStrLn "Nothing'" foo Nothing' putStrLn "Just'" foo (Just' "hello") }}} When executed, it prints: {{{ Nothing' nothing Just' Failure: Failure.hs:10:20-29: Non-exhaustive patterns in case }}} Compiled with `ghc Failure.hs`. Please note that by removing the `pattern`s, and writting `foo` as following works as expected: {{{#!haskell foo x = case x of (# | () #) -> putStrLn "nothing" (# _ | #) -> putStrLn "just" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 20:54:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 20:54:39 -0000 Subject: [GHC] #14199: Document Type.Reflection better (Fun and Con') In-Reply-To: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> References: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> Message-ID: <060.f23818db3f255e751975e5adfc64ab3a@haskell.org> #14199: Document Type.Reflection better (Fun and Con') -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.2.2 Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3943 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f9bf621caf2fc17d829dee0ee48b204144927e72/ghc" f9bf621/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f9bf621caf2fc17d829dee0ee48b204144927e72" Better document TypeRep patterns As pointed out in #14199 these are rather non-trivial; extra documentation is in order. [skip ci] Test Plan: Read it Reviewers: dfeuer, austin, hvr Subscribers: rwbarton, thomie GHC Trac Issues: #14199 Differential Revision: https://phabricator.haskell.org/D3943 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 20:54:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 20:54:39 -0000 Subject: [GHC] #14213: Improve the documentation of seq function In-Reply-To: <043.053aa1ee2284ef7ad3446d36b517c5b3@haskell.org> References: <043.053aa1ee2284ef7ad3446d36b517c5b3@haskell.org> Message-ID: <058.ddc6dcd9f4bdf3294fd3e5b258817565@haskell.org> #14213: Improve the documentation of seq function -------------------------------------+------------------------------------- Reporter: sibi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | 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:D3945 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4e222203751e50e3c35815376090b2951bf7c9e0/ghc" 4e22220/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4e222203751e50e3c35815376090b2951bf7c9e0" Clarify seq documentation Improves the documentation by specifying that the first argument in seq function is evaluated to WHNF. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: harendra, rwbarton, thomie GHC Trac Issues: #14213 Differential Revision: https://phabricator.haskell.org/D3945 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 20:54:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 20:54:40 -0000 Subject: [GHC] #14171: STM causes program to suddenly exit In-Reply-To: <051.a861f285f45a631468bb590e6c9c6a19@haskell.org> References: <051.a861f285f45a631468bb590e6c9c6a19@haskell.org> Message-ID: <066.09c0238c45f249ebafa5c1861de4619c@haskell.org> #14171: STM causes program to suddenly exit ----------------------------------+---------------------------------------- Reporter: MichaelBurge | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: libraries/stm | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #8091 | Differential Rev(s): Phab:D3919 Wiki Page: | ----------------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"10a1a4781c646f81ca9e2ef7a2585df2cbe3a014/ghc" 10a1a47/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="10a1a4781c646f81ca9e2ef7a2585df2cbe3a014" Model divergence of retry# as ThrowsExn, not Diverges The demand signature of the retry# primop previously had a Diverges result. However, this caused the demand analyser to conclude that a program of the shape, catchRetry# (... >> retry#) would diverge. Of course, this is plainly wrong; catchRetry#'s sole reason to exist is to "catch" the "exception" thrown by retry#. While catchRetry#'s demand signature correctly had the ExnStr flag set on its first argument, indicating that it should catch divergence, the logic associated with this flag doesn't apply to Diverges results. This resulted in #14171. The solution here is to treat the divergence of retry# as an exception. Namely, give it a result type of ThrowsExn rather than Diverges. Updates stm submodule for tests. Test Plan: Validate with T14171 Reviewers: simonpj, austin Subscribers: rwbarton, thomie GHC Trac Issues: #14171, #8091 Differential Revision: https://phabricator.haskell.org/D3919 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 20:54:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 20:54:40 -0000 Subject: [GHC] #8091: retry# lacks strictness information In-Reply-To: <044.e7a925b8333c20ff7c4dfcee4bdadb24@haskell.org> References: <044.e7a925b8333c20ff7c4dfcee4bdadb24@haskell.org> Message-ID: <059.ed0eb4702c7db0e9dbbcf4ff6efbe878@haskell.org> #8091: retry# lacks strictness information -------------------------------------+------------------------------------- Reporter: parcs | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"10a1a4781c646f81ca9e2ef7a2585df2cbe3a014/ghc" 10a1a47/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="10a1a4781c646f81ca9e2ef7a2585df2cbe3a014" Model divergence of retry# as ThrowsExn, not Diverges The demand signature of the retry# primop previously had a Diverges result. However, this caused the demand analyser to conclude that a program of the shape, catchRetry# (... >> retry#) would diverge. Of course, this is plainly wrong; catchRetry#'s sole reason to exist is to "catch" the "exception" thrown by retry#. While catchRetry#'s demand signature correctly had the ExnStr flag set on its first argument, indicating that it should catch divergence, the logic associated with this flag doesn't apply to Diverges results. This resulted in #14171. The solution here is to treat the divergence of retry# as an exception. Namely, give it a result type of ThrowsExn rather than Diverges. Updates stm submodule for tests. Test Plan: Validate with T14171 Reviewers: simonpj, austin Subscribers: rwbarton, thomie GHC Trac Issues: #14171, #8091 Differential Revision: https://phabricator.haskell.org/D3919 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 20:55:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 20:55:46 -0000 Subject: [GHC] #14199: Document Type.Reflection better (Fun and Con') In-Reply-To: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> References: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> Message-ID: <060.e0ab819901cc7752056e0ee978b48c3f@haskell.org> #14199: Document Type.Reflection better (Fun and Con') -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: bug | Status: merge Priority: high | Milestone: 8.2.2 Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3943 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 20:56:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 20:56:05 -0000 Subject: [GHC] #14213: Improve the documentation of seq function In-Reply-To: <043.053aa1ee2284ef7ad3446d36b517c5b3@haskell.org> References: <043.053aa1ee2284ef7ad3446d36b517c5b3@haskell.org> Message-ID: <058.469f61f9226871a864fd14e025fe0b78@haskell.org> #14213: Improve the documentation of seq function -------------------------------------+------------------------------------- Reporter: sibi | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Documentation | 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:D3945 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 20:56:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 20:56:33 -0000 Subject: [GHC] #14171: STM causes program to suddenly exit In-Reply-To: <051.a861f285f45a631468bb590e6c9c6a19@haskell.org> References: <051.a861f285f45a631468bb590e6c9c6a19@haskell.org> Message-ID: <066.3b4420cfb1aa19d5e30a64e8827c4a22@haskell.org> #14171: STM causes program to suddenly exit ----------------------------------+---------------------------------------- Reporter: MichaelBurge | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: libraries/stm | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #8091 | Differential Rev(s): Phab:D3919 Wiki Page: | ----------------------------------+---------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 21:22:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 21:22:51 -0000 Subject: [GHC] #14229: Contraditions in users_guide/using-warnings.html Message-ID: <054.d6f9d16cc1b1fa988ffa9396c0d0581c@haskell.org> #14229: Contraditions in users_guide/using-warnings.html -------------------------------------+------------------------------------- Reporter: | Owner: (none) MikolajKonarski | Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Lists are not updated in https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using- warnings.html E.g., it says "The warnings that are not enabled by -Wall are ...-Wredundant-constraints", but then it says "This option is on by default". Also "-Worphans" is on none of the list of enabled or not enabled flags and also there is no mention in its description if its enabled by default or not. I guess there may be more. Also, it may be worth mentioning that obsolete warnings or warnings subsumed by others are not on any of the list, or whatever the actual rule is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 22:05:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 22:05:35 -0000 Subject: [GHC] #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) In-Reply-To: <044.09b34dc4c0e2fa3e606fc911e20d53ee@haskell.org> References: <044.09b34dc4c0e2fa3e606fc911e20d53ee@haskell.org> Message-ID: <059.d45763ef3b4671988aa8f9b9732d64c0@haskell.org> #14080: GHC panic while forcing the thunk for TyThing IsFile (regression) -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13803, #13981 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by _deepfire): Edward, this bug is marked `infoneeded`, which seems to put it in a dangerous category, but is it really warranted? Sorry for meddling, just another worried user stuck on this.. : -) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 22:49:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 22:49:46 -0000 Subject: [GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" In-Reply-To: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> References: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> Message-ID: <062.3ff74e65b883a1666014e2e1efa465ba@haskell.org> #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The assessment in comment:4 sounds pretty reasonable to me. I agree that there's little reason to lose sleep over the `f (raisesLaterCatchedException) (causesMatchFailure)` case; such code produce warnings under any production-worthy flag set and users will almost certainly understand that this sort of code is fragile. The `f (raisesException1) (raisesException2)` case is a tad more worrying since users may be mislead by the (change in the) resulting exception. However, as you point out, the Report does say that both exceptions are admissible and I don't think we should be shy about taking advantage of this freedom if there really is performance on the table. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 13 23:23:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Sep 2017 23:23:08 -0000 Subject: [GHC] #14228: PatternSynonyms Non-exhaustive with UnboxedSums In-Reply-To: <045.20b2cde42b5eb75c44e10e92ba8e9b86@haskell.org> References: <045.20b2cde42b5eb75c44e10e92ba8e9b86@haskell.org> Message-ID: <060.247bf63f701424529b923f5f2c655103@haskell.org> #14228: PatternSynonyms Non-exhaustive with UnboxedSums -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: UnboxedSums, | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: UnboxedSum, PatternSynonyms => UnboxedSums, PatternSynonyms Comment: Wow! Great catch. Indeed, the `ddump-simpl` output for that program looks mighty suspicious. I'll post an abridged version below: {{{#!hs -- RHS size: {terms: 14, types: 20, coercions: 0, joins: 0/0} $mJust' :: forall (r :: TYPE rep) a. Maybe' a -> (a -> r) -> (Void# -> r) -> r $mJust' = \ (@ (rep :: RuntimeRep)) (@ (r :: TYPE rep)) (@ a) (scrut :: Maybe' a) (cont :: a -> r) _ -> case scrut of { (#_|#) x -> cont x; (#|_#) ipv -> patError "Bug.hs:8:19-27|case"# } -- RHS size: {terms: 17, types: 21, coercions: 0, joins: 0/0} $mNothing' :: forall (r :: TYPE rep) a. Maybe' a -> (Void# -> r) -> (Void# -> r) -> r $mNothing' = \ (@ (rep :: RuntimeRep)) (@ (r :: TYPE rep)) (@ a) (scrut :: Maybe' a) (cont :: Void# -> r) _ -> case scrut of { (#_|#) ipv -> patError "Bug.hs:11:20-29|case"#; (#|_#) ds -> case ds of { () -> cont void# } } }}} Just //look// at that rubbish! The matchers for `Just'` and `Nothing'` each take a failure continuation as an argument, but appear to ignore them completely and just proceed directly to `patError` in case the expected pattern wasn't matched. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 00:20:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 00:20:51 -0000 Subject: [GHC] #14227: Add -fdefer-ffi-errors flag In-Reply-To: <048.d425d7353a8d9d520ea0edf2dab3c26a@haskell.org> References: <048.d425d7353a8d9d520ea0edf2dab3c26a@haskell.org> Message-ID: <063.ebc81badab07f3c6ce9e1ebd35d2678f@haskell.org> #14227: Add -fdefer-ffi-errors flag -------------------------------------+------------------------------------- Reporter: tysonzero | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > The easiest solution to the problem seems to me to be a `-fdefer-ffi- errors` flag which replaces any unsupported ffi declaration with a runtime error call that gives a similar error message to the one currently given at compile time. An interesting idea. I believe this wouldn't be too hard to implement; the relevant code can be found in `TcForeign.checkCConv`. > I would also like a `-fdefer-ffi-errors-no-warn` flag to avoid my tooling complaining / emitting a bunch of warnings that don't actually help me much. I think I would probably instead spell this `-Wno-deferred-ffi-errors` or similar. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 01:04:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 01:04:45 -0000 Subject: [GHC] #14228: PatternSynonyms Non-exhaustive with UnboxedSums In-Reply-To: <045.20b2cde42b5eb75c44e10e92ba8e9b86@haskell.org> References: <045.20b2cde42b5eb75c44e10e92ba8e9b86@haskell.org> Message-ID: <060.3d55cf6a6af1aeca01826b284f7a9455@haskell.org> #14228: PatternSynonyms Non-exhaustive with UnboxedSums -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: UnboxedSums, | PatternSynonyms 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:D3951 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3951 * milestone: => 8.2.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 01:56:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 01:56:01 -0000 Subject: [GHC] #11350: Allow visible type application in patterns In-Reply-To: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> References: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> Message-ID: <066.0d644e0fdff3abbde7564a2bae55cdd0@haskell.org> #11350: Allow visible type application in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11385, #13159, | Differential Rev(s): #13158 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by jeltsch): * cc: jeltsch (added) Comment: Visible type application in patterns would be ''extremely'' useful for implementing core transformations in the new version of the `incremental- computing` package. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 02:29:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 02:29:26 -0000 Subject: [GHC] #11649: LLVM code generator produces mal-formed LLVM blocks In-Reply-To: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> References: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> Message-ID: <061.9e781e16b41a913e3740a5f59a69eb84@haskell.org> #11649: LLVM code generator produces mal-formed LLVM blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: erikd Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9043 | Differential Rev(s): Phab:D1996 Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * cc: kavon, angerman (added) Comment: Yikes. This still seems to be the case with LLVM5. We should probably upstream a fix for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 09:12:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 09:12:29 -0000 Subject: [GHC] #14175: Panic repSplitTyConApp_maybe In-Reply-To: <045.2fc9be96fc161afbef29226fbd9e3b46@haskell.org> References: <045.2fc9be96fc161afbef29226fbd9e3b46@haskell.org> Message-ID: <060.e44766e72b79f72f326dcd5089368e1d@haskell.org> #14175: Panic repSplitTyConApp_maybe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.2.1 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: #13910 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"8bf865d3db69c6f4a09f3e5e3880c087c0a7c7f0/ghc" 8bf865d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8bf865d3db69c6f4a09f3e5e3880c087c0a7c7f0" Tidying could cause ill-kinded types I found (Trac #14175) that the tidying we do when reporting type error messages could cause a well-kinded type to become ill-kinded. Reason: we initialised the tidy-env with a completely un-zonked TidyEnv accumulated in the TcLclEnv as we come across lexical type-varialbe bindings. Solution: zonk them. But I ended up refactoring a bit: * Get rid of tcl_tidy :: TidyEnv altogether * Instead use tcl_bndrs :: TcBinderStack This used to contain only Ids, but now I've added those lexically scoped TyVars too. * Change names: TcIdBinderStack -> TcBinderStack TcIdBinder -> TcBinder extendTcIdBndrs -> extendTcBinderStack * Now tcInitTidyEnv can grab those TyVars from the tcl_bndrs, zonk, and tidy them. The only annoyance is that I had to add TcEnv.hs-boot, to break the recursion between the zonking code and the TrRnMonad functions like addErrTc that call tcInitTidyEnv. Tiresome, but in fact that file existed already. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 09:12:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 09:12:29 -0000 Subject: [GHC] #13910: Inlining a definition causes GHC to panic (repSplitTyConApp_maybe) In-Reply-To: <050.14bd55ba33332ff15d7c16c4f0c73fad@haskell.org> References: <050.14bd55ba33332ff15d7c16c4f0c73fad@haskell.org> Message-ID: <065.ada5f48eb206df889f88a1a96b88ce46@haskell.org> #13910: Inlining a definition causes GHC to panic (repSplitTyConApp_maybe) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: 14119 | Blocking: Related Tickets: #13877, #14038, | Differential Rev(s): #14175 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"9218ea60faa744803fb41066aedd1da8f1bd9185/ghc" 9218ea60/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9218ea60faa744803fb41066aedd1da8f1bd9185" Interim fix for a nasty type-matching bug The type matcher in types/Unify.hs was producing a substitution that had variables from the template in its range. Yikes! This patch, documented in Note [Matching in the presence of casts], is an interm fix. Richard and I don't like it much, and are pondering a better solution (Trac #14119). All this came up in investigating Trac #13910. Alas this patch doesn't fix #13910, which still has ASSERT failures, so I have not yet added a test. But the patch does fix a definite bug. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 09:12:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 09:12:29 -0000 Subject: [GHC] #14162: Core Lint error In-Reply-To: <051.8e77500e96b9b78e4c6419516988ffa1@haskell.org> References: <051.8e77500e96b9b78e4c6419516988ffa1@haskell.org> Message-ID: <066.1d79d51ad9bdd0e6301fbbd519112c13@haskell.org> #14162: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"3a27e34f7a59a30f91fad9dd2ca194acdb1bcb1a/ghc" 3a27e34/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3a27e34f7a59a30f91fad9dd2ca194acdb1bcb1a" Fix subtle bug in TcTyClsDecls.mkGADTVars This bug was revealed by Trac #14162. In a GADT-style data-family instance we ended up a data constructor whose type mentioned an out-of-scope variable. (This variable was in the kind of a variable in the kind of a variable.) Only Lint complained about this (actually only when the data constructor was injected into the bindings by CorePrep). So it doesn't matter much -- but it's a solid bug and might bite us some day. It took me quite a while to unravel because the test case was itself quite tricky. But the fix is easy; just add a missing binding to the substitution we are building up. It's in the regrettably-subtle mkGADTVars function. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 09:12:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 09:12:29 -0000 Subject: [GHC] #14119: Refactor type patterns In-Reply-To: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> References: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> Message-ID: <062.651e2b54a02890d35cba4124b3e83a9e@haskell.org> #14119: Refactor type patterns -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12564, 13910, | 13938, 14038 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"9218ea60faa744803fb41066aedd1da8f1bd9185/ghc" 9218ea60/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9218ea60faa744803fb41066aedd1da8f1bd9185" Interim fix for a nasty type-matching bug The type matcher in types/Unify.hs was producing a substitution that had variables from the template in its range. Yikes! This patch, documented in Note [Matching in the presence of casts], is an interm fix. Richard and I don't like it much, and are pondering a better solution (Trac #14119). All this came up in investigating Trac #13910. Alas this patch doesn't fix #13910, which still has ASSERT failures, so I have not yet added a test. But the patch does fix a definite bug. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 09:17:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 09:17:13 -0000 Subject: [GHC] #14175: Panic repSplitTyConApp_maybe In-Reply-To: <045.2fc9be96fc161afbef29226fbd9e3b46@haskell.org> References: <045.2fc9be96fc161afbef29226fbd9e3b46@haskell.org> Message-ID: <060.b2af3098a539d63642f28cc340d1f4a9@haskell.org> #14175: Panic repSplitTyConApp_maybe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 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: indexed- crash or panic | types/should_fail/T14175 Blocked By: | Blocking: Related Tickets: #13910 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed-types/should_fail/T14175 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 09:18:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 09:18:59 -0000 Subject: [GHC] #14162: Core Lint error In-Reply-To: <051.8e77500e96b9b78e4c6419516988ffa1@haskell.org> References: <051.8e77500e96b9b78e4c6419516988ffa1@haskell.org> Message-ID: <066.ee583ae400ff4b5efb831e802ad57f42@haskell.org> #14162: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T14162 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => indexed-types/should_compile/T14162 Comment: I believe this fix is also on Richards `wip/rae` branch. Worth merging to 8.2 I think, because it's a simple, local change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 09:19:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 09:19:08 -0000 Subject: [GHC] #14162: Core Lint error In-Reply-To: <051.8e77500e96b9b78e4c6419516988ffa1@haskell.org> References: <051.8e77500e96b9b78e4c6419516988ffa1@haskell.org> Message-ID: <066.1cf79fc490db53c24163d6ad32c1186c@haskell.org> #14162: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T14162 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: => 8.2.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 09:24:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 09:24:17 -0000 Subject: [GHC] #11350: Allow visible type application in patterns In-Reply-To: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> References: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> Message-ID: <066.20db3b7ff22df7809704a9afacf9cf4d@haskell.org> #11350: Allow visible type application in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11385, #13159, | Differential Rev(s): #13158 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Visible type application in patterns would be extremely useful for implementing core transformations in the new version of the incremental- computing package. Could you distil some motivating examples from your package? It's good to know it'd be useful, but better to be able to see the usefulness. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 11:33:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 11:33:03 -0000 Subject: [GHC] #14211: Compiler is unable to INLINE as well as the programmer can manually In-Reply-To: <047.2a53ecf1e57ab8268d4f765d1da08a61@haskell.org> References: <047.2a53ecf1e57ab8268d4f765d1da08a61@haskell.org> Message-ID: <062.47a79ca17b8ec0d0aba899e313482342@haskell.org> #14211: Compiler is unable to INLINE as well as the programmer can manually -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | StaticArgumentTransformation, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): There is a warning in core lint which warns about `INLINE` pragmas on loops breakers but I don't know why it is not on by default. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 11:41:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 11:41:05 -0000 Subject: [GHC] #14206: Add bit deposit and bit extraction primops In-Reply-To: <047.2543734720307265ea1bddd575e5fddb@haskell.org> References: <047.2543734720307265ea1bddd575e5fddb@haskell.org> Message-ID: <062.7bd63f69028f3732348e6b19f96c3524@haskell.org> #14206: Add bit deposit and bit extraction primops -------------------------------------+------------------------------------- Reporter: newhoggy | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by newhoggy: Old description: > Modern CPUs (on x86, Haswell and newer) have a PDEP instruction for > efficient bit deposit and a PEXT instruction for efficient bit > extraction. These instructions can be used to implement various data > structures. > > I propose we add the following set of primops > > {{{#!hs > pdep8# :: Word# -> Word# -> Word# > pdep16# :: Word# -> Word# -> Word# > pdep32# :: Word# -> Word# -> Word# > pdep64# :: Word64# -> Word64# -> Word64# > pdep# :: Word# -> Word# -> Word# > > pext8# :: Word# -> Word# -> Word# > pext16# :: Word# -> Word# -> Word# > pext32# :: Word# -> Word# -> Word# > pext64# :: Word64# -> Word64# -> Word64# > pext# :: Word# -> Word# -> Word# > }}} > > Each primop compiles into either a single PDEP/PEXT instruction or a call > to some fallback function, implemented in C. > > For reference, see the following library that implements FFI wrapper > 32-bit and 64-bit functions for these instructions: > > https://github.com/haskell-works/hw-prim-bits New description: Modern CPUs (on x86, Haswell and newer) have a PDEP instruction for efficient bit deposit and a PEXT instruction for efficient bit extraction. These instructions can be used to implement various data structures. I propose we add the following set of primops {{{#!hs pdep8# :: Word# -> Word# -> Word# pdep16# :: Word# -> Word# -> Word# pdep32# :: Word# -> Word# -> Word# pdep64# :: Word64# -> Word64# -> Word64# pdep# :: Word# -> Word# -> Word# pext8# :: Word# -> Word# -> Word# pext16# :: Word# -> Word# -> Word# pext32# :: Word# -> Word# -> Word# pext64# :: Word64# -> Word64# -> Word64# pext# :: Word# -> Word# -> Word# }}} Each primop compiles into either a single PDEP/PEXT instruction or a call to some fallback function, implemented in C. For reference, see the following library that implements FFI wrapper for 32-bit and 64-bit functions for these instructions: https://github.com/haskell-works/hw-prim-bits -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 12:43:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 12:43:48 -0000 Subject: [GHC] #14227: Add -fdefer-ffi-errors flag In-Reply-To: <048.d425d7353a8d9d520ea0edf2dab3c26a@haskell.org> References: <048.d425d7353a8d9d520ea0edf2dab3c26a@haskell.org> Message-ID: <063.a2e0fedaa6954cf265b8870e5b75c103@haskell.org> #14227: Add -fdefer-ffi-errors flag -------------------------------------+------------------------------------- Reporter: tysonzero | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Would be fine with me. It's a user-facing change, so worth running quickly through the [https://github.com/ghc-proposals/ghc-proposals GHC proposals process]. Should be fast! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 12:52:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 12:52:50 -0000 Subject: [GHC] #14223: Casts get in the way of join points In-Reply-To: <046.c643afeaab71d296b8e8a944c5db87b5@haskell.org> References: <046.c643afeaab71d296b8e8a944c5db87b5@haskell.org> Message-ID: <061.a266dcf51f653975046af8346ab921c5@haskell.org> #14223: Casts get in the way of join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Trouble is, the transformation that pushes continuations into join RHSs would become ill-typed. Consider {{{ case (join j x = e in case b of True -> j x |> g False -> r) of ALTS }}} Here we are allowing `j` as a join point, as proposed in comment:7. Now move that outer case inwards: {{{ join j x = case e of ALTS in case b of True -> j x False -> case r of ALTS }}} Alas, the two `(case . of ALTS)` are now scrutinising values of different types! You could say "just live with that" but I don't know what the consequences would be. Better, I think, to move the casts around somehow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 13:01:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 13:01:28 -0000 Subject: [GHC] #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc In-Reply-To: <049.42fb65c94c9d58534f92e7ad520e593b@haskell.org> References: <049.42fb65c94c9d58534f92e7ad520e593b@haskell.org> Message-ID: <064.82a5f216d69630983b5210ebdd7da5bc@haskell.org> #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13840, #13973, | Differential Rev(s): #14087 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: adamgundry (added) Comment: Adam, might you look at this, since it seems to be in ORF-land? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 13:02:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 13:02:36 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks In-Reply-To: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> References: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> Message-ID: <061.012e44bfef61bdd2bea04862f18dbb6d@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (CodeGen) | Resolution: | Keywords: Operating System: 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): OK, so now we are back to: why doesn't CBE eliminate the common blocks? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 13:18:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 13:18:25 -0000 Subject: [GHC] #14222: Simple text fusion example results in rather duplicative code In-Reply-To: <046.acf3e774499e29f098fdca7495f195f8@haskell.org> References: <046.acf3e774499e29f098fdca7495f195f8@haskell.org> Message-ID: <061.0173709ef0a0e560e1bd4eef827953b2@haskell.org> #14222: Simple text fusion example results in rather duplicative code -------------------------------------+------------------------------------- Reporter: bgamari | 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 simonpj): I agree that CBE should nail it, so let's do #14226. But still it'd be even better to do it in Core. As you'll see in `Note [Combine identical alternatives]` in `CoreUtils` we do some combining of identical alternatives, but only in the very convenient case where one of them is the DEFAULT, which is not the case here. I suppose we'd like {{{ case ww4_X2zB of __DEFAULT -> GHC.Types.False; '+'# -> jump $wloop_all_s2z2 (GHC.Prim.+# ww3_s2z0 2#); '-'# -> jump $wloop_all_s2z2 (GHC.Prim.+# ww3_s2z0 2#); '.'# -> jump $wloop_all_s2z2 (GHC.Prim.+# ww3_s2z0 2#); 'E'# -> jump $wloop_all_s2z2 (GHC.Prim.+# ww3_s2z0 2#); 'e'# -> jump $wloop_all_s2z2 (GHC.Prim.+# ww3_s2z0 2#) ===> join j = jump $wloop_all_s2z2 (GHC.Prim.+# ww3_s2z0 2#) in case ww4_X2zB of __DEFAULT -> GHC.Types.False; '+'# -> jump j '-'# -> jump j '.'# -> jump j 'E'# -> jump j 'e'# -> jump j }}} You could imagine trying that. It's a variant of something I've wanted to try for some time to get better CSE. Suppose we have {{{ f (x+y) (g (x+y)) }}} Currently we don't CSE the two `(x+y)` expressions. Suppose we did this: 1. Convert to ANF, by let-binding every sub-expression {{{ f (let a1 = x+y in a1) (let a2 = let a3 = x+y in g a3 in a2) }}} 2. Float out aggressively {{{ let a1 = x+y in let a3 = x+y in let a2 = g a3 in f a1 a2 }}} 3. Do CSE exactly as now {{{ let a1 = x+y in let a3 = a1 in let a2 = g a3 in f a1 a2 }}} 4. Now inline as usual {{{ let a1 = x+1 in f a1 (g a1) }}} which is what we want. I like this 4-step plan because only step 1 is new: the other passes exist already. It's a bit brutal but it would do the job. And (provided we did this for join-points too) it would nail the example nicely. Anyone want to have a go? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 13:20:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 13:20:04 -0000 Subject: [GHC] #14222: Simple text fusion example results in rather duplicative code In-Reply-To: <046.acf3e774499e29f098fdca7495f195f8@haskell.org> References: <046.acf3e774499e29f098fdca7495f195f8@haskell.org> Message-ID: <061.09d5d83cbf6022a8d24df54855fded3f@haskell.org> #14222: Simple text fusion example results in rather duplicative code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: CSE Operating System: 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: => CSE -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 13:31:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 13:31:16 -0000 Subject: [GHC] #14175: Panic repSplitTyConApp_maybe In-Reply-To: <045.2fc9be96fc161afbef29226fbd9e3b46@haskell.org> References: <045.2fc9be96fc161afbef29226fbd9e3b46@haskell.org> Message-ID: <060.a8d95c8aebe70e0edce897a220aede46@haskell.org> #14175: Panic repSplitTyConApp_maybe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 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: indexed- crash or panic | types/should_fail/T14175 Blocked By: | Blocking: Related Tickets: #13910 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): After this patch, GHC HEAD gives this error for the program in comment:2: {{{ Bug.hs:11:3: error: • Expected kind ‘(k -> *) -> (k -> *) -> *’, but ‘CD :: (k -> *) -> (k -> *) -> *’ has kind ‘Maybe a -> Maybe a -> *’ • In the data instance declaration for ‘CD’ In the instance declaration for ‘C (Maybe a)’ | 11 | data CD :: (k -> *) -> (k -> *) -> * | ^^^^^^^ }}} And this error for the program in comment:4: {{{ Bug.hs:13:3: error: • Expected kind ‘(k -> *) -> *’, but ‘CD k (a :: k -> *) :: (k -> *) -> *’ has kind ‘k -> *’ • In the data instance declaration for ‘CD’ In the instance declaration for ‘C (Maybe a)’ | 13 | data CD k (a :: k -> *) :: (k -> *) -> * | ^^^^^^^^^^^^^^^^^^^^^^^ }}} As you observed, these error messages aren't great and could likely be improved. Should I open a separate ticket for this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 13:40:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 13:40:41 -0000 Subject: [GHC] #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms In-Reply-To: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> References: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> Message-ID: <058.52c946490be58353efc34f4dbbbf581b@haskell.org> #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms -------------------------------------+------------------------------------- Reporter: ntc2 | 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 simonpj): It's nothing specific about call-stacks. It's in implicit parameters: {{{ type C2 = (?x::Int, ?y::Int) h1 :: C2 => Int -> IO () h1 v = print (?x+v) -- h2 :: (?x::Int, ?y::Int) => Int -> IO () h2 :: C2 => Int -> IO () h2 v = let ?x = 0 in h1 v main = let { ?x = 3; ?y = 4 } in h2 4 }}} This prints 7; but if you swap to the other (equivalent!) type sig for `h2` it prints 4 (as it should). Reason: in `h2`, when calling `h1` we should really rebuild a pair- constraint to pass on to `h1` so that we "see" the binding (which behaves like a local instance declaration) for `?x`. But we don't: we just have a wanted constraint `[W] C2` and a given one with the same type, and solve one from the other. We don't allow implicit parameters as superclasses for exactly this reason. It matters precisely where an implicit parameter constraint is solved, so you can't meaningfully abstract over them. `HasCallStack` is really just an implicit parameter, so it fails in the same way. Possible solutions: 1. Don't allow implicit parameters in type synonyms, or 2. Expand type synonyms in constraints more aggressively, so they really behave ''exactly'' like the expanded version. I vote for (2). Indeed I was surprised that doesn't happen already. But I think we should prohibit {{{ type instance F [a] = (?x::a, Show a) }}} with an implicit parameter on the right. Now aggressive expansion won't always work. This should be just as illegal as implicit parameters in superclasses. In effect, implicit parameters aren't really a first-class constraint form: you can't abstract over them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 13:42:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 13:42:12 -0000 Subject: [GHC] #14175: Panic repSplitTyConApp_maybe In-Reply-To: <045.2fc9be96fc161afbef29226fbd9e3b46@haskell.org> References: <045.2fc9be96fc161afbef29226fbd9e3b46@haskell.org> Message-ID: <060.6ff65e57b512401bf1d890048559d38f@haskell.org> #14175: Panic repSplitTyConApp_maybe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 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: indexed- crash or panic | types/should_fail/T14175 Blocked By: | Blocking: Related Tickets: #13910 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes please! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 13:43:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 13:43:59 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.72b0f1327b3151c55b5f74f80dfdfa13@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: performance Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: see ticket Blocked By: | Blocking: Related Tickets: #14226 | Differential Rev(s): Phab:D892 Wiki Page: | Phab:D896 -------------------------------------+------------------------------------- Comment (by simonpj): > severely reduces our ability to CBE Do you mean: it makes un-equal blocks that should be considered equal? Can you give an example? (For truly un-equal blocks we ''want'' to restrict our CBE: they aren't equal!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 13:49:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 13:49:30 -0000 Subject: [GHC] #14230: Gruesome kind mismatch errors for associated data family instances Message-ID: <050.be2138b3feceaf8cddb1acd9189d3e67@haskell.org> #14230: Gruesome kind mismatch errors for associated data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: #14175 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Spun off from https://ghc.haskell.org/trac/ghc/ticket/14175#comment:9. This program, which can only really be compiled on GHC HEAD at the moment: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} module Bug where class C k where data CD :: k -> k -> * instance C (Maybe a) where data CD :: (k -> *) -> (k -> *) -> * }}} Gives a heinous error message: {{{ Bug.hs:11:3: error: • Expected kind ‘(k -> *) -> (k -> *) -> *’, but ‘CD :: (k -> *) -> (k -> *) -> *’ has kind ‘Maybe a -> Maybe a -> *’ • In the data instance declaration for ‘CD’ In the instance declaration for ‘C (Maybe a)’ | 11 | data CD :: (k -> *) -> (k -> *) -> * | ^^^^^^^ }}} * We shouldn't be expecting kind `(k -> *) -> (k -> *) -> *`, but rather kind `Maybe a -> Maybe a -> *`, due to the instance head itself. * The phrase `‘CD :: (k -> *) -> (k -> *) -> *’ has kind ‘Maybe -> Maybe a -> *’` is similarly confusing. This doesn't point out that the real issue is the use of `(k -> *)`. Another program in a similar vein: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind class C a where data CD k (a :: k) :: k -> * instance C (Maybe a) where data CD k (a :: k -> *) :: (k -> *) -> * }}} {{{ Bug.hs:13:3: error: • Expected kind ‘(k -> *) -> *’, but ‘CD k (a :: k -> *) :: (k -> *) -> *’ has kind ‘k -> *’ • In the data instance declaration for ‘CD’ In the instance declaration for ‘C (Maybe a)’ | 13 | data CD k (a :: k -> *) :: (k -> *) -> * | ^^^^^^^^^^^^^^^^^^^^^^^ }}} This error message is further muddled by the incorrect use of `k` as the first type pattern (instead of `k -> *`, as subsequent kind signatures would suggest). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 13:49:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 13:49:47 -0000 Subject: [GHC] #14175: Panic repSplitTyConApp_maybe In-Reply-To: <045.2fc9be96fc161afbef29226fbd9e3b46@haskell.org> References: <045.2fc9be96fc161afbef29226fbd9e3b46@haskell.org> Message-ID: <060.c954cebf33767bea74ce4259b60c924a@haskell.org> #14175: Panic repSplitTyConApp_maybe -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 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: indexed- crash or panic | types/should_fail/T14175 Blocked By: | Blocking: Related Tickets: #13910, #14230 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #13910 => #13910, #14230 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 13:51:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 13:51:51 -0000 Subject: [GHC] #14231: Core lint error "in result of Static argument" Message-ID: <049.27a154799be5fe4aee7dcfb662d1a005@haskell.org> #14231: Core lint error "in result of Static argument" -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- 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 Thu Sep 14 14:02:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 14:02:13 -0000 Subject: [GHC] #12822: Cleanup GHC verbosity flags In-Reply-To: <045.4d9fca09f9ab247dee7b220b1a06e9a9@haskell.org> References: <045.4d9fca09f9ab247dee7b220b1a06e9a9@haskell.org> Message-ID: <060.ba6b9396738a05bb0a6f016f8626c223@haskell.org> #12822: Cleanup GHC verbosity flags -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | newcomer,flags 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 captaintrunky): I'm ready to work with both parts. It feels like the first part is somewhat simpler and straightforward, so I can start with it. As for the second part, I like the renaming with '-v' prefix. Implementation wise, I think that we can add a new constructor for DynFlag: {{{#!haskell data DynFlags = DynFlags { ... } | VerbocityFlag { ... } }}} As it's painful change, I think that it should be marked as deprecated for quite a lot of time, maybe until the end of 2018? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 15:09:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 15:09:59 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks In-Reply-To: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> References: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> Message-ID: <061.c5f341b1b9652504efbbe72b579c645f@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (CodeGen) | Resolution: | Keywords: Operating System: 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, because we have an extremely narrow definition of "common". Namely, to be the same two blocks must be syntactically identical, including local register names. I don't know how often this happens in practice, but I'd imagine not terribly often. I think the criterion that you would ideally want is equivalence up to alpha renaming of local registers; unfortunately this would likely be considerably more costly to check for. This makes me wonder whether we shouldn't just try to avoid duplicating the blocks to begin with (e.g. addressing #14222 earlier in the compilation pipeline). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 15:15:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 15:15:49 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks In-Reply-To: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> References: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> Message-ID: <061.543656520768c05440ec5800a44b7cdd@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (CodeGen) | Resolution: | Keywords: Operating System: 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): One option would be to run CBE **after** register allocation; this would make it significantly more likely that two structurally similar blocks would look similar to CBE. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 15:18:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 15:18:56 -0000 Subject: [GHC] #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc In-Reply-To: <049.42fb65c94c9d58534f92e7ad520e593b@haskell.org> References: <049.42fb65c94c9d58534f92e7ad520e593b@haskell.org> Message-ID: <064.876ca26cffe17f1ec5b58d507e66a91f@haskell.org> #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13840, #13973, | Differential Rev(s): #14087 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): @simonpj thanks for pointing me to this ticket. > The problem is in TcPat.find_field_ty but I can't see how to cleanly fix it. @mpickering part of the fix is surely to compare the selector names (which we have available). I've implemented this in 52110a7966848538583acb65f6e064aadc751260 and it fixes the original test case. However, the related bug #13847 remains: this patch is too liberal as it accepts examples where the field label is in scope only qualified, but it is used unqualified, and `DisambiguateRecordFields` is not enabled. Several of the other related bugs demonstrate this, so my patch causes them to be accepted (without a panic, but without an error either). I'm out of time to investigate further for now, unfortunately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 15:28:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 15:28:53 -0000 Subject: [GHC] #14232: Invalid type signature prokoves error in GHCi Message-ID: <046.50af05586dbbb6aeb886c7ddeb6828b1@haskell.org> #14232: Invalid type signature prokoves error in GHCi -------------------------------------+------------------------------------- Reporter: walling | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Poor/confusing (amd64) | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I create and save a file with the following content (notice the missing arrow `->`): {{{#!hs f :: (String -> a) String -> a f g s = g s }}} ... it outputs this snippet in GHCi (copy-pasted from terminal): {{{ $ ghci bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Playground/bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): repSplitAppTys String a_a1pl[sk:1] [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:808:9 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > Leaving GHCi. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 15:33:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 15:33:49 -0000 Subject: [GHC] #12822: Cleanup GHC verbosity flags In-Reply-To: <045.4d9fca09f9ab247dee7b220b1a06e9a9@haskell.org> References: <045.4d9fca09f9ab247dee7b220b1a06e9a9@haskell.org> Message-ID: <060.8721174da423c0aa2092b6c1b28693e4@haskell.org> #12822: Cleanup GHC verbosity flags -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | newcomer,flags 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): Let's first define specifically which flags we are talking about changing here; there are currently several broad categories that one might consider "verbosity" flags, * the dump (`-d*`) flags; these are currently handled uniformly within just and are represented by the `DynFlags.DumpFlags` type. * the `-fprint-*` flags * the `-fshow-options` flag * the `-v` flags * the as-of-yet non-existent flags which denote the individual effects currently controlled by the `-v` flags What concretely would you like to do with these flags? It's not entirely clear to me that, for instance, unifying the `-d*` flags with the `-fprint-*` flags is a good idea; afterall, the former are meant for developers while the latter are for users. Regarding the refactoring bit of (1): There should be no need to add a constructor to `DynFlags` (which is essentially just a product of all of the user-specified configuration GHC needs). You should have a look at how the `-On` flags are currently implemented; namely look at references to `optLevel` in `DynFlags`. Of particular interest will be `DynFlags.optLevelFlags`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 15:35:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 15:35:36 -0000 Subject: [GHC] #14230: Gruesome kind mismatch errors for associated data family instances In-Reply-To: <050.be2138b3feceaf8cddb1acd9189d3e67@haskell.org> References: <050.be2138b3feceaf8cddb1acd9189d3e67@haskell.org> Message-ID: <065.65338b9890f8e4422e44abd5c07fd37c@haskell.org> #14230: Gruesome kind mismatch errors for associated data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.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: #14175 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 15:58:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 15:58:13 -0000 Subject: [GHC] #14233: Remove old GetTickCount() code path for Windows Message-ID: <042.60b838660adf324b88964ba3ae6d930d@haskell.org> #14233: Remove old GetTickCount() code path for Windows ----------------------------------------+--------------------------------- Reporter: nh2 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Windows XP support was dropped since GHC 8.0 as per https://ghc.haskell.org/trac/ghc/wiki/WindowsGhc In `HsWord64 getMonotonicNSec()` on Windows we still fall back to the 32-bit `GetTickCount()` if `QueryPerformanceFrequency()` is not supported: [https://github.com/ghc/ghc/blob/ghc-8.2.1-release/rts/win32/GetTime.c#L69 Code] But [https://msdn.microsoft.com/en- us/library/windows/desktop/ms644905(v=vs.85).aspx Microsoft's documentation] says that `QueryPerformanceFrequency()` is guaranteed to be supported on Windows >= XP: > On systems that run Windows XP or later, the function will always succeed and will thus never return zero. Thus we can remove the `if (!qpc_supported)` check and all `if (!qpc_frequency.QuadPart)` code paths, and replace it with an assertion or a `./configure` check. We can also add a comment that `getMonotonicNSec()` will indeed always make use of the whole 64-bit domain. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 16:04:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 16:04:38 -0000 Subject: [GHC] #13205: Run `validate --slow` during CI at least sometimes. In-Reply-To: <047.9b52b4440ebca44d5a2343fbe8a3a428@haskell.org> References: <047.9b52b4440ebca44d5a2343fbe8a3a428@haskell.org> Message-ID: <062.117ff75171199a044133459cde136bc5@haskell.org> #13205: Run `validate --slow` during CI at least sometimes. -------------------------------------+------------------------------------- Reporter: dobenour | 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): This will fall out of the move to Jenkins; see #13716. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 16:04:57 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 16:04:57 -0000 Subject: [GHC] #13716: Move CI to Jenkins In-Reply-To: <046.48e2facaae8e965ca7d5990f8113aa95@haskell.org> References: <046.48e2facaae8e965ca7d5990f8113aa95@haskell.org> Message-ID: <061.f86f33b3b3e3307a0de44102d9cc1f7d@haskell.org> #13716: Move CI to Jenkins -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13897 | Blocking: Related Tickets: #11958, #13205 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: #11958 => #11958, #13205 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 16:16:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 16:16:26 -0000 Subject: [GHC] #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc In-Reply-To: <049.42fb65c94c9d58534f92e7ad520e593b@haskell.org> References: <049.42fb65c94c9d58534f92e7ad520e593b@haskell.org> Message-ID: <064.ddb587135653f31f6e69ce69924c1094@haskell.org> #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13840, #13973, | Differential Rev(s): #14087 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks Adam! I think you are saying * This patch fixes #13644 * And it fixes #13973, #14087, #13973, #13840, and #12158 * But not #13847 Right? If so, let's add regression tests for the others; and then close this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 16:16:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 16:16:28 -0000 Subject: [GHC] #14211: Compiler is unable to INLINE as well as the programmer can manually In-Reply-To: <047.2a53ecf1e57ab8268d4f765d1da08a61@haskell.org> References: <047.2a53ecf1e57ab8268d4f765d1da08a61@haskell.org> Message-ID: <062.27eca20b57e2d3afbd0cd1ee047a7300@haskell.org> #14211: Compiler is unable to INLINE as well as the programmer can manually -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | StaticArgumentTransformation, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I looked at this issue all of this afternoon and don't feel any closer to understanding what is going on but have some diagnosis. Manually performing SAT makes the program much faster. The SAT pass itself does nothing to the definition when there is an `INLINE` pragma on the definition. Removing the `INLINE` pragma causes SAT is happen but makes the program much slower as it is not inlined. Adding `-fexpose-all- unfoldings` to the defining module again makes the program much faster. I also noticed some interaction with SAT and inline pragmas, obviously the unsatted definition is included as the unfolding when an INLINE pragma is present even if it is a loop-breaker. SAT has the effect of changing a definition from a loop-breaker into an inlinable function but because we only export one unfolding this is then not usable across modules. All very unsatisfactory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 16:18:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 16:18:14 -0000 Subject: [GHC] #14232: Invalid type signature prokoves error in GHCi In-Reply-To: <046.50af05586dbbb6aeb886c7ddeb6828b1@haskell.org> References: <046.50af05586dbbb6aeb886c7ddeb6828b1@haskell.org> Message-ID: <061.f595859f1c06343257d1aff21b0279b8@haskell.org> #14232: Invalid type signature prokoves error in GHCi -------------------------------------+------------------------------------- Reporter: walling | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That's terrible! Works fine in HEAD though. I'm not sure what fixed it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 16:19:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 16:19:53 -0000 Subject: [GHC] #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc In-Reply-To: <049.42fb65c94c9d58534f92e7ad520e593b@haskell.org> References: <049.42fb65c94c9d58534f92e7ad520e593b@haskell.org> Message-ID: <064.b641701a3981b394c5e47e7929d92cfd@haskell.org> #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13840, #13973, | Differential Rev(s): #14087 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Replying to [comment:16 adamgundry]: > @simonpj thanks for pointing me to this ticket. > > > The problem is in TcPat.find_field_ty but I can't see how to cleanly fix it. > > @mpickering part of the fix is surely to compare the selector names (which we have available). I've implemented this in 52110a7966848538583acb65f6e064aadc751260 and it fixes the original test case. > > However, the related bug #13847 remains: this patch is too liberal as it accepts examples where the field label is in scope only qualified, but it is used unqualified, and `DisambiguateRecordFields` is not enabled. Several of the other related bugs demonstrate this, so my patch causes them to be accepted (without a panic, but without an error either). > > I'm out of time to investigate further for now, unfortunately. Is it not currently implemented like it is to enabled ORF to work properly? I think your patch changes it back to how it used to work? I can possibly try to create a test case tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 16:20:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 16:20:33 -0000 Subject: [GHC] #14232: Invalid type signature prokoves error in GHCi In-Reply-To: <046.50af05586dbbb6aeb886c7ddeb6828b1@haskell.org> References: <046.50af05586dbbb6aeb886c7ddeb6828b1@haskell.org> Message-ID: <061.08fb7f518ace2190bb937ebb0a5930f8@haskell.org> #14232: Invalid type signature prokoves error in GHCi -------------------------------------+------------------------------------- Reporter: walling | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"93da9f95b0c921f0d50a34bd1202c6428ff7ba5b/ghc" 93da9f95/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="93da9f95b0c921f0d50a34bd1202c6428ff7ba5b" Add test for Trac #14232 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 16:50:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 16:50:06 -0000 Subject: [GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks In-Reply-To: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> References: <050.56ce2cdbe46ff04b6c134e3857205c6f@haskell.org> Message-ID: <065.b035ec5280f1ea055fc9131504c0f1fc@haskell.org> #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: TobyGoodwin | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: performance Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: see ticket Blocked By: | Blocking: Related Tickets: #14226 | Differential Rev(s): Phab:D892 Wiki Page: | Phab:D896 -------------------------------------+------------------------------------- Comment (by bgamari): I should correct my statement from comment:39 as I misunderstood the intent of the patch from comment:28: The commit does not change the behavior of CBE; rather, it only adjusts the hash function used for "rough" comparison to more closely reflect the equality relation used later. However, I would argue that our CBE is still significantly less aggressive than it should be. Let's continue this discussion on #14226. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 16:51:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 16:51:18 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks In-Reply-To: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> References: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> Message-ID: <061.be53be639c88ba51e63e9c37868bc055@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): To make my objection in comment:4 more concrete, consider that you have the following two blocks (from the example in #14226), {{{ c2VZ: // global _c2Yd::I64 = _s2Se::I64 + 1; _s2Sx::I64 = _c2Yd::I64; _s2Se::I64 = _s2Sx::I64; goto c2TE; c2VY: // global _c2Yb::I64 = _s2Se::I64 + 1; _s2Sw::I64 = _c2Yb::I64; _s2Se::I64 = _s2Sw::I64; goto c2TE; }}} They differ in only two local register names, both of which are dead outside of their respective blocks. Ignoring the fact that the sinking pass should eliminate both intermediate locals, it seems to me like CBE should really consider these blocks to be duplicates. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 16:59:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 16:59:33 -0000 Subject: [GHC] #14222: Simple text fusion example results in rather duplicative code In-Reply-To: <046.acf3e774499e29f098fdca7495f195f8@haskell.org> References: <046.acf3e774499e29f098fdca7495f195f8@haskell.org> Message-ID: <061.26ef819be596c589c471194e91583eff@haskell.org> #14222: Simple text fusion example results in rather duplicative code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: CSE Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I should have been a bit more clear; the duplication that I was pointing out wasn't in the case alternatives (although that duplication is perhaps also worth thinking about). Rather, I was pointing out that the **entire case expression** is duplicated six times at various points in the program. I'll attach the simplified Core in a moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 17:00:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 17:00:28 -0000 Subject: [GHC] #14222: Simple text fusion example results in rather duplicative code In-Reply-To: <046.acf3e774499e29f098fdca7495f195f8@haskell.org> References: <046.acf3e774499e29f098fdca7495f195f8@haskell.org> Message-ID: <061.cc3df526bf6250a6acbcff25f867ad73@haskell.org> #14222: Simple text fusion example results in rather duplicative code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: CSE Operating System: 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): * Attachment "T14221.dump-simpl" added. Simplified Core from example given in ticket description -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 17:09:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 17:09:01 -0000 Subject: [GHC] #12742: Instantiation of invisible type family arguments is too eager In-Reply-To: <047.d8931509a6e46a4eff28174add83c0f9@haskell.org> References: <047.d8931509a6e46a4eff28174add83c0f9@haskell.org> Message-ID: <062.efbd1fc74446b017fe9f034d00eb0b41@haskell.org> #12742: Instantiation of invisible type family arguments is too eager -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: 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:"c813d8c9776b2c57ec90ab29e1cc0b687fbb9c34/ghc" c813d8c9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c813d8c9776b2c57ec90ab29e1cc0b687fbb9c34" Regression test for #12742 Location: dependent/should_compile/T12742 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 17:09:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 17:09:01 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2314038=3A_TypeApplications_regressio?= =?utf-8?q?n_in_GHC_HEAD=3A_=E2=80=98p0=E2=80=99_is_untouchable_i?= =?utf-8?q?nside_the_constraints=3A_=28=29?= In-Reply-To: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> References: <050.6967c2fcff26fd2fc4ab5ac2e6230fa5@haskell.org> Message-ID: <065.026f30f0d1bb8b024f5df67748faad2f@haskell.org> #14038: TypeApplications regression in GHC HEAD: ‘p0’ is untouchable inside the constraints: () -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14119 | Blocking: Related Tickets: #13877 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3b686879dd60250e084852c620864d7651f1a771/ghc" 3b68687/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3b686879dd60250e084852c620864d7651f1a771" Test #14038 in dependent/should_compile/T14038 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 17:09:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 17:09:02 -0000 Subject: [GHC] #13407: Fix printing of higher-rank kinds In-Reply-To: <047.e0e70f9dcf452b0789ae502f43b96326@haskell.org> References: <047.e0e70f9dcf452b0789ae502f43b96326@haskell.org> Message-ID: <062.f1a4bc51735a0137f5d922002f989391@haskell.org> #13407: Fix printing of higher-rank kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"04bb8736e1b0573ac45905a0f8c96bcb91564e2d/ghc" 04bb8736/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="04bb8736e1b0573ac45905a0f8c96bcb91564e2d" Fix #13407 by suppressing invisibles better. Previously, the iface-invisible-suppresser assumed that all invisible things are up front. Not true! test case: ghci/scripts/T13407 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 17:09:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 17:09:01 -0000 Subject: [GHC] #12938: Polykinded associated type family rejected on false pretenses In-Reply-To: <047.78289df80bb670b87243ff849a83bc7e@haskell.org> References: <047.78289df80bb670b87243ff849a83bc7e@haskell.org> Message-ID: <062.da1269a0c56aa3057801f4174aed8c5d@haskell.org> #12938: Polykinded associated type family rejected on false pretenses -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b9776308f69b6c6cca39c0cf05045405cdcfc16e/ghc" b9776308/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b9776308f69b6c6cca39c0cf05045405cdcfc16e" Test #12938 in indexed-types/should_compile/T12938 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 17:26:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 17:26:52 -0000 Subject: [GHC] #14229: Contraditions in users_guide/using-warnings.html In-Reply-To: <054.d6f9d16cc1b1fa988ffa9396c0d0581c@haskell.org> References: <054.d6f9d16cc1b1fa988ffa9396c0d0581c@haskell.org> Message-ID: <069.ba1dbb422e83db0c568cb6311e32d815@haskell.org> #14229: Contraditions in users_guide/using-warnings.html -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Oh dear; yes, it was only a matter of time until this fell out of sync. I'm a bit on the fence regarding whether we should invest some effort into automating the documentation generation or just fix it this once and try to be more careful in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 18:49:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 18:49:15 -0000 Subject: [GHC] #14144: Standardize binary distribution doc files In-Reply-To: <049.d1ba1a61ec88a72418a407b8a6104720@haskell.org> References: <049.d1ba1a61ec88a72418a407b8a6104720@haskell.org> Message-ID: <064.91b6c340db3c6e2bc377458f84a7d5ce@haskell.org> #14144: Standardize binary distribution doc files -------------------------------------+------------------------------------- Reporter: patrickdoc | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by patrickdoc): I've worked through a number of these problems in Hadrian, and opened a PR for comments [https://github.com/snowleopard/hadrian/pull/413]. Some more comments specifically about this ticket: Cabal's guide's configuration requires the "Read the Docs" theme. Packaging the theme inside the folder or requiring the user to install it both seem wrong to me, so it might be nice to have a default theme for local building. But that would have to be changed in the `cabal/Cabal/doc/conf.py` source. Building all of the docs on a single platform should be doable. However, the current implementation needs `package-data.mk` generated by `ghc-cabal configure`. This fails to configure `Win32` on Unix, and I would imagine the opposite is also true. However, I believe the data should be attainable just from the cabal file. I'll need to do some research to see if we can get by without `ghc-cabal` for the docs. I have managed to eliminate the need for `gen_contents_index`, which just leaves the mkDocs script. This script really just unifies the documentation built on both platforms, so solving the above would remove the need for this script. Likewise your upload script should become much simpler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 19:12:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 19:12:04 -0000 Subject: [GHC] #13407: Fix printing of higher-rank kinds In-Reply-To: <047.e0e70f9dcf452b0789ae502f43b96326@haskell.org> References: <047.e0e70f9dcf452b0789ae502f43b96326@haskell.org> Message-ID: <062.f6f607dc02f865ec213957a3437b756c@haskell.org> #13407: Fix printing of higher-rank kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 19:25:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 19:25:23 -0000 Subject: [GHC] #14234: Enable -Wconversion for GHC's C code Message-ID: <042.91986df936edd06b29e7da366eb6965e@haskell.org> #14234: Enable -Wconversion for GHC's C code -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Because apparently none of `-Wall`, `-Wextra` or `-pedantic` of GCC imply `-Wconversion` or its subset `-Wsign-conversion`: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51625 That means currently you can call a function taking an `unsigned int` with a `signed int` without getting any warning. That is very bad, because of course negative numbers will overflow. Having `-Wconversion` would have caught overflow errors such as this one: https://phabricator.haskell.org/D3955#110993 We should probably have it for the C code. Turning it on everywhere will be quite some work though because it creates lots of complaints such as `long long int` not being the same as `long int` (which is technically correct but in practice they are typically the same). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 19:35:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 19:35:56 -0000 Subject: [GHC] #13909: Misleading error message when partially applying a data type with a visible quantifier in its kind In-Reply-To: <050.a4022a3675301573ae65eedb2f8a013b@haskell.org> References: <050.a4022a3675301573ae65eedb2f8a013b@haskell.org> Message-ID: <065.620a23c4bfcfaa1b9db625372d525e5c@haskell.org> #13909: Misleading error message when partially applying a data type with a visible quantifier in its kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"89c8d4d26416381a088eab6f5b8744927e349e69/ghc" 89c8d4d2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="89c8d4d26416381a088eab6f5b8744927e349e69" Fix #13909 by tweaking an error message. GHC was complaining about numbers of arguments when the real problem is impredicativity. test case: typecheck/should_fail/T13909 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 19:35:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 19:35:56 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism In-Reply-To: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> References: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> Message-ID: <063.2e9c6162b4df883947636b159dca75fd@haskell.org> #13929: GHC panic with levity polymorphism -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fa626f3b1c1140a1f10bba60fdde10f767863f70/ghc" fa626f3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fa626f3b1c1140a1f10bba60fdde10f767863f70" Fix #13929 by adding another levity polymorphism check test case: typecheck/should_fail/T13929 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 19:35:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 19:35:56 -0000 Subject: [GHC] #13910: Inlining a definition causes GHC to panic (repSplitTyConApp_maybe) In-Reply-To: <050.14bd55ba33332ff15d7c16c4f0c73fad@haskell.org> References: <050.14bd55ba33332ff15d7c16c4f0c73fad@haskell.org> Message-ID: <065.c1bdbd53b311d52ad98c86e1cbd3ae7d@haskell.org> #13910: Inlining a definition causes GHC to panic (repSplitTyConApp_maybe) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: 14119 | Blocking: Related Tickets: #13877, #14038, | Differential Rev(s): #14175 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e5beb6ecac1497972fd538fd9a60c75e9279d68f/ghc" e5beb6ec/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e5beb6ecac1497972fd538fd9a60c75e9279d68f" Make rejigConRes do kind substitutions This was a lurking bug discovered on the hunt for #13910, but it doesn't fix that bug. The old version of rejigConRes was just wrong, forgetting to propagate a kind-change. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 19:35:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 19:35:56 -0000 Subject: [GHC] #13938: Iface type variable out of scope: k1 In-Reply-To: <050.7a3f2d444543ff2efcc9028549798245@haskell.org> References: <050.7a3f2d444543ff2efcc9028549798245@haskell.org> Message-ID: <065.9cb6f024b778b3d1c47e4d843057e002@haskell.org> #13938: Iface type variable out of scope: k1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: 14119 | Blocking: Related Tickets: #14038 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"86e1db7d6850144d6e86dfb33eb0819205f6904c/ghc" 86e1db7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="86e1db7d6850144d6e86dfb33eb0819205f6904c" Test #13938, with expect_broken test case: dependent/should_compile/T13938 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 19:35:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 19:35:56 -0000 Subject: [GHC] #13963: Runtime representation confusingly displayed In-Reply-To: <051.c04a48884b20e6ae25a9e6eec8350f39@haskell.org> References: <051.c04a48884b20e6ae25a9e6eec8350f39@haskell.org> Message-ID: <066.62210ee453122808f0b2ccd135aa1f92@haskell.org> #13963: Runtime representation confusingly displayed -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8f99cd67262a67c46ed1af952003486825e0e9f7/ghc" 8f99cd6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8f99cd67262a67c46ed1af952003486825e0e9f7" Fix #13963. This commit fixes several things: 1. RuntimeRep arg suppression was overeager for *visibly*-quantified RuntimeReps, which should remain. 2. The choice of whether to used a Named TyConBinder or an anonymous was sometimes wrong. Now, we do an extra little pass right before constructing the tycon to fix these. 3. TyCons that normally cannot appear unsaturated can appear unsaturated in :kind. But this fact was not propagated into the type checker. It now is. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 20:12:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 20:12:51 -0000 Subject: [GHC] #11819: Full validation issues for 8.0.1 In-Reply-To: <046.98f1b24d795b2e584c0708ff1e99ff8b@haskell.org> References: <046.98f1b24d795b2e584c0708ff1e99ff8b@haskell.org> Message-ID: <061.2edfac0e6a775f6f02bf2246c82ec757@haskell.org> #11819: Full validation issues for 8.0.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 8.0.1-rc3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): Results from 9e46167fc54b09bd59bc1e5f82dea19c3f4c3121, validate --slow on linux (repasting from ghc-devs): {{{ Unexpected results from: TEST="EtaExpandLevPoly PatternSplice StrictPats T10508_api T11627b T12809 T12870a T12870b T12870c T12870d T12870e T12870f T12870g T12870h T12903 T12962 T13366 T13543 T13688 T13780c T13822 T13949 T14137 T2552 T2783 T3001-2 T4114c T4114d T4188 T4334 T5129 T5363 T5559 T5611 T680 T7411 T7837 T7944 T8025 T8089 T8542 TH_spliceE5_prof_ext UnsafeReenter compact_gc compact_share dsrun014 dynamic-paper haddock.Cabal hpc_fork prof-doc-fib prof-doc-last profinline001 read029 return_mem_to_os rn041 scc001 scc002 scc003 scc005 space_leak_001 tc165 tryReadMVar2" SUMMARY for test run started at Thu Sep 14 04:57:20 2017 PDT 0:12:27 spent to go through 6091 total tests, which gave rise to 24105 test cases, of which 4531 were skipped 143 had missing libraries 19120 expected passes 203 expected failures 0 caused framework failures 0 caused framework warnings 6 unexpected passes 97 unexpected failures 5 unexpected stat failures Unexpected passes: /tmp/ghctest-e17wqi8b/test spaces/./dependent/should_compile/dynamic- paper.run dynamic-paper [unexpected] (optasm) /tmp/ghctest-e17wqi8b/test spaces/./indexed- types/should_compile/T7837.run T7837 [unexpected] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./parser/should_compile/read029.run read029 [unexpected] (optasm) /tmp/ghctest-e17wqi8b/test spaces/./rename/should_compile/rn041.run rn041 [unexpected] (optasm) /tmp/ghctest-e17wqi8b/test spaces/./simplCore/should_fail/T7411.run T7411 [unexpected] (hpc) /tmp/ghctest-e17wqi8b/test spaces/./typecheck/should_compile/tc165.run tc165 [unexpected] (optasm) Unexpected failures: /tmp/ghctest-e17wqi8b/test spaces/./codeGen/should_run/T5129.run T5129 [bad exit code] (hpc) /tmp/ghctest-e17wqi8b/test spaces/./codeGen/should_run/T5129.run T5129 [bad exit code] (optasm) /tmp/ghctest-e17wqi8b/test spaces/./codeGen/should_run/T5129.run T5129 [bad exit code] (threaded2) /tmp/ghctest-e17wqi8b/test spaces/./codeGen/should_run/T5129.run T5129 [bad exit code] (dyn) /tmp/ghctest-e17wqi8b/test spaces/./concurrent/should_run/T5611.run T5611 [bad stdout] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./concurrent/should_run/tryReadMVar2.run tryReadMVar2 [bad heap profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./deSugar/should_run/dsrun014.run dsrun014 [bad stderr] (hpc) /tmp/ghctest-e17wqi8b/test spaces/./deSugar/should_run/dsrun014.run dsrun014 [bad stderr] (optasm) /tmp/ghctest-e17wqi8b/test spaces/./deSugar/should_run/dsrun014.run dsrun014 [bad stderr] (threaded2) /tmp/ghctest-e17wqi8b/test spaces/./deSugar/should_run/dsrun014.run dsrun014 [bad stderr] (dyn) /tmp/ghctest-e17wqi8b/test spaces/./dependent/should_fail/T13780c.run T13780c [stderr mismatch] (normal) /tmp/ghctest-e17wqi8b/test spaces/./dependent/should_compile/dynamic- paper.run dynamic-paper [exit code non-0] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./driver/T4114d.run T4114d [bad exit code] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./driver/T4114c.run T4114c [bad exit code] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./ghc-api/T10508_api.run T10508_api [bad exit code] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./numeric/should_compile/T8542.run T8542 [stderr mismatch] (hpc) /tmp/ghctest-e17wqi8b/test spaces/./ghc-api/T10508_api.run T10508_api [bad exit code] (profthreaded) /tmp/ghctest-e17wqi8b/test spaces/./partial- sigs/should_compile/PatternSplice.run PatternSplice [exit code non-0] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./patsyn/should_run/T13688.run T13688 [exit code non-0] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./patsyn/should_run/T13688.run T13688 [exit code non-0] (profthreaded) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T3001-2.run T3001-2 [exit code non-0] (prof_hb) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/scc003.run scc003 [bad profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T11627b.run T11627b [bad heap profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T12962.run T12962 [bad profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/scc003.run scc003 [bad profile] (profthreaded) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T12962.run T12962 [bad profile] (profthreaded) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/scc003.run scc003 [bad profile] (prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T12962.run T12962 [bad profile] (prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/scc001.run scc001 [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/scc005.run scc005 [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/profinline001.run profinline001 [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T5559.run T5559 [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T11627b.run T11627b [bad heap profile] (prof_hc_hb) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/scc003.run scc003 [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T680.run T680 [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/scc002.run scc002 [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T12962.run T12962 [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/prof-doc- fib.run prof-doc-fib [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T11627b.run T11627b [bad heap profile] (prof_hb) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T2552.run T2552 [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/prof-doc- last.run prof-doc-last [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T11627b.run T11627b [bad heap profile] (prof_hd) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T5363.run T5363 [bad exit code] (ghci-ext-prof) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T11627b.run T11627b [bad heap profile] (prof_hy) /tmp/ghctest-e17wqi8b/test spaces/./profiling/should_run/T11627b.run T11627b [bad heap profile] (prof_hr) /tmp/ghctest-e17wqi8b/test spaces/./rts/T2783.run T2783 [bad exit code] (threaded1) /tmp/ghctest-e17wqi8b/test spaces/./rts/return_mem_to_os.run return_mem_to_os [bad heap profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./rts/T12903.run T12903 [bad heap profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870a.run T12870a [bad stderr] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870f.run T12870f [bad stdout] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870b.run T12870b [bad heap profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870c.run T12870c [bad heap profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870e.run T12870e [bad stdout] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870d.run T12870d [bad stderr] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870b.run T12870b [bad exit code] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870f.run T12870f [bad stderr] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870c.run T12870c [bad exit code] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870e.run T12870e [bad stderr] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870g.run T12870g [bad stderr] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870h.run T12870h [bad heap profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870h.run T12870h [bad stderr] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870f.run T12870f [bad stdout] (threaded2) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870e.run T12870e [bad stdout] (threaded2) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870f.run T12870f [bad stdout] (profthreaded) /tmp/ghctest-e17wqi8b/test spaces/./rts/flags/T12870e.run T12870e [bad stdout] (profthreaded) /tmp/ghctest-e17wqi8b/test spaces/./simplCore/should_compile/T7944.run T7944 [exit code non-0] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./simplCore/should_compile/T13543.run T13543 [stderr mismatch] (hpc) /tmp/ghctest-e17wqi8b/test spaces/./simplCore/should_compile/T13543.run T13543 [stderr mismatch] (optasm) /tmp/ghctest-e17wqi8b/test spaces/./simplCore/should_compile/T13543.run T13543 [stderr mismatch] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./simplCore/should_compile/T14137.run T14137 [stderr mismatch] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./th/TH_spliceE5_prof_ext.run TH_spliceE5_prof_ext [bad exit code] (normal) /tmp/ghctest-e17wqi8b/test spaces/./th/T4188.run T4188 [exit code non-0] (normal) /tmp/ghctest-e17wqi8b/test spaces/./th/T4188.run T4188 [exit code non-0] (ext-interp) /tmp/ghctest-e17wqi8b/test spaces/./th/T13366.run T13366 [bad stderr] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./th/should_compile/T8025/T8025.run T8025 [exit code non-0] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./th/should_compile/T13949/T13949.run T13949 [exit code non-0] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./typecheck/should_compile/T13822.run T13822 [exit code non-0] (normal) /tmp/ghctest-e17wqi8b/test spaces/./typecheck/should_compile/T13822.run T13822 [exit code non-0] (hpc) /tmp/ghctest-e17wqi8b/test spaces/./typecheck/should_compile/T13822.run T13822 [exit code non-0] (optasm) /tmp/ghctest-e17wqi8b/test spaces/./typecheck/should_compile/T13822.run T13822 [exit code non-0] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly [exit code non-0] (profasm) /tmp/ghctest-e17wqi8b/test spaces/./typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly [bad stderr] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./typecheck/should_run/T12809.run T12809 [bad stderr] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./typecheck/should_run/StrictPats.run StrictPats [bad stderr] (ghci) /tmp/ghctest-e17wqi8b/test spaces/./typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly [exit code non-0] (profthreaded) /tmp/ghctest-e17wqi8b/test spaces/../../libraries/base/tests/T8089.run T8089 [bad exit code] (ghci) /tmp/ghctest-e17wqi8b/test spaces/../../libraries/base/tests/T8089.run T8089 [bad exit code] (threaded1) /tmp/ghctest-e17wqi8b/test spaces/../../libraries/base/tests/T8089.run T8089 [bad exit code] (threaded2) /tmp/ghctest-e17wqi8b/test spaces/../../libraries/base/tests/T8089.run T8089 [bad exit code] (profthreaded) /tmp/ghctest-e17wqi8b/test spaces/../../libraries/hpc/tests/fork/hpc_fork.run hpc_fork [bad heap profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/../../libraries/ghc- compact/tests/compact_share.run compact_share [bad stdout] (profasm) /tmp/ghctest-e17wqi8b/test spaces/../../libraries/ghc- compact/tests/compact_share.run compact_share [bad stdout] (ghci) /tmp/ghctest-e17wqi8b/test spaces/../../libraries/ghc- compact/tests/compact_gc.run compact_gc [bad heap profile] (profasm) /tmp/ghctest-e17wqi8b/test spaces/../../libraries/ghc- compact/tests/compact_share.run compact_share [bad stdout] (profthreaded) /tmp/ghctest-e17wqi8b/test spaces/./ffi/should_fail/UnsafeReenter.run UnsafeReenter [bad exit code] (threaded1) /tmp/ghctest-e17wqi8b/test spaces/./ffi/should_fail/UnsafeReenter.run UnsafeReenter [bad exit code] (threaded2) /tmp/ghctest-e17wqi8b/test spaces/./ffi/should_fail/UnsafeReenter.run UnsafeReenter [bad exit code] (profthreaded) Unexpected stat failures: /tmp/ghctest-e17wqi8b/test spaces/./perf/haddock/haddock.Cabal.run haddock.Cabal [stat not good enough] (normal) /tmp/ghctest-e17wqi8b/test spaces/./perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (hpc) /tmp/ghctest-e17wqi8b/test spaces/./perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (optasm) /tmp/ghctest-e17wqi8b/test spaces/./perf/space_leaks/T4334.run T4334 [stat not good enough] (threaded2) /tmp/ghctest-e17wqi8b/test spaces/./perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (dyn) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 20:22:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 20:22:34 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism In-Reply-To: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> References: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> Message-ID: <063.3bf3a5cedd3754dbbda056a6d91ce5c9@haskell.org> #13929: GHC panic with levity polymorphism -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vagarenko): Replying to [comment:10 Ben Gamari ]: Can you please elaborate why you think GHC should reject this. This error message doesn't say much {{{ T13929.hs:29:27: error: A levity-polymorphic type is not allowed here: Type: GUnboxed f rf Kind: TYPE rf In the type of expression: gunbox x T13929.hs:29:37: error: A levity-polymorphic type is not allowed here: Type: GUnboxed g rg Kind: TYPE rg In the type of expression: gunbox y }}} As I mentioned in comment 8: >>To be clear, I don't think (although could be wrong) this program should compile; afterall, the type of gunbox requires that we represent a levity polymorphic result, which we cannot do. Hence, the real bug here is the panic instead of a proper type error. >I think levity polymorphism paper says you can't have functions with levity-polymorphic parameters, levity-polymorphic results are OK. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 20:48:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 20:48:23 -0000 Subject: [GHC] #14229: Contraditions in users_guide/using-warnings.html In-Reply-To: <054.d6f9d16cc1b1fa988ffa9396c0d0581c@haskell.org> References: <054.d6f9d16cc1b1fa988ffa9396c0d0581c@haskell.org> Message-ID: <069.1d6389e74669c6ab09eb93624c1293bd@haskell.org> #14229: Contraditions in users_guide/using-warnings.html -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): That's actually an easy, nice, introductory ticket for would-be GHC- contributors, so why waste computing power, when humans can do it almost as well. :) We'd just need to post it once a major release on a page with intro tickets and perhaps advertise the page on some hacker forums. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 21:10:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 21:10:19 -0000 Subject: [GHC] #14235: Suspiciously missing closure types in isRetainer Message-ID: <046.29af8d0b9a3a3d8c4d9ba9ecb9f4e7a7@haskell.org> #14235: Suspiciously missing closure types in isRetainer -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime | Version: 8.2.1 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: -------------------------------------+------------------------------------- `RetainerProfile:isRetainer` has a switch on closure types which appears to be lacking several defined types. * `BLOCKING_QUEUE`: someone actually came into `#ghc` complaining about a crash due to this one * `WHITEHOLE` * `SMALL_MUT_ARR_PTRS_CLEAN` * `SMALL_MUT_ARR_PTRS_DIRTY` * `SMALL_MUT_ARR_PTRS_FROZEN0` * `SMALL_MUT_ARR_PTRS_FROZEN` * `COMPACT_NFDATA` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 21:13:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 21:13:52 -0000 Subject: [GHC] #14235: Suspiciously missing closure types in isRetainer In-Reply-To: <046.29af8d0b9a3a3d8c4d9ba9ecb9f4e7a7@haskell.org> References: <046.29af8d0b9a3a3d8c4d9ba9ecb9f4e7a7@haskell.org> Message-ID: <061.08484e5d1eb165b472357b771292761d@haskell.org> #14235: Suspiciously missing closure types in isRetainer -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3967 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3967 Comment: Here is a patch, although it deserves careful review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 21:27:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 21:27:11 -0000 Subject: [GHC] #14227: Add -fdefer-ffi-errors flag In-Reply-To: <048.d425d7353a8d9d520ea0edf2dab3c26a@haskell.org> References: <048.d425d7353a8d9d520ea0edf2dab3c26a@haskell.org> Message-ID: <063.21727075fac4ebfe37d1643174d39b7d@haskell.org> #14227: Add -fdefer-ffi-errors flag -------------------------------------+------------------------------------- Reporter: tysonzero | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ooh, this would also allow us to potentially compile, for instance, `win32` on Linux, which would simplify documentation preparation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 21:32:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 21:32:41 -0000 Subject: [GHC] #11649: LLVM code generator produces mal-formed LLVM blocks In-Reply-To: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> References: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> Message-ID: <061.176799d08f31349b2bcfac0561041f96@haskell.org> #11649: LLVM code generator produces mal-formed LLVM blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: erikd Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9043 | Differential Rev(s): Phab:D1996 Wiki Page: | -------------------------------------+------------------------------------- Comment (by kavon): The entry block restriction isn't a bug in LLVM, it's just part of their IR design. I believe that not having any predecessors of the entry block simplifies some things related to computing dominators (plus, the way phi nodes work in LLVM makes it weird to write one for an entry block to merge incoming function arguments). A better fix for this issue would also include a way to avoid making a pass over the Cmm procedure to determine which global registers need allocas (which can only be declared in the entry block). Here's my proposal to solve both problems: For each CmmProc, after turning its Cmm blocks into LLVM blocks, we should generate a brand new entry basic block. This new entry block would include the allocas that we need for the function and then branch to the translated version of the original entry block. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 21:41:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 21:41:24 -0000 Subject: [GHC] #14189: Renamer does not preserve location for IEThingWith list items In-Reply-To: <044.0c99d438de6c1244d5aee79758fc528d@haskell.org> References: <044.0c99d438de6c1244d5aee79758fc528d@haskell.org> Message-ID: <059.a53b25ce8fdb7eb21622c2b149bf9b7c@haskell.org> #14189: Renamer does not preserve location for IEThingWith list items -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3968 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D3968 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 22:30:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 22:30:41 -0000 Subject: [GHC] #13910: Inlining a definition causes GHC to panic (repSplitTyConApp_maybe) In-Reply-To: <050.14bd55ba33332ff15d7c16c4f0c73fad@haskell.org> References: <050.14bd55ba33332ff15d7c16c4f0c73fad@haskell.org> Message-ID: <065.d378370a75e3cc77b5fa96c5cb11caa4@haskell.org> #13910: Inlining a definition causes GHC to panic (repSplitTyConApp_maybe) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: 14119 | Blocking: Related Tickets: #13877, #14038, | Differential Rev(s): #14175 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I now think that the patch in comment:14 is bogus. I tripped over this when debugging #13910, following the patch in comment:7 of that ticket. We had {{{ [W] alpha |> co ~ t }}} where `co :: ~ kappa`, `alpha` and `kappa` are unification variables, `t :: tk` is a skolem. We can't unify `alpha := t |> sym co` because the kinds don't match, so, according to `Note [Equalities with incompatible kinds]` (introduced in comment:14) we emit a derived equality {{{ [D] kappa ~ tk }}} and park the original Wanted as an Irred. ALAS! It turns out that `kappa` was ''already'' unified with `tk`, so the new Derived is instantly solved, but since no unifications happen we don't kick out the Wanted from the inert set, so it (utterly bogusly) stays unsolved. Possible solution: in the kind check in `canEqTyVar` use `zonk_eq_types`. That would make this program work, I think, but a deeper bug is lurking. The process described in `Note [Equalities with incompatible kinds]` relies on the kind-equality being solved by unification. But what if we have {{{ [W] (alpha :: F Int) ~ (beta :: *) }}} Now we may indeed be able solve the kind equality `F Int ~ *`, if `F` is a type function, with a suitable instance. But there is no unification happening, and we really do need ultimately to unify `alpha` to `beta |> co` where `co :: * ~ F Int`. I conclude that the patch in comment:14 is utterly wrong. Richard do you agree? Given `[W] co :: (alpha :: k1) ~ (ty :: k2)`, kind-heterogeneous, I think we probably ''do'' want to generate a wanted kind-equality {{{ [W] co_k :: k1 ~ k2 }}} Then rewrite the original equality to {{{ [W] co' :: (alpha :: k1) ~ (ty :: k2) |> sym co_k }}} '''But we want to somehow refrain from actually carrying out the unificationn unti we have discharged `co_k`.''' One way to do that might be to park it in Irreds and kick it out when unifying `co_k`. But that would fail if we end up iterating the entire implication in which this constraint lives. Maybe we should refrain from unify `alpha := ty` if there are any coercion holes in `ty`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 22:32:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 22:32:06 -0000 Subject: [GHC] #11198: TypeInType error message regressions In-Reply-To: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> References: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> Message-ID: <062.f484cf6a275425552ef01b8d1c28ad44@haskell.org> #11198: TypeInType error message regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeInType, Resolution: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/{T8262,T8603,tcfail122} Blocked By: | Blocking: Related Tickets: #11672 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: goldfire => (none) * status: merge => new Comment: I now think that the patch in comment:14 is bogus. I tripped over this when debugging #13910, following the patch in comment:7 of that ticket. We had {{{ [W] alpha |> co ~ t }}} where `co :: ~ kappa`, `alpha` and `kappa` are unification variables, `t :: tk` is a skolem. We can't unify `alpha := t |> sym co` because the kinds don't match, so, according to `Note [Equalities with incompatible kinds]` (introduced in comment:14) we emit a derived equality {{{ [D] kappa ~ tk }}} and park the original Wanted as an Irred. ALAS! It turns out that `kappa` was ''already'' unified with `tk`, so the new Derived is instantly solved, but since no unifications happen we don't kick out the Wanted from the inert set, so it (utterly bogusly) stays unsolved. Possible solution: in the kind check in `canEqTyVar` use `zonk_eq_types`. That would make this program work, I think, but a deeper bug is lurking. The process described in `Note [Equalities with incompatible kinds]` relies on the kind-equality being solved by unification. But what if we have {{{ [W] (alpha :: F Int) ~ (beta :: *) }}} Now we may indeed be able solve the kind equality `F Int ~ *`, if `F` is a type function, with a suitable instance. But there is no unification happening, and we really do need ultimately to unify `alpha` to `beta |> co` where `co :: * ~ F Int`. I conclude that the patch in comment:14 is utterly wrong. Richard do you agree? Given `[W] co :: (alpha :: k1) ~ (ty :: k2)`, kind-heterogeneous, I think we probably ''do'' want to generate a wanted kind-equality {{{ [W] co_k :: k1 ~ k2 }}} Then rewrite the original equality to {{{ [W] co' :: (alpha :: k1) ~ (ty :: k2) |> sym co_k }}} '''But we want to somehow refrain from actually carrying out the unificationn unti we have discharged `co_k`.''' One way to do that might be to park it in Irreds and kick it out when unifying `co_k`. But that would fail if we end up iterating the entire implication in which this constraint lives. Maybe we should refrain from unify `alpha := ty` if there are any coercion holes in `ty`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 23:02:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 23:02:43 -0000 Subject: [GHC] #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms In-Reply-To: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> References: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> Message-ID: <058.98cbde3948b601f5f66ce77368b9e75c@haskell.org> #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms -------------------------------------+------------------------------------- Reporter: ntc2 | 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 ntc2): Is this a known implicit params bug or "feature" then? In any case, I also vote for (2) :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 23:11:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 23:11:26 -0000 Subject: [GHC] #14236: Typeable App pattern doesn't match function types Message-ID: <046.ae944f6e95c597c7005a5662aad01714@haskell.org> #14236: Typeable App pattern doesn't match function types -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the type representation, {{{#!hs rep = typeRep @(Int -> Char) }}} We would expect this to match the pattern, {{{#!hs (App (App arrowRep intRep) charRep) }}} However, this is currently not the case. Fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 23:12:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 23:12:36 -0000 Subject: [GHC] #14236: Typeable App pattern doesn't match function types In-Reply-To: <046.ae944f6e95c597c7005a5662aad01714@haskell.org> References: <046.ae944f6e95c597c7005a5662aad01714@haskell.org> Message-ID: <061.e7069155c8f1047c7aa8375f6a0c2fcf@haskell.org> #14236: Typeable App pattern doesn't match function types -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.4.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:D2369 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D2369 Old description: > Consider the type representation, > {{{#!hs > rep = typeRep @(Int -> Char) > }}} > > We would expect this to match the pattern, > {{{#!hs > (App (App arrowRep intRep) charRep) > }}} > > However, this is currently not the case. Fix this. New description: Consider the type representation, {{{#!hs rep = typeRep @(Int -> Char) }}} We would expect this to match the pattern, {{{#!hs (App (App arrowRep intRep) charRep) }}} where {{{#!hs arrowRep :: TypeRep ((->) :: Type -> Type -> Type) intRep :: TypeRep Int charRep :: TypeRep Char }}} However, this is currently not the case. Fix this. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 23:13:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 23:13:07 -0000 Subject: [GHC] #14236: Typeable App pattern doesn't match function types In-Reply-To: <046.ae944f6e95c597c7005a5662aad01714@haskell.org> References: <046.ae944f6e95c597c7005a5662aad01714@haskell.org> Message-ID: <061.529f21eecf97890630aa1b80a0ea5f16@haskell.org> #14236: Typeable App pattern doesn't match function types -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.4.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:D3969 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D2369 => Phab:D3969 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 23:14:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 23:14:59 -0000 Subject: [GHC] #8406: Invalid object in isRetainer() or Segfault In-Reply-To: <047.cda95cb1752355077595406288b06592@haskell.org> References: <047.cda95cb1752355077595406288b06592@haskell.org> Message-ID: <062.15231793e04bb282ddcbc726e8218db1@haskell.org> #8406: Invalid object in isRetainer() or Segfault -----------------------------------+-------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by bgamari): Note that Phab:D3967 may be relevant to some of the issues reported above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 23:15:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 23:15:27 -0000 Subject: [GHC] #4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch In-Reply-To: <049.7962690c1cad7c1dc6772c5aaee21bae@haskell.org> References: <049.7962690c1cad7c1dc6772c5aaee21bae@haskell.org> Message-ID: <064.bba27b3eb0858f1149b958e041375eec@haskell.org> #4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch ----------------------------------+-------------------------------------- Reporter: dleuschner | Owner: (none) Type: bug | Status: infoneeded Priority: highest | Milestone: 8.4.1 Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11978 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by bgamari): Note that ​Phab:D3967 may be relevant to some of the issues reported above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 14 23:50:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Sep 2017 23:50:44 -0000 Subject: [GHC] #14237: -Wredundant-constraints incorrectly warns about required type equality constraints in default signatures Message-ID: <050.e3dc094564bbfbd54906e6f9a94f2531@haskell.org> #14237: -Wredundant-constraints incorrectly warns about required type equality constraints in default signatures -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- GHC emits a warning about the following function: {{{#!hs f :: (Integer ~ a) => a -> Integer f = (+ 1) }}} {{{ /private/tmp/redundant-default- constraint/src/RedundantDefaultConstraints.hs:14:1: warning: [-Wredundant- constraints] • Redundant constraint: Integer ~ a • In the type signature for: f :: forall a. Integer ~ a => a -> Integer | 14 | f :: Integer ~ a => a -> Integer | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} This is understandable (though the error message could perhaps be better) because the equality is pointless. It would be better to just rewrite the type signature as `Integer -> Integer`. However, this becomes problematic when combined with `DefaultSignatures`. GHC ''also'' emits a warning for the following program: {{{#!hs class Monad m => MonadFoo m where foo :: m () default foo :: (MonadFoo m', MonadTrans t, m ~ t m') => m () foo = lift foo }}} {{{ /private/tmp/redundant-default- constraint/src/RedundantDefaultConstraints.hs:8:18: warning: [-Wredundant- constraints] • Redundant constraint: m ~ t m' • In the type signature for: foo :: forall (m' :: * -> *) (t :: (* -> *) -> * -> *). (MonadFoo m', MonadTrans t, m ~ t m') => m () | 8 | default foo :: (MonadFoo m', MonadTrans t, m ~ t m') => m () | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} This is wrong, because the constraint here is necessary. The type equality cannot be “inlined” into the type, since #12918 made that illegal. The constraint cannot be removed entirely, since then the program would fail to typecheck. Therefore, GHC should not produce an error in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 00:07:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 00:07:30 -0000 Subject: [GHC] #14237: -Wredundant-constraints incorrectly warns about required type equality constraints in default signatures In-Reply-To: <050.e3dc094564bbfbd54906e6f9a94f2531@haskell.org> References: <050.e3dc094564bbfbd54906e6f9a94f2531@haskell.org> Message-ID: <065.ad14a974a6cfab744b86b0b9f9ea46fc@haskell.org> #14237: -Wredundant-constraints incorrectly warns about required type equality constraints in default signatures -------------------------------------+------------------------------------- Reporter: lexi.lambda | 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 lexi.lambda): This actually seems worse than I thought—GHC warns even when type equalities are clearly required. It seems like perhaps `-Wredundant- constraints` in GHC 8.2.1 treats all type equalities as redundant? For example, this program produces a warning: {{{#!hs import GHC.Exts (IsList(..)) nums :: (Num a, IsList t, Item t ~ a) => t nums = fromList [1, 2, 3] }}} {{{ /private/tmp/redundant-default- constraint/src/RedundantDefaultConstraints.hs:9:1: warning: [-Wredundant- constraints] • Redundant constraint: Item t ~ a • In the type signature for: nums :: forall a t. (Num a, IsList t, Item t ~ a) => t | 9 | nums :: (Num a, IsList t, Item t ~ a) => t | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 00:08:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 00:08:22 -0000 Subject: [GHC] #14237: -Wredundant-constraints incorrectly treats all type equality constraints as redundant (was: -Wredundant-constraints incorrectly warns about required type equality constraints in default signatures) In-Reply-To: <050.e3dc094564bbfbd54906e6f9a94f2531@haskell.org> References: <050.e3dc094564bbfbd54906e6f9a94f2531@haskell.org> Message-ID: <065.ee536fb44f448ac8ebb550fa4d587f2d@haskell.org> #14237: -Wredundant-constraints incorrectly treats all type equality constraints as redundant -------------------------------------+------------------------------------- Reporter: lexi.lambda | 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 00:41:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 00:41:23 -0000 Subject: [GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix In-Reply-To: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> References: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> Message-ID: <057.c7f882dd8cb902a9d5e43b9974d84feb@haskell.org> #8684: hWaitForInput cannot be interrupted by async exceptions on unix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13497, 13525 | Blocking: Related Tickets: #12912, #13525 | Differential Rev(s): Phab:D42 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): OK new info with the power of `-debug` and `+RTS -Ds`: In non`-threaded`, it does raise the exception, but _after_ the entire `hWaitForInput` is over. I can see it in `cap 0: raising exception in thread 2.`, and also the reason: `timeout`'s `throwTo ` also only happens **after** `hWaitForInput` is over (it prints `cap 0: throwTo: from thread 1 to thread 2` only at the very end). So that means it's not the exception handling that's not working, it's the throwing. My C code returns back into Haskell land, but there is no exception there at the time so it continues. ---- On my debug commit https://github.com/nh2/ghc/blob/49a5e9ce7062da7594bfd86ca7af92796b84b52a/libraries/base/cbits/inputReady.c#L53-L68 that looks like this (relevant output without `-debug` in [https://gist.github.com/nh2/f543030a9b68b1530b19087d0c655115 this gist]): {{{ cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (suspended while making a foreign call) fdReady called with msecs = 20 fdReady res = -1 cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (suspended while making a foreign call) fdReady called with msecs = 10 fdReady res = -1 cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (suspended while making a foreign call) fdReady called with msecs = 0 fdReady res = 0 cap 0: running thread 1 (ThreadRunGHC) cap 0: throwTo: from thread 1 to thread 2 thread 2 @ 0x42001059d0 is blocked until 558048911098409 (TSO_DIRTY) cap 0: raising exception in thread 2. cap 0: thread 1 stopped (finished) bound thread (1) finished task exiting }}} Observe here how `cap 0: throwTo: from thread 1 to thread 2` is after the `fdReady called with msecs = 0` (`hWaitForInput` ran its entire 5 seconds). ---- So now we just need to find out why `timeout` doesn't result in a prompt `cap 0: throwTo: from thread 1 to thread 2` after 1 second. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 01:25:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 01:25:31 -0000 Subject: [GHC] #11649: LLVM code generator produces mal-formed LLVM blocks In-Reply-To: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> References: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> Message-ID: <061.291f5fae87d0ed921e03b9288e2c5fe3@haskell.org> #11649: LLVM code generator produces mal-formed LLVM blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: erikd Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9043 | Differential Rev(s): Phab:D1996 Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): That's a fantastic idea! I guess we could even name the initial block `entry`, and just allocate all the registers on the stack and just fall through into the first block. I'll give this a try with the `llvmng`. If this works, I might backport it to the `llvm` backend. It would also relinquish the need for the unique supply in the `LlvmM` I believe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 01:35:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 01:35:58 -0000 Subject: [GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix In-Reply-To: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> References: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> Message-ID: <057.8e1dc1760466c4e93ac3febbd0802212@haskell.org> #8684: hWaitForInput cannot be interrupted by async exceptions on unix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13497, 13525 | Blocking: Related Tickets: #12912, #13525 | Differential Rev(s): Phab:D42 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): OK, looking at the definition of `timeout` [http://hackage.haskell.org/package/base-4.10.0.0/docs/src/System.Timeout.html#timeout here], and making an instrumented copy of it into my test case file, it seems that the `threadDelay n >> throwTo pid ex` is never executed. The `cap 0: throwTo: from thread 1 to thread 2` I observe at the very end is from `killThread`. Changing it into this {{{ handleJust (\e -> if e == ex then Just () else Nothing) (\_ -> return Nothing) (bracket (forkIOWithUnmask $ \unmask -> do putStrLn "before unmask" unmask $ putStrLn "before delay" >> threadDelay n >> putStrLn "delay over" >> throwTo pid ex) (\x -> putStrLn "before killThread" >> uninterruptibleMask_ (killThread x)) (\_ -> fmap Just f)) }}} yields the output at the very end: {{{ fdReady called with msecs = 0 fdReady res = 1 before killThread fdReady called with msecs = 0 fdReady res = 1 before unmask }}} and then the program terminates. This suggests that nothing inside `unmask` is ever executed in my non- threaded case, and that the thread started with `forkIOWithUnmask` doesn't actually run until `hWaitForInput` is over. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 01:42:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 01:42:44 -0000 Subject: [GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix In-Reply-To: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> References: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> Message-ID: <057.ade27e20fd742649f467db38c256436e@haskell.org> #8684: hWaitForInput cannot be interrupted by async exceptions on unix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13497, 13525 | Blocking: Related Tickets: #12912, #13525 | Differential Rev(s): Phab:D42 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Looking at this with `+RTS -Ds` again, we get: {{{ created capset 0 of type 2 created capset 1 of type 3 cap 0: initialised assigned cap 0 to capset 0 assigned cap 0 to capset 1 new task (taskCount: 1) cap 0: created thread 1 new bound thread (1) cap 0: schedule() cap 0: running thread 1 (ThreadRunGHC) fdReady called with msecs = 0 fdReady res = 1 setup cap 0: created thread 2 cap 0: thread 1 stopped (suspended while making a foreign call) fdReady called with msecs = 5000 fdReady res = -1 ... [lots of output running only thread 1] ... cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (suspended while making a foreign call) fdReady called with msecs = 4690 fdReady res = -1 cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (suspended while making a foreign call) fdReady called with msecs = 4680 fdReady res = 0 cap 0: running thread 1 (ThreadRunGHC) cap 0: throwTo: from thread 1 to thread 2 thread 2 @ 0x4200105aa0 is not blocked (TSO_DIRTY) cap 0: throwTo: blocking on thread 2 cap 0: thread 1 stopped (blocked on throwTo) thread 1 @ 0x4200105388 is blocked on a throwto message (TSO_DIRTY) cap 0: running thread 2 (ThreadRunGHC) cap 0: raising exception in thread 2. cap 0: waking up thread 1 on cap 0 cap 0: thread 2 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) }}} So the new question here is: Why is `thread 2` (the one that contains `unmask $ threadDelay n >> throwTo pid ex`) never run, and `thread 1` is run all the time? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 01:54:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 01:54:01 -0000 Subject: [GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix In-Reply-To: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> References: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> Message-ID: <057.94e73c8a9efa5dcaf1d572c09a9f90b9@haskell.org> #8684: hWaitForInput cannot be interrupted by async exceptions on unix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13497, 13525 | Blocking: Related Tickets: #12912, #13525 | Differential Rev(s): Phab:D42 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): The above seems to be because in `rts/Schedule.c` only `resumeThread()` is called, and `schedule()` is not called. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 02:04:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 02:04:22 -0000 Subject: [GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix In-Reply-To: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> References: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> Message-ID: <057.3beb9d774692477c3227d54e0f5ec6f9@haskell.org> #8684: hWaitForInput cannot be interrupted by async exceptions on unix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13497, 13525 | Blocking: Related Tickets: #12912, #13525 | Differential Rev(s): Phab:D42 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I think I've got it! Inserting a `yield` [https://github.com/nh2/ghc/blob/49a5e9ce7062da7594bfd86ca7af92796b84b52a/libraries/base/GHC/IO/FD.hs#L422 here] after `fdReady()` returns back into Haskell makes `delay over` appear and my example code terminate after the 1 second `timeout`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 02:46:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 02:46:43 -0000 Subject: [GHC] #11198: TypeInType error message regressions In-Reply-To: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> References: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> Message-ID: <062.18016cf3956585b1d9915041a1302a25@haskell.org> #11198: TypeInType error message regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeInType, Resolution: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/{T8262,T8603,tcfail122} Blocked By: | Blocking: Related Tickets: #11672 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): What test program inspired comment:18? I don't agree with some of your conclusions and want to examine this myself. In particular, both problems (the already-unified `kappa` and the `F Int` example) would seem to be solved as long as we flatten kinds sufficiently. I have reworked some of the code around this in Phab:D3848 (my big flattener patch), which is currently (with much progress made today) undergoing revisions as suggested last week. This new version explicitly flattens kinds before emitting the derived, and so I wonder if your test program behaves differently on my end. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 02:52:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 02:52:45 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism In-Reply-To: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> References: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> Message-ID: <063.10bdf11426e6581c0b5cac6ce3e458de@haskell.org> #13929: GHC panic with levity polymorphism -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): It looks to me that the runtime representation of `x` and `y` can't be known at compile time -- these arguments are levity-polymorphic, which is problematic. Do you see otherwise? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 06:20:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 06:20:44 -0000 Subject: [GHC] #14211: Compiler is unable to INLINE as well as the programmer can manually In-Reply-To: <047.2a53ecf1e57ab8268d4f765d1da08a61@haskell.org> References: <047.2a53ecf1e57ab8268d4f765d1da08a61@haskell.org> Message-ID: <062.8dcdf6faf3537710cf6f74d4ffafa68b@haskell.org> #14211: Compiler is unable to INLINE as well as the programmer can manually -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | StaticArgumentTransformation, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): {{{ -dcore-lint Turn on heavyweight intra-pass sanity-checking within GHC, at Core level. (It checks GHC’s sanity, not yours.) }}} Someone who is not working on GHC would not even look at such flags and rightly so. We need a flag for regular programmers helping them in the optimization process, something like `-Wmissed-specialisations` or does that flag cover inlining as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 06:34:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 06:34:51 -0000 Subject: [GHC] #14211: Compiler is unable to INLINE as well as the programmer can manually In-Reply-To: <047.2a53ecf1e57ab8268d4f765d1da08a61@haskell.org> References: <047.2a53ecf1e57ab8268d4f765d1da08a61@haskell.org> Message-ID: <062.f9a425e637584c927e7573442114c579@haskell.org> #14211: Compiler is unable to INLINE as well as the programmer can manually -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | StaticArgumentTransformation, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): Thanks Matthew for looking into this. It looks like as of now inline and SAT are exclusive to each other. What's the solution to this - we either need to inline the SATed definition or can we do SAT again after inlining? I observed that my package had several SAT opportunities that I fixed manually but `-fstatic-argument-transformation` did not make any difference, it could be because of this same reason perhaps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 09:09:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 09:09:13 -0000 Subject: [GHC] #6084: Add stg_ap_pnnv and related call patterns In-Reply-To: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> References: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> Message-ID: <064.19b6939ba851ffb157d03a8c6eb392cf@haskell.org> #6084: Add stg_ap_pnnv and related call patterns -------------------------------------+--------------------------------- Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8313 Related Tickets: | -------------------------------------+--------------------------------- Changes (by angerman): * Attachment "T6084.ll" added. T6084.ll -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 09:16:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 09:16:41 -0000 Subject: [GHC] #6084: Add stg_ap_pnnv and related call patterns In-Reply-To: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> References: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> Message-ID: <064.059db0297680d1a9b7a09828127e1b15@haskell.org> #6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------- Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8313 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): `-fllvm` with LLVM5 and GHC at `8a1de424`, generates some rather interesting IR with -O2: https://ghc.haskell.org/trac/ghc/attachment/ticket/6084/T6084.ll specifically {{{ ... %ln4QS = bitcast void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @Main_p_info$def to void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64, float, double)* %ln4QT = load i64*, i64** %Sp_Var %ln4QU = load i64, i64* %R1_Var %ln4QV = load i64, i64* %R2_Var %ln4QW = load float, float* %F1_Var %ln4QX = load double, double* %D2_Var tail call ghccc void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64, float, double) %ln4QS( i64* %Base_Arg, i64* %ln4QT, i64* %Hp_Arg, i64 %ln4QU, i64 %ln4QV, i64 undef, i64 undef, i64 undef, i64 undef, i64 %SpLim_Arg, float %ln4QW, double %ln4QX ) nounwind ret void } @Main_p_info = alias i8, bitcast (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @Main_p_info$def to i8*) define ghccc void @Main_p_info$def(i64* noalias nocapture %Base_Arg, i64* noalias nocapture %Sp_Arg, i64* noalias nocapture %Hp_Arg, i64 %R1_Arg, i64 %R2_Arg, i64 %R3_Arg, i64 %R4_Arg, i64 %R5_Arg, i64 %R6_Arg, i64 %SpLim_Arg) align 8 nounwind prefix <{i64, i64, i64, i64, i64, i64}><{i64 add (i64 sub (i64 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @Main_p_slow$def to i64),i64 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @Main_p_info$def to i64)),i64 0), i64 451, i64 add (i64 sub (i64 ptrtoint (%S4QA_srt_struct* @S4QA_srt$def to i64),i64 ptrtoint (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @Main_p_info$def to i64)),i64 0), i64 12884901888, i64 0, i64 4294967310}> { ... }}} we bitcast `@Main_p_info$def` from `(i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)` to `(i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64, float, double)`. (E.g. we add a `float` and a `double`) to the signature. And then we call the newly bitcasted function with an additional float and double. However `Main_p_info$def` doesn't take those two last arguments, and never does anything with them. At the point where we create `Main_p_info$def` (the `CmmProc`) the `live` value hence does not include registers `F1` and `D1`. Yet at the call site we do expect to pass them. The LLVM backend, simply ignores this, as it always casts functions to the expected type. However a more rigorous backend that tries to unify functions with their callsite signatures falls over at this point. Is it possible that some liveness logic is broken in Cmm here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 10:18:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 10:18:20 -0000 Subject: [GHC] #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms In-Reply-To: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> References: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> Message-ID: <058.1ceb50c325fe42fb9e61da56e2025757@haskell.org> #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms -------------------------------------+------------------------------------- Reporter: ntc2 | 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 simonpj): Well NOW it's a know implicit-parameter bug. No one had previously reported it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 10:24:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 10:24:04 -0000 Subject: [GHC] #11198: TypeInType error message regressions In-Reply-To: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> References: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> Message-ID: <062.c42bb0047845cc22a53f5f1145d9d2aa@haskell.org> #11198: TypeInType error message regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeInType, Resolution: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/{T8262,T8603,tcfail122} Blocked By: | Blocking: Related Tickets: #11672 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > What test program inspired comment:18? The one in #13910, with HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 11:16:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 11:16:42 -0000 Subject: [GHC] #6084: Add stg_ap_pnnv and related call patterns In-Reply-To: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> References: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> Message-ID: <064.1dac4ba20f106be4e8b4e81febda7ab3@haskell.org> #6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------- Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8313 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): It's always possible that something is broken :) What does the Cmm look like? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 11:59:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 11:59:28 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks In-Reply-To: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> References: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> Message-ID: <061.df6265d1c46ee1ce8b0dc531c2de1ed7@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (CodeGen) | Resolution: | Keywords: Operating System: 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): OK, got it. Yes, totally. CBE should be insensitive to alpha-renaming of local register. One way to do this would be for the hashing function to be sensitive to binding sites. Concretely, suppose that we had {{{ hashInstrs :: HashEnv -> [Instruction] -> HashCode type HashEnv = (Map LocalReg HashCode, Int) }}} Now we could have {{{ hashInstrs (env, next) (Load reg expr : instrs) = hashInstrs (extendEnv env reg next, next+1) instrs `hashPlus` hashExpr env expr ... hashExpr env (LocalReg r) | Just hc <- lookupEnv env r = hc | otherwise = hashLocalReg r -- as now }}} The mapping tells what hashcode to use for a local register. We deBruijn- number all binding sites as we come across them, mapping them to 1, 2, 3, etc. Now we'll be insensitive to what name is chosen. I think we already have a function that, for an instruction, says what local regs it assigns to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 13:12:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 13:12:13 -0000 Subject: [GHC] #14237: -Wredundant-constraints incorrectly treats all type equality constraints as redundant In-Reply-To: <050.e3dc094564bbfbd54906e6f9a94f2531@haskell.org> References: <050.e3dc094564bbfbd54906e6f9a94f2531@haskell.org> Message-ID: <065.850974421d4bcc0e1e65723e6e6c8c99@haskell.org> #14237: -Wredundant-constraints incorrectly treats all type equality constraints as redundant -------------------------------------+------------------------------------- Reporter: lexi.lambda | 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: #12700 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #12700 Comment: Yes, this is a known pain point of `-Wredundant-constraints`. See also the very similar ticket #12700. (Among other reasons, this is why `-Wredundant-constraints` is no longer a part of `-Wall`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 13:12:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 13:12:32 -0000 Subject: [GHC] #12700: Don't warn about redundant constraints for type equalities In-Reply-To: <047.e796800360deb24c984967cba0fa772b@haskell.org> References: <047.e796800360deb24c984967cba0fa772b@haskell.org> Message-ID: <062.7bc258b2977b72eba5ec5772aa333890@haskell.org> #12700: Don't warn about redundant constraints for type equalities -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #14237 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #14237 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 13:25:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 13:25:13 -0000 Subject: [GHC] #10651: Type checking issue with existential quantification, rank-n types and constraint kinds In-Reply-To: <046.13e821c10925b9eff72404016930e9cc@haskell.org> References: <046.13e821c10925b9eff72404016930e9cc@haskell.org> Message-ID: <061.513f406dfe8ef16050e046601ec5d699@haskell.org> #10651: Type checking issue with existential quantification, rank-n types and constraint kinds -------------------------------------+------------------------------------- Reporter: Roboguy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Indeed, that seems to the fix. Note that you can get rid of the explicit `Proxy b` argument if you turn on `AllowAmbiguousTypes`: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} data ConstrList c = forall a. c a => a :> ConstrList c | CNil infixr :> constrMap :: (forall a. c a => a -> b) -> ConstrList c -> [b] constrMap f (x :> xs) = f x : constrMap f xs constrMap f CNil = [] constrMapM :: Monad m => (forall a. c a => a -> m b) -> ConstrList c -> m [b] constrMapM f = sequence . constrMap f constrMapM_ :: forall m c b. Monad m => (forall a. (c a) => a -> m b) -> ConstrList c -> m () constrMapM_ f x = constrMapM f x >>= (\(_ :: [b]) -> return ()) }}} This has the potential downside that you might need to explicitly provide some extra type information to `constrMapM_` in places that you invoke it, perhaps in the form of `TypeApplications`: {{{#!hs constrMapM_ @IO @Show @() print }}} But that's the price you pay for dancing with ambiguity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 13:33:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 13:33:24 -0000 Subject: [GHC] #14222: Simple text fusion example results in rather duplicative code In-Reply-To: <046.acf3e774499e29f098fdca7495f195f8@haskell.org> References: <046.acf3e774499e29f098fdca7495f195f8@haskell.org> Message-ID: <061.2bd5e4ef2e104dcb3ef0a8dedc6339e2@haskell.org> #14222: Simple text fusion example results in rather duplicative code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: CSE Operating System: 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): Last night I looked further into why we end up duplicating the expession in question: There are two ways by which we end up duplicating the case analysis. == First Duplication == First, relatively early in simplification we end up rewriting `isNumeric'` to (after inlining `(||)`), {{{#!hs isNumeric'_s2z6 :: Char -> Bool isNumeric'_s2z6 = \ (eta_B1 :: Char) -> case eta_B1 of { GHC.Types.C# c2_a2sP -> case GHC.Prim.leChar# '0'# c2_a2sP of { __DEFAULT -> case c2_a2sP of { __DEFAULT -> GHC.Types.False; '+'# -> GHC.Types.True; '-'# -> GHC.Types.True; '.'# -> GHC.Types.True; 'E'# -> GHC.Types.True; 'e'# -> GHC.Types.True }; 1# -> case GHC.Prim.leChar# c2_a2sP '9'# of { __DEFAULT -> case c2_a2sP of { __DEFAULT -> GHC.Types.False; '+'# -> GHC.Types.True; '-'# -> GHC.Types.True; '.'# -> GHC.Types.True; 'E'# -> GHC.Types.True; 'e'# -> GHC.Types.True }; 1# -> GHC.Types.True } } } }}} Note the two instances of `case c2_a2sP of {...}`; this comes about via unconditional post-inlining since the scrutinee is trivial (being a `Var`). This makes me wonder whether there is any benefit for `postInlineUnconditional` to inline join points. == Second Duplication == Then, later in simplification we duplicate `isNumeric'` three times (resulting in six instances of the `case` analysis). This happens when we start with this Core after worker/wrapper, {{{#!hs join { $w$j_s2Cy :: GHC.Prim.Char# -> Int -> Bool $w$j_s2Cy (ww_s2Cw :: GHC.Prim.Char#) (w_s2Ct :: Int) = let { w_s2Cs :: Char w_s2Cs = GHC.Types.C# ww_s2Cw } in let { x_a2vL :: Char x_a2vL = w_s2Cs } in let { s'_a2vM :: Int s'_a2vM = w_s2Ct } in case x_a2vL of { GHC.Types.C# c2_a2t0 -> join { $j_s2yJ :: Bool $j_s2yJ = case c2_a2t0 of { __DEFAULT -> GHC.Types.False; '+'# -> jump loop_all_a2vd s'_a2vM; '-'# -> jump loop_all_a2vd s'_a2vM; '.'# -> jump loop_all_a2vd s'_a2vM; 'E'# -> jump loop_all_a2vd s'_a2vM; 'e'# -> jump loop_all_a2vd s'_a2vM } } in case GHC.Prim.leChar# '0'# c2_a2t0 of { __DEFAULT -> jump $j_s2yJ; 1# -> case GHC.Prim.leChar# c2_a2t0 '9'# of { __DEFAULT -> jump $j_s2yJ; 1# -> jump loop_all_a2vd s'_a2vM } } } } in join { -- the wrapper for the above worker $j_s2At :: Char -> Int -> Bool $j_s2At (w_s2Cs :: Char) (w_s2Ct :: Int) = case w_s2Cs of ww_s2Cv { GHC.Types.C# ww_s2Cw -> jump $w$j_s2Cy ww_s2Cw w_s2Ct } } in {- ... a large expression with three call-sites of $j_s2At -} }}} In the post-worker-wrapper simplification step we then immediately inline the wrappers into all of the call-sites, {{{ Considering inlining: $j_s2At arg infos [ValueArg, ValueArg] interesting continuation BoringCtxt some_benefit True is exp: True is work-free: True guidance ALWAYS_IF(arity=2,unsat_ok=True,boring_ok=False) ANSWER = YES Inlining done: $j_s2At Inlined fn: \ (w_s2Cs :: GHC.Types.Char) (w_s2Ct :: GHC.Types.Int) -> case w_s2Cs of { GHC.Types.C# ww_s2Cw -> jump $w$j ww_s2Cw w_s2Ct } Cont: ApplyToVal nodup (GHC.Types.C# (GHC.Prim.chr# (GHC.Prim.word2Int# r#))) ApplyToVal nodup (GHC.Types.I# (GHC.Prim.+# ipv 1#)) Stop[BoringCtxt] GHC.Types.Bool }}} and in each case inline the workers soon thereafter, {{{ Considering inlining: $w$j_s2Cy arg infos [NonTrivArg, ValueArg] interesting continuation BoringCtxt some_benefit True is exp: True is work-free: True guidance IF_ARGS [126 120] 190 0 discounted size = -35 ANSWER = YES Inlining done: $w$j Inlined fn: \ (ww_s2Cw :: GHC.Prim.Char#) (w_s2Ct :: GHC.Types.Int) -> join { $j_s2yJ :: GHC.Types.Bool $j_s2yJ = case ww_s2Cw of { __DEFAULT -> GHC.Types.False; '+'# -> case w_s2Ct of { GHC.Types.I# ww_X2Dh -> jump $wloop_all ww_X2Dh }; '-'# -> case w_s2Ct of { GHC.Types.I# ww_X2Dh -> jump $wloop_all ww_X2Dh }; '.'# -> case w_s2Ct of { GHC.Types.I# ww_X2Dh -> jump $wloop_all ww_X2Dh }; 'E'# -> case w_s2Ct of { GHC.Types.I# ww_X2Dh -> jump $wloop_all ww_X2Dh }; 'e'# -> case w_s2Ct of { GHC.Types.I# ww_X2Dh -> jump $wloop_all ww_X2Dh } } } in case GHC.Prim.leChar# '0'# ww_s2Cw of { __DEFAULT -> jump $j_s2yJ; 1# -> case GHC.Prim.leChar# ww_s2Cw '9'# of { __DEFAULT -> jump $j_s2yJ; 1# -> case w_s2Ct of { GHC.Types.I# ww_X2Dk -> jump $wloop_all ww_X2Dk } } } Cont: ApplyToVal nodup ww_s2Cw ApplyToVal nodup w_s2Ct Stop[BoringCtxt] GHC.Types.Bool }}} We consequently end up with two identical and one nearly identical copies of the same rather large block of code. It's not immediately clear to me how we can determine whether this latter duplication is fruitful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 13:58:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 13:58:30 -0000 Subject: [GHC] #13909: Misleading error message when partially applying a data type with a visible quantifier in its kind In-Reply-To: <050.a4022a3675301573ae65eedb2f8a013b@haskell.org> References: <050.a4022a3675301573ae65eedb2f8a013b@haskell.org> Message-ID: <065.46aab9fd1476152bf2c64cfd032ae5b8@haskell.org> #13909: Misleading error message when partially applying a data type with a visible quantifier in its kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13909 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => typecheck/should_fail/T13909 * status: new => closed * resolution: => fixed * milestone: => 8.4.1 Comment: As noted above, we can't really "fix" this any further without implementing support for impredicative types, so I consider this ticket to be resolved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 14:09:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 14:09:31 -0000 Subject: [GHC] #13963: Runtime representation confusingly displayed In-Reply-To: <051.c04a48884b20e6ae25a9e6eec8350f39@haskell.org> References: <051.c04a48884b20e6ae25a9e6eec8350f39@haskell.org> Message-ID: <066.88c6b72cd913e11ac993e8c22c07682b@haskell.org> #13963: Runtime representation confusingly displayed -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T13963 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => ghci/scripts/T13963 * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 14:17:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 14:17:18 -0000 Subject: [GHC] #14238: `:kind` suppresses visible dependent quantifiers by default in GHCi 8.2.1 Message-ID: <050.c719b82c47f85091cc937dd9178cacd2@haskell.org> #14238: `:kind` suppresses visible dependent quantifiers by default in GHCi 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Load this program into GHCi on 8.2.1 or later: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeInType #-} import Data.Kind data Foo (k :: Type) :: k -> Type where MkFoo :: Foo (k1 -> k2) f -> Foo k1 a -> Foo k2 (f a) }}} And ask it what the kind of `Foo` is: {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Ok, 1 module loaded. λ> :k Foo Foo :: k -> * }}} This is just plain wrong: the actual kind of `Foo` should be `forall k -> k -> *`. Normally, one can omit `forall`s from a kind signature, but this is a special case where we're using a //visible// forall. In other words, `forall k -> k -> *` is not the same as `k -> *`, as the former takes two arguments, whereas the latter takes one. A workaround is to force GHCi to come to its senses by explicitly enabling `-fprint-explicit-foralls`: {{{ λ> :set -fprint-explicit-foralls λ> :k Foo Foo :: forall k -> k -> * }}} This is actually a regression since GHC 8.0.2, since GHCi did the right thing by default then: {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Ok, modules loaded: Main. λ> :k Foo Foo :: forall k -> k -> Type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 14:30:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 14:30:57 -0000 Subject: [GHC] #14238: `:kind` suppresses visible dependent quantifiers by default in GHCi 8.2.1 In-Reply-To: <050.c719b82c47f85091cc937dd9178cacd2@haskell.org> References: <050.c719b82c47f85091cc937dd9178cacd2@haskell.org> Message-ID: <065.e15c8d0255ed7a002f88af8bc5a8a982@haskell.org> #14238: `:kind` suppresses visible dependent quantifiers by default in GHCi 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I agree! For terms we have a difference between `:info` (which takes a name) and `:type` (which takes an expression, and may involve instantiating and re- generalising). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 15:12:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 15:12:24 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks In-Reply-To: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> References: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> Message-ID: <061.7494695edebb119b7887233e2022f80e@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (CodeGen) | 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:D3973 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3973 Comment: Phab:D3973 implements the equivalence-up-to-alpha-renaming idea described above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 15:17:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 15:17:13 -0000 Subject: [GHC] #14222: Simple text fusion example results in rather duplicative code In-Reply-To: <046.acf3e774499e29f098fdca7495f195f8@haskell.org> References: <046.acf3e774499e29f098fdca7495f195f8@haskell.org> Message-ID: <061.d5fdd56d455a09c4e1b99c6454fc9395@haskell.org> #14222: Simple text fusion example results in rather duplicative code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: CSE Operating System: 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): simonpj, regarding comment:4: It seems to me like there is a real threat of introducing inappropriate sharing in such a scheme, given that full laziness already tends to produce quite some [[http://www.well-typed.com/blog/2016/09/sharing- conduit/|headaches]]. Do you think CSE is currently cautious enough to avoid these sorts of blowups? Perhaps we would want to be slightly less aggressive in floating out bindings which the compiler introduced during ANF-ization? Of course, this is all hypothetical; I suppose the best way to find out is to try. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 16:36:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 16:36:29 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism In-Reply-To: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> References: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> Message-ID: <063.3f410703fa86b19b700cd2639a117dd1@haskell.org> #13929: GHC panic with levity polymorphism -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vagarenko): Replying to [comment:12 goldfire]: > It looks to me that the runtime representation of `x` and `y` can't be known at compile time -- these arguments are levity-polymorphic, which is problematic. Do you see otherwise? `x, y :: f p` where `f :: Type -> Type` and `p :: Type` so they are always lifted, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 17:02:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 17:02:41 -0000 Subject: [GHC] #14237: -Wredundant-constraints incorrectly treats all type equality constraints as redundant In-Reply-To: <050.e3dc094564bbfbd54906e6f9a94f2531@haskell.org> References: <050.e3dc094564bbfbd54906e6f9a94f2531@haskell.org> Message-ID: <065.eefcbb2d16c3c3e0d4e691dca2bb8203@haskell.org> #14237: -Wredundant-constraints incorrectly treats all type equality constraints as redundant -------------------------------------+------------------------------------- Reporter: lexi.lambda | 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: #12700 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lexi.lambda): I disagree that this is “very similar” to #12700. This is a **regression** from GHC 8.0, which did not have this problem. The type equality in the example given in #12700 is arguably redundant, since the program would compile without it, but the examples I’ve given in this ticket will fail to compile if the equalities are removed. When compiling these with `-Wredundant-constraints` in GHC 8.0.2, no warning is produced. In GHC 8.2.1, a warning ''is'' produced. I’m not sure why this happens, but it seems like a real step backwards, and it’s much more severe than #12700. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 17:41:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 17:41:30 -0000 Subject: [GHC] #14239: Let -fspecialise-aggressively respect NOINLINE (or NOSPECIALISABLE?) Message-ID: <054.3fc353cace424f353779f664cd491f56@haskell.org> #14239: Let -fspecialise-aggressively respect NOINLINE (or NOSPECIALISABLE?) -------------------------------------+------------------------------------- Reporter: | Owner: (none) MikolajKonarski | Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- First, let me explain the context. By defuault GHC specialises very few functions and the programmer is expected to enumerate additional functions to specialise (e.g., with INLINABLE). This is problematic if the functions are defined in libraries, not in the user code. Also, in some kinds of code it leads to INLINABLE on every functions (because missing even just one breaks the chain). The problems are described in other tickets. With `-fspecialise-aggressively` and `-fexpose-all-unfoldings`, the default is reversed. Everything (even functions from libraries, as long as they have unfoldings available) is specialized and the user only needs to enumerate exceptions. Unfortunately, he can't. I think (in particular from experiments with `-Wall-missed- specialisations`), in the presence of `-fexpose-all-unfoldings`, the `-fspecialise-aggressively` option happily specialises functions marked `NOINLINE` (and so with `Inline:,` in the .hi file). Consequently, the user has no way to be selective wrt specialisation when using the specialize-often default. If we want to gradually disentangle INLINE and SPECIALIZE (e.g., rename INLINABLE to SPECIALISABLE), perhaps the pragma to use should be NOSPECIALISABLE. Perhaps it also makes sense to leave the current functionality, for experimenting with whole modules, but I'd rename it to `-fforce-specialise-aggressively`, because it overrides the obvious user intent. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 17:47:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 17:47:44 -0000 Subject: [GHC] #14239: Let -fspecialise-aggressively respect NOINLINE (or NOSPECIALISABLE?) In-Reply-To: <054.3fc353cace424f353779f664cd491f56@haskell.org> References: <054.3fc353cace424f353779f664cd491f56@haskell.org> Message-ID: <069.e997852edf6ba687615fd173ba6bc3e1@haskell.org> #14239: Let -fspecialise-aggressively respect NOINLINE (or NOSPECIALISABLE?) -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 17:49:14 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 17:49:14 -0000 Subject: [GHC] #12537: Parallel cabal builds Segmentation Fault on PowerPC 64-bit In-Reply-To: <048.e821713d1c06a4d751fa396103744323@haskell.org> References: <048.e821713d1c06a4d751fa396103744323@haskell.org> Message-ID: <063.482ca1eb67833cbd08bb3fad7c3bfcec@haskell.org> #12537: Parallel cabal builds Segmentation Fault on PowerPC 64-bit -------------------------------------+------------------------------------- Reporter: michelmno | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: 12469 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * owner: (none) => trommler Comment: I found an issue in the implementation of atomic read and atomic write operations in ghc-prim. I am working on a fix for powerpc64 and powerpc64le. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 17:52:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 17:52:45 -0000 Subject: [GHC] #14239: Let -fspecialise-aggressively respect NOINLINE (or NOSPECIALISABLE?) In-Reply-To: <054.3fc353cace424f353779f664cd491f56@haskell.org> References: <054.3fc353cace424f353779f664cd491f56@haskell.org> Message-ID: <069.205bc3343eb2c5005066c9c037feac03@haskell.org> #14239: Let -fspecialise-aggressively respect NOINLINE (or NOSPECIALISABLE?) -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: feature request | Status: new 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 simonpj): * keywords: Inlining => Comment: I think you are suggesting that a user can write one (and only one) of * INLINE: please inline what I write, at every call site * SPECIALISABLE (currently written INLINABLE): please specialise what I write, at every call site * NOSPECIALISABLE: please do not specialise this function (even if it would otherwise be easy to do so) * NOINLINE: please do not inline or specialise this function (even if it would otherwise be easy to do so). That is, hide its implementation from the caller. That would not be too hard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 18:09:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 18:09:49 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism In-Reply-To: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> References: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> Message-ID: <063.efa9716bcb6eee022e1b28a5806f6a30@haskell.org> #13929: GHC panic with levity polymorphism -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The problem is the result type of `gunbox x`. Namely, we have {{{#!hs class GUnbox (f :: Type -> Type) (r :: RuntimeRep) where type GUnboxed f r :: TYPE r gunbox :: f p -> GUnboxed f r }}} and {{{#!hs f :: Type -> Type p :: Type x :: f p }}} therefore {{{#!hs gunbox x :: GUnboxed f rf }}} Which is levity polymorphic. My understanding is that this wouldn't be the problem if this were at the head of the RHS; however, in this case we need to build an unboxed tuple from it, which is problematic. In short: returning levity polymorphic things generally isn't a problem. However, the moment we actually need to manipulate such a value we have a problem. I find it helpful to consider why this is from the standpoint of a concrete operational model. You can think of the `RuntimeRep` of a function's return type as being a description of which machine register(s) the result can be found in. In the case that we have a function like, {{{#!hs ($) :: forall (r :: RuntimeRep) (a :: TYPE r) (b :: Type). (b -> a) -> b -> a f $ x = f x }}} The `($)` function never needs to //do// anything with the levity- polymorphic value: it simply sets up the call to `f` and jumps. In fact, flow of control will never even return to `($)` after this jump. Consequently, the code that we generate for `($)` can be entirely agnostic to the `RuntimeRep` that it is used at. Now let's consider at your function, {{{#!hs gunbox :: (GUnbox f rf, GUnbox g rg) => (f :*: g) -> (# GUnboxed f rf, GUnboxed g rg #) gunbox (x :*: y) = (# gunbox x, gunbox y #) }}} Specifically, let's consider the case where `f ~ Double` and `g ~ Maybe Int` (with instances such that `rf ~ DoubleRep` and `rg ~ LiftedPtrRep`). In this case `gunbox` will need to first evaluate `gunbox x`, which will save its result in one of the machine's floating point registers. Then it will need to evaluate `gunbox y`, which will save its result in a pointer register. We can then return, having "constructed" our unboxed tuple. This case was easy as there was no "overlap" between the two registers used to return the result. However, let's consider another case, where `f ~ Double` and `g ~ Double` (therefore `rf ~ DoubleRep` and `rg ~ DoubleRep`). In this case `gunbox` will need to evaluate both `gunbox x` and `gunbox y`, but it must take care to move the result of one out of the way before evaluating the other since both will return their result in the same floating point register. This, of course, means that `gunbox` would need to behave differently depending upon the `RuntimeRep`s that it was working with. Our code generation strategy does not currently allow for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 18:16:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 18:16:48 -0000 Subject: [GHC] #14239: Let -fspecialise-aggressively respect NOINLINE (or NOSPECIALISABLE?) In-Reply-To: <054.3fc353cace424f353779f664cd491f56@haskell.org> References: <054.3fc353cace424f353779f664cd491f56@haskell.org> Message-ID: <069.24f6c5f4e3bd81a29015309e6e87d4d4@haskell.org> #14239: Let -fspecialise-aggressively respect NOINLINE (or NOSPECIALISABLE?) -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: feature request | Status: new 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 MikolajKonarski): Yes, I would be completely satisfied by that and a convention that all GHC options without `-fforce-` respect that (currently only `-fspecialise- aggressively` doesn't, I think). In particular I'd leave untouched `-fexpose-all-unfoldings`, because it's not about inlining nor specialisation, so it doesn't need to respect the pragmas. It's about unfoldings, or rather it's close to a `-fignore-the- split-into-modules-from-affecting-performance-which-puzzles-users` option (and it's cheap and also useful for experimenting). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 19:37:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 19:37:22 -0000 Subject: [GHC] #13870: Empty record construction for record-less constructor gives surprising runtime error (and surprisingly few warnings) In-Reply-To: <050.fc98e01b762a6c8eb62abc4b92b4d47b@haskell.org> References: <050.fc98e01b762a6c8eb62abc4b92b4d47b@haskell.org> Message-ID: <065.291a153df259d199b051ee1a04b2b97c@haskell.org> #13870: Empty record construction for record-less constructor gives surprising runtime error (and surprisingly few warnings) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | deSugar/should_compile/T13870 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3940 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9e227bb19b8ceb129ce28e72aa070b3ba85accf7/ghc" 9e227bb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9e227bb19b8ceb129ce28e72aa070b3ba85accf7" Fix missing fields warnings in empty record construction, fix #13870 Test Plan: make test TEST=T13870 Reviewers: RyanGlScott, austin, bgamari, mpickering Reviewed By: mpickering Subscribers: mpickering, rwbarton, thomie, RyanGlScott Tags: #ghc GHC Trac Issues: #13870 Differential Revision: https://phabricator.haskell.org/D3940 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 19:37:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 19:37:22 -0000 Subject: [GHC] #14189: Renamer does not preserve location for IEThingWith list items In-Reply-To: <044.0c99d438de6c1244d5aee79758fc528d@haskell.org> References: <044.0c99d438de6c1244d5aee79758fc528d@haskell.org> Message-ID: <059.9ec19e3638c7878efc7b04316b9e06fb@haskell.org> #14189: Renamer does not preserve location for IEThingWith list items -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3968 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9498c50ef5af2680305e0aaea6f32439cacc3da0/ghc" 9498c50/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9498c50ef5af2680305e0aaea6f32439cacc3da0" Renamer now preserves location for IEThingWith list items Prior to this, in the RenamedSource for module Renaming.RenameInExportedType ( MyType (NT) ) where data MyType = MT Int | NT The (NT) was given the location of MyType earlier on the line in the export list. Also the location was discarded for any field labels, and replaced with a `noLoc`. Test Plan: ./validate Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14189 Differential Revision: https://phabricator.haskell.org/D3968 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 19:37:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 19:37:22 -0000 Subject: [GHC] #14228: PatternSynonyms Non-exhaustive with UnboxedSums In-Reply-To: <045.20b2cde42b5eb75c44e10e92ba8e9b86@haskell.org> References: <045.20b2cde42b5eb75c44e10e92ba8e9b86@haskell.org> Message-ID: <060.a49c9ef24e0d1594914bdee814b6bc33@haskell.org> #14228: PatternSynonyms Non-exhaustive with UnboxedSums -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: UnboxedSums, | PatternSynonyms 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:D3951 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f4d50a0ec0d23dbcd61a014c8a773030c8fe310d/ghc" f4d50a0e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f4d50a0ec0d23dbcd61a014c8a773030c8fe310d" Fix #14228 by marking SumPats as non-irrefutable `isIrrefutableHsPat` should always return `False` for unboxed sum patterns (`SumPat`s), since they always have at least one other corresponding pattern of the same arity (since the minimum arity for a `SumPat` is 2). Failure to do so causes incorrect code to be generated for pattern synonyms that use unboxed sums, as shown in #14228. Test Plan: make test TEST=T14228 Reviewers: austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #14228 Differential Revision: https://phabricator.haskell.org/D3951 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 19:37:59 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 19:37:59 -0000 Subject: [GHC] #14189: Renamer does not preserve location for IEThingWith list items In-Reply-To: <044.0c99d438de6c1244d5aee79758fc528d@haskell.org> References: <044.0c99d438de6c1244d5aee79758fc528d@haskell.org> Message-ID: <059.5df3fab5139bd88add60f2f74c6e1c9b@haskell.org> #14189: Renamer does not preserve location for IEThingWith list items -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: merge Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3968 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 19:38:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 19:38:34 -0000 Subject: [GHC] #14228: PatternSynonyms Non-exhaustive with UnboxedSums In-Reply-To: <045.20b2cde42b5eb75c44e10e92ba8e9b86@haskell.org> References: <045.20b2cde42b5eb75c44e10e92ba8e9b86@haskell.org> Message-ID: <060.e46c7d24ce021e4a4eb311442cf3b79e@haskell.org> #14228: PatternSynonyms Non-exhaustive with UnboxedSums -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: UnboxedSums, | PatternSynonyms 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:D3951 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 19:39:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 19:39:41 -0000 Subject: [GHC] #13870: Empty record construction for record-less constructor gives surprising runtime error (and surprisingly few warnings) In-Reply-To: <050.fc98e01b762a6c8eb62abc4b92b4d47b@haskell.org> References: <050.fc98e01b762a6c8eb62abc4b92b4d47b@haskell.org> Message-ID: <065.0fec548adee72f18aae06b9ec99b92c5@haskell.org> #13870: Empty record construction for record-less constructor gives surprising runtime error (and surprisingly few warnings) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: sighingnow Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | deSugar/should_compile/T13870 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3940 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.4.1 Comment: Given that this isn't a regression in 8.2 I think we'll wait until 8.4 to release this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 21:10:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 21:10:33 -0000 Subject: =?utf-8?b?W0dIQ10gIzE0MjQwOiBDU0XigJlpbmcgdy934oCZZWQgY29kZSBy?= =?utf-8?q?egresses_program_runtime?= Message-ID: <046.5c37d5e63156613df1c04fdc18ec8c04@haskell.org> #14240: CSE’ing w/w’ed code regresses program runtime -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- Commit changeset:fe04f378/ghc, which fixed #14186, causes two runtime regressions: {{{ nofib/time/integer 1.529 + 4.19% 1.593 seconds nofib/time/lambda 1.041 + 7.3% 1.117 seconds }}} Sigh. I guess it up to me to track that one down. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 21:10:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 21:10:45 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDI0MDogQ1NF4oCZaW5nIHcvd+KAmWVkIGNv?= =?utf-8?q?de_regresses_program_runtime?= In-Reply-To: <046.5c37d5e63156613df1c04fdc18ec8c04@haskell.org> References: <046.5c37d5e63156613df1c04fdc18ec8c04@haskell.org> Message-ID: <061.a97962478dcaf88d7f5451a9874d1077@haskell.org> #14240: CSE’ing w/w’ed code regresses program runtime -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new 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 nomeata): * owner: (none) => nomeata -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 15 22:06:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Sep 2017 22:06:34 -0000 Subject: [GHC] #13391: PolyKinds is more permissive in GHC 8 In-Reply-To: <047.7921462df1c636dc7a1bfe3d9149887d@haskell.org> References: <047.7921462df1c636dc7a1bfe3d9149887d@haskell.org> Message-ID: <062.bf62abd1f21370cf430b7bd338b44387@haskell.org> #13391: PolyKinds is more permissive in GHC 8 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3859 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): One non-obvious implication of this change is that program like the `KindEqualities` test from the testsuite will now require that users enable `TypeInType` and consequently will manually need to quantify over the kind variables of their tycon's signature. For instance, currently `KindEqualities` has, {{{#!hs data TyRep :: k -> * where TyInt :: TyRep Int -- etc. }}} This needs to become, {{{#!hs data TyRep :: forall k. k -> * where TyInt :: TyRep Int -- etc. }}} This is documented in Phab:D3966. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 16 01:26:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Sep 2017 01:26:16 -0000 Subject: [GHC] #6084: Add stg_ap_pnnv and related call patterns In-Reply-To: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> References: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> Message-ID: <064.df480964c8768f9b491a6d881014318f@haskell.org> #6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------- Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8313 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * Attachment "T6084.cmm" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 16 04:28:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Sep 2017 04:28:42 -0000 Subject: [GHC] #6084: Add stg_ap_pnnv and related call patterns In-Reply-To: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> References: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> Message-ID: <064.3be7dc0b8f13fbaade438a8b6a8867a5@haskell.org> #6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------- Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8313 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): cmm, as per `-ddump-cmm`. I believe the relevant part is {{{ ==================== Output Cmm ==================== [section ""relreadonly" . S4QA_srt" { S4QA_srt: const Main.q1_closure; }, section ""data" . Main.p_closure" { Main.p_closure: const Main.p_info; const 0; }, Main.p_slow() // [R1] { info_tbl: [] stack_info: arg_space: 0 updfr_space: Nothing } {offset c4Qt: // global D2 = F64[Sp + 16]; F1 = F32[Sp + 8]; R2 = I64[Sp]; R1 = R1; Sp = Sp + 24; call Main.p_info(D2, F1, R2, R1) args: 8, res: 0, upd: 8; } }, Main.p_entry() // [] { info_tbl: [(c4Qx, label: Main.p_info rep:HeapRep static { Fun {arity: 3 fun_type: ArgGen [True, True, True]} })] stack_info: arg_space: 0 updfr_space: Nothing } {offset c4Qx: // global R1 = Main.q1_closure; call (I64[R1])(R1) args: 8, res: 0, upd: 8; } }] }}} However, my Cmm knowledge is rather limited. The llvm backend then does: {{{ pprLlvmCmmDecl (CmmProc mb_info entry_lbl live (ListGraph blks)) = do let lbl = case mb_info of Nothing -> entry_lbl Just (Statics info_lbl _) -> info_lbl link = if externallyVisibleCLabel lbl then ExternallyVisible else Internal lmblocks = map (\(BasicBlock id stmts) -> LlvmBlock (getUnique id) stmts) blks funDec <- llvmFunSig live lbl link dflags <- getDynFlags let buildArg = fsLit . showSDoc dflags . ppPlainName funArgs = map buildArg (llvmFunArgs dflags live) funSect = llvmFunSection dflags (decName funDec) -- generate the info table prefix <- case mb_info of Nothing -> return Nothing Just (Statics _ statics) -> do infoStatics <- mapM genData statics let infoTy = LMStruct $ map getStatType infoStatics return $ Just $ LMStaticStruc infoStatics infoTy let fun = LlvmFunction funDec funArgs llvmStdFunAttrs funSect prefix lmblocks name = decName $ funcDecl fun defName = name `appendFS` fsLit "$def" funcDecl' = (funcDecl fun) { decName = defName } fun' = fun { funcDecl = funcDecl' } funTy = LMFunction funcDecl' funVar = LMGlobalVar name (LMPointer funTy) link Nothing Nothing Alias defVar = LMGlobalVar defName (LMPointer funTy) (funcLinkage funcDecl') (funcSect fun) (funcAlign funcDecl') Alias alias = LMGlobal funVar (Just $ LMBitc (LMStaticPointer defVar) (LMPointer $ LMInt 8)) return (ppLlvmGlobal alias $+$ ppLlvmFunction fun', []) -- ... llvmFunSig :: LiveGlobalRegs -> CLabel -> LlvmLinkageType -> LlvmM LlvmFunctionDecl llvmFunSig live lbl link = do lbl' <- strCLabel_llvm lbl llvmFunSig' live lbl' link llvmFunSig' :: LiveGlobalRegs -> LMString -> LlvmLinkageType -> LlvmM LlvmFunctionDecl llvmFunSig' live lbl link = do let toParams x | isPointer x = (x, [NoAlias, NoCapture]) | otherwise = (x, []) dflags <- getDynFlags return $ LlvmFunctionDecl lbl link (llvmGhcCC dflags) LMVoid FixedArgs (map (toParams . getVarType) (llvmFunArgs dflags live)) (llvmFunAlign dflags) -- ... -- | A Function's arguments llvmFunArgs :: DynFlags -> LiveGlobalRegs -> [LlvmVar] llvmFunArgs dflags live = map (lmGlobalRegArg dflags) (filter isPassed (activeStgRegs platform)) where platform = targetPlatform dflags isLive r = not (isSSE r) || r `elem` alwaysLive || r `elem` live isPassed r = not (isSSE r) || isLive r isSSE (FloatReg _) = True isSSE (DoubleReg _) = True isSSE (XmmReg _) = True isSSE (YmmReg _) = True isSSE (ZmmReg _) = True isSSE _ = False -- ... -- | A list of STG Registers that should always be considered alive alwaysLive :: [GlobalReg] alwaysLive = [BaseReg, Sp, Hp, SpLim, HpLim, node] }}} As the set of live registers for `Main.p_info` (`Main.p_entry()`) is empty, we end up generating the default signature for {{{ ["BaseReg","Sp","Hp","R1","R2","R3","R4","R5","R6","SpLim"] }}} only, when we supposedly would want to have included `F1` and `D2` as well. On the other hand, I don't see where we'd use those in the body of `p_entry`. And thus why we'd want to pass them in the first place? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 16 08:53:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Sep 2017 08:53:45 -0000 Subject: [GHC] #14241: Pattern synonyms defined through other pattern synonyms produce `impossible happened` Message-ID: <047.0b921412e877076981400f25a0354157@haskell.org> #14241: Pattern synonyms defined through other pattern synonyms produce `impossible happened` ---------------------------------------+------------------------------- Reporter: Heimdell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: PatternSynonyms | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+------------------------------- This module content (Bug.hs) {{{#!hs {-# language PatternSynonyms #-} data A a = A a pattern B a = A a pattern C a = B a }}} causes ghci/runhaskell to fail: {{{ > :l Bug [1 of 1] Compiling Main ( Bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): kindPrimRep.go rep_a1r0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} When using ghc everything compiles and even works, so adding the code {{{#!hs main = do let C a = A 1 print a }}} produced executable that prints "1". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 16 09:21:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Sep 2017 09:21:52 -0000 Subject: [GHC] #14241: Pattern synonyms defined through other pattern synonyms produce `impossible happened` in ghci/runhaskell (was: Pattern synonyms defined through other pattern synonyms produce `impossible happened`) In-Reply-To: <047.0b921412e877076981400f25a0354157@haskell.org> References: <047.0b921412e877076981400f25a0354157@haskell.org> Message-ID: <062.af9020bd19dea3167082ca0d1ba2af85@haskell.org> #14241: Pattern synonyms defined through other pattern synonyms produce `impossible happened` in ghci/runhaskell -------------------------------+--------------------------------------- Reporter: Heimdell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: PatternSynonyms Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | 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 Sep 16 11:27:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Sep 2017 11:27:24 -0000 Subject: [GHC] #6084: Add stg_ap_pnnv and related call patterns In-Reply-To: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> References: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> Message-ID: <064.d4dcd8878a6a0acb312b0e4e673357e4@haskell.org> #6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------- Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8313 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > On the other hand, I don't see where we'd use those in the body of `p_entry`. And thus why we'd want to pass them in the first place? Because this is what the calling convention that the function exposes. If the functions in `T6084` didn't have `NOINLINE` pragmas then we would have eliminated these dead arguments during core2core. However, since they do we are forced to expose precisely the calling convention that the user wrote. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 16 11:55:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Sep 2017 11:55:33 -0000 Subject: [GHC] #14221: yaml-0.8.23.3 fails to build with -g In-Reply-To: <046.9dadad43b611bdb3c19cc87ee92d4f08@haskell.org> References: <046.9dadad43b611bdb3c19cc87ee92d4f08@haskell.org> Message-ID: <061.9c218f57bf2d55ab284cb0b6d2ea4223@haskell.org> #14221: yaml-0.8.23.3 fails to build with -g -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | 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:D3977 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3977 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 16 11:58:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Sep 2017 11:58:22 -0000 Subject: [GHC] #10601: GHC should be distributed with debug symbols In-Reply-To: <046.ddcd45dcc3f972fc17c42b77b9184272@haskell.org> References: <046.ddcd45dcc3f972fc17c42b77b9184272@haskell.org> Message-ID: <061.5333301901f0ad227c097181970b4685@haskell.org> #10601: GHC should be distributed with debug symbols -------------------------------------+------------------------------------- Reporter: bitonic | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Build System | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9894 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: The GHC 8.2.1 includes a binary distribution which enables DWARF debugging support and includes the necessary debug information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 16 12:02:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Sep 2017 12:02:08 -0000 Subject: [GHC] #14221: yaml-0.8.23.3 fails to build with -g In-Reply-To: <046.9dadad43b611bdb3c19cc87ee92d4f08@haskell.org> References: <046.9dadad43b611bdb3c19cc87ee92d4f08@haskell.org> Message-ID: <061.9ba5e57297b3f94e0be656990321429d@haskell.org> #14221: yaml-0.8.23.3 fails to build with -g -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | 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:D3977 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: niteria (added) Comment: Bartosz, I believe you reported encountering this issue while using `-g` at some point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 16 12:36:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Sep 2017 12:36:43 -0000 Subject: [GHC] #14242: Ticks and join points don't play well Message-ID: <046.44b5c9487253d57677726ed143b46a84@haskell.org> #14242: Ticks and join points don't play well -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the presence of ticks appear to inhibit our ability to discover join points as described by this comment in `OccurAnal.occAnal`, {{{#!hs usage_lam = markAllNonTailCalled (markAllInsideLam usage) -- TODO There may be ways to make ticks and join points play -- nicer together, but right now there are problems: -- let j x = ... in tick (j 1) -- Making j a join point may cause the simplifier to drop t -- (if the tick is put into the continuation). So we don't -- count j 1 as a tail call. }}} This causes spurious warnings when compiling with a `DEBUG` compiler and `-g` or profiling enabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 16 12:55:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Sep 2017 12:55:23 -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.5e4090ff9ce331922b01b51786ec75bf@haskell.org> #14242: Ticks and join points don't play well -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * milestone: => 8.4.1 Comment: The current logic is arguably far too conservative in the particular case of source notes, which generally shouldn't interfere with optimization. This case is addressed by Phab:D3978. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 16 13:52:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Sep 2017 13:52:06 -0000 Subject: [GHC] #14221: yaml-0.8.23.3 fails to build with -g In-Reply-To: <046.9dadad43b611bdb3c19cc87ee92d4f08@haskell.org> References: <046.9dadad43b611bdb3c19cc87ee92d4f08@haskell.org> Message-ID: <061.96f6e0bf42b96d153e408b86bde925f9@haskell.org> #14221: yaml-0.8.23.3 fails to build with -g -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | 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:D3977 Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): That looks exactly like my problem, thanks for the ping and the fix! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 16 17:23:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Sep 2017 17:23:50 -0000 Subject: [GHC] #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) In-Reply-To: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> References: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> Message-ID: <065.7448f4d50d8bac12244b7d6290f20554@haskell.org> #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: carlostome Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: | 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 carlostome): * owner: (none) => carlostome -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 16 18:21:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Sep 2017 18:21:34 -0000 Subject: [GHC] #14241: Pattern synonyms defined through other pattern synonyms produce `impossible happened` in ghci/runhaskell In-Reply-To: <047.0b921412e877076981400f25a0354157@haskell.org> References: <047.0b921412e877076981400f25a0354157@haskell.org> Message-ID: <062.18ca76801370c675ba8b7eb705d8205b@haskell.org> #14241: Pattern synonyms defined through other pattern synonyms produce `impossible happened` in ghci/runhaskell -------------------------------+--------------------------------------- Reporter: Heimdell | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: PatternSynonyms Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #12007 | Differential Rev(s): Wiki Page: | -------------------------------+--------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #12007 Comment: Thanks for the the bug report. This is a duplicate of #12007, which has been fixed since GHC 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 16 22:46:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Sep 2017 22:46:58 -0000 Subject: [GHC] #14243: GHC doesn't add constraint when deriving Message-ID: <051.c8a69e4b23eafe74b02bc02a195cf182@haskell.org> #14243: GHC doesn't add constraint when deriving -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I can't remember if this was intended, but GHC cannot `derive newtype Functor` or `derive stock Functor` for `WGeneric` even if it knows the constraint to add (I have `FlexibleInstances` enabled) {{{#!hs import GHC.Generic -- • Could not deduce (Functor (Rep1 f)) -- arising from the 'deriving' clause of a data type declaration -- from the context: Functor f -- bound by the deriving clause for ‘Functor (WGeneric f)’ -- at /home/baldur/hs/074.hs:63:5-11 -- Possible fix: -- use a standalone 'deriving instance' declaration, -- so you can specify the instance context yourself newtype WGeneric f a = WGeneric (Sum (Rep1 f) f a) deriving newtype Functor }}} but either of these works {{{#!hs deriving newtype instance (Functor f, Functor (Rep1 f)) => Functor (WGeneric f) deriving stock instance (Functor f, Functor (Rep1 f)) => Functor (WGeneric f) }}} Could GHC add the inferred `Functor (Rep1 f)`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 16 22:59:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Sep 2017 22:59:33 -0000 Subject: [GHC] #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) In-Reply-To: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> References: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> Message-ID: <065.cc7754dc22cce26c21f87d7a25c9c159@haskell.org> #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: carlostome Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carlostome): I've found that this error is caused by the order of the arguments to `tcMatchTy` in the following code. {{{ mkOneConFull x con = do let res_ty = idType x (univ_tvs, ex_tvs, eq_spec, thetas, _req_theta , arg_tys, con_res_ty) = conLikeFullSig con tc_args = tyConAppArgs res_ty subst1 = case con of RealDataCon {} -> zipTvSubst univ_tvs tc_args PatSynCon {} -> expectJust "mkOneConFull" (tcMatchTy con_res_ty res_ty) ... }}} Adding some debugging information I noticed that the call that makes `tcMatchTy` return `Nothing` and therefore trigger the error it is done with the following arguments (as outputed with -dppr-debug): {{{ con_res_ty = main:T14135.Foo{tc r9} ghc-prim:GHC.Types.Int{(w) tc 3u} res_ty = main:T14135.Foo{tc r9} (a{tv aWz} [tv] :: *) }}} As far as I understand the problem stands because `tcMatchTy` expects the first argument to be a kind of template type that will get instantiated to match the second argument. However, it is clear that there is no substitution s such that s(Int) = a. If we change the call to `tcMatchTy res_ty con_res_ty` then the example program compiles fine but when trying to validate, ghc is not able to build anymore `Data.Typeable.Internal` because it triggers the exactly same error. I have found that by substituting `tcMatchTy` by `tcUnifyTy` we solve the full problem, however, I don't know if `tcMatchTy` should be prefered over `tcUnify` or not (if it makes a semantic difference). Any insight on this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 16 23:06:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Sep 2017 23:06:42 -0000 Subject: [GHC] #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) In-Reply-To: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> References: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> Message-ID: <065.2913be06f708df83eab4ee28cc703a15@haskell.org> #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: carlostome Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: | 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): Phab:D3981 Wiki Page: | -------------------------------------+------------------------------------- Changes (by carlostome): * differential: => Phab:D3981 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 17 00:32:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Sep 2017 00:32:02 -0000 Subject: [GHC] #11721: GADT-syntax data constructors don't work well with TypeApplications In-Reply-To: <047.d3cda57aa918919c3cdf02eb21c0a581@haskell.org> References: <047.d3cda57aa918919c3cdf02eb21c0a581@haskell.org> Message-ID: <062.d816c607d5d978b8b84095e09385198e@haskell.org> #11721: GADT-syntax data constructors don't work well with TypeApplications -------------------------------------+------------------------------------- Reporter: goldfire | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13848, #12025 | Differential Rev(s): Phab:D3687 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D3687 Comment: Phab:D3687 is now ready for review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 17 02:24:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Sep 2017 02:24:35 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism In-Reply-To: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> References: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> Message-ID: <063.7dc61b33f1629afe4a75122d05fb30c4@haskell.org> #13929: GHC panic with levity polymorphism -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Great explanation in comment:14. Yes, my comment:12 is wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 17 02:41:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Sep 2017 02:41:02 -0000 Subject: [GHC] #14036: GHCi HEAD segfaults upon startup with a prof build In-Reply-To: <050.97d82502cca9748fd13eeb16499d7f64@haskell.org> References: <050.97d82502cca9748fd13eeb16499d7f64@haskell.org> Message-ID: <065.dc54571c9dd79994cd2ad68fd3c89f2f@haskell.org> #14036: GHCi HEAD segfaults upon startup with a prof build -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3983 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D3983 Comment: I found the problem. {{{#!hs arity <= TAG_MASK ? obj + arity : obj, }}} That addition is ''pointer'' addition, which changes all the wrong bits. We need to cast the `obj` to an integer before adding. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 17 02:42:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Sep 2017 02:42:07 -0000 Subject: [GHC] #14238: `:kind` suppresses visible dependent quantifiers by default in GHCi 8.2.1 In-Reply-To: <050.c719b82c47f85091cc937dd9178cacd2@haskell.org> References: <050.c719b82c47f85091cc937dd9178cacd2@haskell.org> Message-ID: <065.5962e6cdbd9ae1c1d88d347f6c12ba81@haskell.org> #14238: `:kind` suppresses visible dependent quantifiers by default in GHCi 8.2.1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Agreed as well. The ticket has TypeInType on it already, and so I'll get to it in due course, unless someone grabs it sooner. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 17 02:48:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Sep 2017 02:48:12 -0000 Subject: [GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> References: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> Message-ID: <059.a286b0dd3aee6847d7f76dea17a9e4b7@haskell.org> #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 (Linker) | 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): Phab:D3983 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D3983 Comment: I think I have a fix for #14036. Hopefully that fixes this too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 17 04:09:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Sep 2017 04:09:21 -0000 Subject: [GHC] #14199: Document Type.Reflection better (Fun and Con') In-Reply-To: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> References: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> Message-ID: <060.01b51073d349c82ba2028abb0151cade@haskell.org> #14199: Document Type.Reflection better (Fun and Con') -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: bug | Status: merge Priority: high | Milestone: 8.2.2 Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3943 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I think it would be helpful to explain, in the documentation of `Con'` and `App`, just what separates the variables that can be separated with `App` from the ones that can be separated with `Con'`. For example, given {{{#!hs data Foo j k (l :: j -> k) }}} one might naively expect something like `App (App (App (Con Foo) Bool) Type) SBool`, but that is not so. Going into a bit more detail about that would be helpful, and it might even be worth mentioning ''why'' the naive guess is wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 17 04:19:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Sep 2017 04:19:32 -0000 Subject: [GHC] #14036: GHCi HEAD segfaults upon startup with a prof build In-Reply-To: <050.97d82502cca9748fd13eeb16499d7f64@haskell.org> References: <050.97d82502cca9748fd13eeb16499d7f64@haskell.org> Message-ID: <065.18e12e4edd2b0cd0661b17aa01ebae56@haskell.org> #14036: GHCi HEAD segfaults upon startup with a prof build -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3983 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"60a3f11ff4b7e239a273498812fd9d31f6775726/ghc" 60a3f11f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="60a3f11ff4b7e239a273498812fd9d31f6775726" Fix pointer tagging mistake f9c6d53fe997f1c560cda6f346f4b201711df37c led to #14036. The problem turned out to be rather simple: the `obj` pointer was being tagged using `obj + arity`. Because this is C, that's done with *pointer arithmetic*, which is not at all what we want. Add appropriate casts. Reviewers: austin, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14036 Differential Revision: https://phabricator.haskell.org/D3983 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 17 04:26:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Sep 2017 04:26:35 -0000 Subject: [GHC] #14036: GHCi HEAD segfaults upon startup with a prof build In-Reply-To: <050.97d82502cca9748fd13eeb16499d7f64@haskell.org> References: <050.97d82502cca9748fd13eeb16499d7f64@haskell.org> Message-ID: <065.0f0eb37419114e80c629a592893eeb54@haskell.org> #14036: GHCi HEAD segfaults upon startup with a prof build -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3983 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 17 04:27:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Sep 2017 04:27:21 -0000 Subject: [GHC] #14036: GHCi HEAD segfaults upon startup with a prof build In-Reply-To: <050.97d82502cca9748fd13eeb16499d7f64@haskell.org> References: <050.97d82502cca9748fd13eeb16499d7f64@haskell.org> Message-ID: <065.f84edf428ae769cdc958cfc649b2fd52@haskell.org> #14036: GHCi HEAD segfaults upon startup with a prof build -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3983 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 17 04:33:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Sep 2017 04:33:21 -0000 Subject: [GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> References: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> Message-ID: <059.908bbfc0211bc542f33957aed889da27@haskell.org> #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 (Linker) | 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): Phab:D3983 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): The commit bgamari identified was definitely problematic, and definitely caused #14036. I just committed a fix for that. However, if the problem in this ticket occurs in the released GHC 8.2.1 (as the ticket text suggests), then there must be something else wrong. pacak, were you using released 8.2.1, or something later? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 17 04:33:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Sep 2017 04:33:36 -0000 Subject: [GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> References: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> Message-ID: <059.e79261057f068ad4eb614fcf9b4e9008@haskell.org> #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 (Linker) | 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): Phab:D3983 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 17 04:38:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Sep 2017 04:38:20 -0000 Subject: [GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> References: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> Message-ID: <059.2f823f06d076d74953977f79684fa91c@haskell.org> #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 (Linker) | 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): Phab:D3983 Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): I'm pretty sure I was able to replicate on downloaded 8.2.1 version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 17 04:42:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Sep 2017 04:42:30 -0000 Subject: [GHC] #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO In-Reply-To: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> References: <044.b3cd3c1bf232141df45df0c09168c130@haskell.org> Message-ID: <059.8a83669c0a40e127d0369fa94637fcbf@haskell.org> #14115: GHC segfaults trying to use TH code when ghc is compiled as DYNAMIC_GHC_PROGRAMS=NO -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 (Linker) | 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): Phab:D3983 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Oh, I just saw your earlier comment. We'll have to try reproducing with the very latest HEAD, and if we need to bisect again, stay in an earlier timeframe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 17 10:47:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Sep 2017 10:47:02 -0000 Subject: [GHC] #12537: Parallel cabal builds Segmentation Fault on PowerPC 64-bit In-Reply-To: <048.e821713d1c06a4d751fa396103744323@haskell.org> References: <048.e821713d1c06a4d751fa396103744323@haskell.org> Message-ID: <063.e3966865dd535ec57143a26fa4438b78@haskell.org> #12537: Parallel cabal builds Segmentation Fault on PowerPC 64-bit -------------------------------------+------------------------------------- Reporter: michelmno | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: 12469 | Blocking: Related Tickets: | Differential Rev(s): Phab:D3984 Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * status: new => patch * differential: => Phab:D3984 Comment: Replying to [comment:11 trommler]: > I found an issue in the implementation of atomic read and atomic write operations in ghc-prim. I am working on a fix for powerpc64 and powerpc64le. Phab:3984 improves the situation a lot on an old PowerMac the segfault occurs only on every other run where before this patch I would see a segfault on almost all build attempts. The correctness issue I found in `libraries/ghc-prim/cbits/atomic.c` affects all platforms that are using the fallback functions `hs_atomicread*` and `hs_atomicwrite`. I will create a separate ticket for that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 17 12:25:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Sep 2017 12:25:58 -0000 Subject: [GHC] #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers Message-ID: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: #12537 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The comments in `compiler/prelude/primops.txt.pp` for both operations say "... Implies a full memory barrier." The implementation does not issue any barriers as exemplified by the 32-bit variants as can be seen in the excerpts from `libraries/ghc- prim/cbits/atomic.c`. {{{#!c StgWord hs_atomicread32(StgWord x) { return *(volatile StgWord32 *) x; } }}} and {{{#!c void hs_atomicwrite32(StgWord x, StgWord val) { *(volatile StgWord32 *) x = (StgWord32) val; } }}} The native code generator for X86/amd64 and the LLVM backend do not generate calls to these functions but generate the necessary barrier (`mfence`) directly and thus are not affected by this issue. There are no gcc `__sync_*` intrinsics for the two operations. The new `__atomic_*` intrinisics have the required operations but require gcc 4.7 or later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 17 22:36:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Sep 2017 22:36:22 -0000 Subject: [GHC] #14245: Make ScopedTypedVariables be effective for any type signature Message-ID: <046.6b08f3a580050db5ccfb9567012c1f53@haskell.org> #14245: Make ScopedTypedVariables be effective for any type signature -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment, `ScopedTypeVariables` does not have an effect for type signatures without an explicit `forall`. Therefore, you are forced to explicitly quantify type variables if you want the type variables of your type signature to be visible outside the type signature. When defining global variables, this means that you have to change part of the interface (the type signature) because of a change in the implementation. Of course, the change is only syntactical, but there is still a change. This is particularly problematic, because Haddock will follow the source code when deciding whether to include a top-level `forall` in the generated documentation or not. Your Haddock-generated documentation will include spurious `forall`s just because of the way your implementation works. You could say that this is just a Haddock issue. However, problems do not stop here. There is also an inconsistency between scoped type variables in variable definitions and scoped type variables in instance declarations. In instance declarations, you do not have to use an explicit `forall`. Type variables in the instance declaration head are visible in the body as soon as `ScopedTypeVariables` is enabled. I propose to change the semantics of `ScopedTypeVariables` such that as soon as it is enabled, the feature is in effect for all rank-1 type variables in any type signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 01:04:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 01:04:11 -0000 Subject: [GHC] #14245: Make ScopedTypedVariables be effective for any type signature In-Reply-To: <046.6b08f3a580050db5ccfb9567012c1f53@haskell.org> References: <046.6b08f3a580050db5ccfb9567012c1f53@haskell.org> Message-ID: <061.52de2f0b514e94735c8e9215494f1c3f@haskell.org> #14245: Make ScopedTypedVariables be effective for any type signature -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: I think this is a fine idea. It has a drawback in that it's not compatible with Haskell98 code, but perhaps that is not a deal-breaker. In any case, this kind of suggestion is perfect for the [https://github.com/ghc- proposals/ghc-proposals ghc-proposals] process, which I have found very valuable in understanding new ideas proposed for GHC (both as a proposer and as a reviewer of proposals). Feel free to copy and paste much of the text you have above, and don't worry so much about the fact that the proposal requires a "specification" -- your change is very simple to specify. In the meantime, I will close this ticket, as the community has settled on the ghc-proposals process as the official way to suggest user-facing changes to GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 01:51:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 01:51:07 -0000 Subject: [GHC] #14224: zipWith does not inline In-Reply-To: <045.ed8abb37df246f8ea9c4fff482d8cd1e@haskell.org> References: <045.ed8abb37df246f8ea9c4fff482d8cd1e@haskell.org> Message-ID: <060.9f269267809cc9c02b838ea050404d67@haskell.org> #14224: zipWith does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | 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): Phab:D3986 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * differential: => Phab:D3986 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 03:12:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 03:12:56 -0000 Subject: [GHC] #14246: Probably AllowAmbiguousTypes + UndecidableInstances + TypeInType Message-ID: <046.8b3b9e984fd26376daba4155f9345b3f@haskell.org> #14246: Probably AllowAmbiguousTypes + UndecidableInstances + TypeInType -------------------------------------+------------------------------------- Reporter: Toricon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | 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: -------------------------------------+------------------------------------- ghc.exe: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): isInjectiveTyCon sees a TcTyCon KLN {{{#!hs {-# LANGUAGE RankNTypes, GADTs, TypeOperators, PolyKinds, DataKinds, TypeFamilies, AllowAmbiguousTypes, UndecidableInstances, TypeInType #-} module MCS.Function where import MCS.Core --import MCS.Value import Data.Kind -- necessary for * type family KLN (n :: k) :: Nat where KLN (f :: v -> k) = S (KLN (forall t. f t)) KLN (f :: *) = Z type family Reveal (n :: k) (l :: Vect (KLN n) L) :: * where Reveal (f :: v -> k) (Cons (Label (t :: v)) l) = Reveal (f t) l Reveal (a :: *) Nil = a }}} The problem *has* to be somewhere in the KLN / Reveal interaction, so I removed everything else for this. Every other weird area is commented out or unused, and the bug vanished when KLN / Reveal was commented out. KLN shouldn't even work. If it _could_ be interaction with the rest of the document, I'll put that back in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 03:59:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 03:59:11 -0000 Subject: [GHC] #13767: GHCi trips -DS checks at rts/sm/Sanity.c, line 210 In-Reply-To: <046.e0bf705a7b0da22195c9831465099e74@haskell.org> References: <046.e0bf705a7b0da22195c9831465099e74@haskell.org> Message-ID: <061.a050785b22ac5215bc138031a05aedb1@haskell.org> #13767: GHCi trips -DS checks at rts/sm/Sanity.c, line 210 -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3680 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): In the unlikely event that we decide to merge this to 8.2 for any reason, we must also merge 60a3f11ff4b7e239a273498812fd9d31f6775726 to fix #14036. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 07:58:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 07:58:38 -0000 Subject: [GHC] #14245: Make ScopedTypedVariables be effective for any type signature In-Reply-To: <046.6b08f3a580050db5ccfb9567012c1f53@haskell.org> References: <046.6b08f3a580050db5ccfb9567012c1f53@haskell.org> Message-ID: <061.6346ed09d92789dc2634e01d53c072d1@haskell.org> #14245: Make ScopedTypedVariables be effective for any type signature -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'd also be OK with this if that's what everyone wants. I originally implemented the current semantics precisely to avoid accidentally breaking H98 programs, even when the extension is enabled, but the community may agree with you that I was too conservative! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 08:06:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 08:06:03 -0000 Subject: [GHC] #6084: Add stg_ap_pnnv and related call patterns In-Reply-To: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> References: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> Message-ID: <064.bd8f1aecab790f9c78958221a1d54006@haskell.org> #6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------- Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8313 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): So what's the actual problem here? The caller assigns a couple of registers that are ignored by the callee, and the callee doesn't need to declare them to be live because they aren't used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 08:57:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 08:57:53 -0000 Subject: [GHC] #14245: Make ScopedTypedVariables be effective for any type signature In-Reply-To: <046.6b08f3a580050db5ccfb9567012c1f53@haskell.org> References: <046.6b08f3a580050db5ccfb9567012c1f53@haskell.org> Message-ID: <061.c71c9e72703efb597d2aefb0a599ef47@haskell.org> #14245: Make ScopedTypedVariables be effective for any type signature -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12540 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * related: => #12540 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 08:58:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 08:58:56 -0000 Subject: [GHC] #12540: RFC: Allow not quantifying every top-level quantifiee In-Reply-To: <051.1956280adad0090e4523e93fefe0fc52@haskell.org> References: <051.1956280adad0090e4523e93fefe0fc52@haskell.org> Message-ID: <066.11c669a64b92a51fd184b26e9563bc82@haskell.org> #12540: RFC: Allow not quantifying every top-level quantifiee -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14245 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * related: => #14245 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 09:27:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 09:27:59 -0000 Subject: [GHC] #13038: implementation of Modus ponens and Modus tollens In-Reply-To: <044.ee87b0a017d5b08f838549b48bb4f0cf@haskell.org> References: <044.ee87b0a017d5b08f838549b48bb4f0cf@haskell.org> Message-ID: <059.2e9d835ece6214376e5768c19b49285d@haskell.org> #13038: implementation of Modus ponens and Modus tollens -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): The H.M algorithm is based on the reasoning of the Modus Ponens.\\ 1) f is a function that maps arguments of type A to results of type B.\\ {{{ f :: A -> B is identical to v(P -> Q) = 1 }}} 2) e is an expression of type A\\ {{{ e :: A is identical to v(P) = 1 }}} 3) Then the application f e has type B\\ {{{ f e :: B is identical to v(Q) = 1 }}} The inference algorithm tells us which type has a value, but it does not tell us what type does not have the value. I also think it is important for the compiler to know what types the value does not have. To know this, we must infer the inverse of the algorithm and must use the Modus Tollens.\\ {{{ 1) f e :: not B is identical to v(Q) = 0 }}} {{{ 2) f :: A -> B is identical to v(P -> Q) = 1 }}} {{{ 3) e :: not A is identical to v(P) = 0 }}} The utility of Modus tollens is complementary for many checks. I also propose that an inference algorithm based on Modus Tollens be coded in GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 12:35:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 12:35:59 -0000 Subject: [GHC] #14246: Probably AllowAmbiguousTypes + UndecidableInstances + TypeInType In-Reply-To: <046.8b3b9e984fd26376daba4155f9345b3f@haskell.org> References: <046.8b3b9e984fd26376daba4155f9345b3f@haskell.org> Message-ID: <061.4ce3e2a782fbeeeb3f0056e0bf936287@haskell.org> #14246: Probably AllowAmbiguousTypes + UndecidableInstances + TypeInType -------------------------------------+------------------------------------- Reporter: Toricon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13271 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13271 Comment: I don't know what `MCS.Core` is, so I have no way to test this code. That being said, this error message is identical to that of #13271, which has been fixed as of GHC 8.2.1. Can you test your code on 8.2.1 and see if you still experience the same error? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 12:50:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 12:50:19 -0000 Subject: [GHC] #13959: substTyVar's definition is highly dubious In-Reply-To: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> References: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> Message-ID: <065.dd68c46ac6a68580c17d8538e1afed6a@haskell.org> #13959: substTyVar's definition is highly dubious -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 13:39:18 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 13:39:18 -0000 Subject: [GHC] #14197: Flag "dump-rn-ast" only dumps the declarations, not the whole RenamedSource In-Reply-To: <044.cc22bc6c087d1948925080ce049a8ac5@haskell.org> References: <044.cc22bc6c087d1948925080ce049a8ac5@haskell.org> Message-ID: <059.8f946a7a32eca7d7a92c248a4c8be576@haskell.org> #14197: Flag "dump-rn-ast" only dumps the declarations, not the whole RenamedSource -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: merge Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3949 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 13:41:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 13:41:01 -0000 Subject: [GHC] #14215: Coordinate re Cabal-2.0.0.3 or Cabal-2.0.1 release In-Reply-To: <042.f2da5496c03c753cd8a87d1fc1022cfc@haskell.org> References: <042.f2da5496c03c753cd8a87d1fc1022cfc@haskell.org> Message-ID: <057.52d4b4a8c4a065d29d263efc5c4e9875@haskell.org> #14215: Coordinate re Cabal-2.0.0.3 or Cabal-2.0.1 release -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: task | Status: upstream Priority: high | Milestone: 8.2.2 Component: libraries | Version: 8.2.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've created https://github.com/haskell/cabal/issues/4772 to track this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 13:42:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 13:42:38 -0000 Subject: [GHC] #9775: "Failed to remove" errors during Windows build from hsc2hs In-Reply-To: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> References: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> Message-ID: <060.201f823d9fd827719822224b7dbe2eb9@haskell.org> #9775: "Failed to remove" errors during Windows build from hsc2hs ---------------------------------+---------------------------------------- Reporter: gintas | Owner: Phyx- Type: bug | Status: upstream Priority: normal | Milestone: 8.4.1 Component: hsc2hs | Version: 7.8.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: | ---------------------------------+---------------------------------------- Changes (by bgamari): * milestone: 8.2.2 => 8.4.1 Comment: Bumping off to 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 13:44:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 13:44:10 -0000 Subject: [GHC] #13753: Improve GHC's ghc package environment lookup logic In-Reply-To: <042.2a208789b5cdf0bbb17f300eaf094b7c@haskell.org> References: <042.2a208789b5cdf0bbb17f300eaf094b7c@haskell.org> Message-ID: <057.b96bc589c70f6f0f9d8038df74c54cab@haskell.org> #13753: Improve GHC's ghc package environment lookup logic -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.2 => 8.4.1 Comment: It doesn't look like this will happen for 8.2.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 13:45:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 13:45:23 -0000 Subject: [GHC] #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL In-Reply-To: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> References: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> Message-ID: <061.332fd7b4f9bade0278929422a7fea0a0@haskell.org> #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13304 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high Comment: Bumping in priority as this likely affects all environments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 13:45:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 13:45:28 -0000 Subject: [GHC] #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL In-Reply-To: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> References: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> Message-ID: <061.69b3e4b87757609459c7358ad42a31a9@haskell.org> #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13304 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 13:45:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 13:45:51 -0000 Subject: [GHC] #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL In-Reply-To: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> References: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> Message-ID: <061.bd1b657879d224f7e3f78eb6d2af6572@haskell.org> #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13304 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 13:47:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 13:47:02 -0000 Subject: [GHC] #13763: Performance regression (~34%) in 8.2.1, poor register allocation(?) in an inner loop over an array In-Reply-To: <048.3858df3b3399782d9452f01ad23b4ddd@haskell.org> References: <048.3858df3b3399782d9452f01ad23b4ddd@haskell.org> Message-ID: <063.6654cfca6ac16409a85ef1fc09c6207c@haskell.org> #13763: Performance regression (~34%) in 8.2.1, poor register allocation(?) in an inner loop over an array -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.2.1-rc2 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.2 => 8.4.1 Comment: Unfortunately I don't think anything will happen on this front for 8.2.2; however, it's likely that Phab:D2903 will make it for 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 13:50:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 13:50:19 -0000 Subject: [GHC] #14214: Users guide lies about default optimization level In-Reply-To: <046.736805dbdfc6944b76008d4f99ba283f@haskell.org> References: <046.736805dbdfc6944b76008d4f99ba283f@haskell.org> Message-ID: <061.cffff8bc0f43d680d7315102b3a90f58@haskell.org> #14214: Users guide lies about default optimization level -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 13:52:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 13:52:54 -0000 Subject: [GHC] #9775: "Failed to remove" errors during Windows build from hsc2hs In-Reply-To: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> References: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> Message-ID: <060.77e1541b9182e922090eb1037495e684@haskell.org> #9775: "Failed to remove" errors during Windows build from hsc2hs ---------------------------------+---------------------------------------- Reporter: gintas | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: 8.4.1 Component: hsc2hs | Version: 7.8.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: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * owner: Phyx- => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 13:56:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 13:56:56 -0000 Subject: [GHC] #14245: Make ScopedTypedVariables be effective for any type signature In-Reply-To: <046.6b08f3a580050db5ccfb9567012c1f53@haskell.org> References: <046.6b08f3a580050db5ccfb9567012c1f53@haskell.org> Message-ID: <061.1604ad2415dd078657dfeee3b3ccdba4@haskell.org> #14245: Make ScopedTypedVariables be effective for any type signature -------------------------------------+------------------------------------- Reporter: jeltsch | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12540 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jeltsch): Note that the way `ScopedTypeVariables` works for instance declarations nowadays already breaks Haskell 98/2010 code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 16:13:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 16:13:58 -0000 Subject: [GHC] #13959: substTyVar's definition is highly dubious In-Reply-To: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> References: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> Message-ID: <065.b14c88274b74017ea43e246afe3e9a04@haskell.org> #13959: substTyVar's definition is highly dubious -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Ryan, are you working on this? Or should I add it to my queue? Or does Simon want it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 16:51:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 16:51:45 -0000 Subject: [GHC] #13959: substTyVar's definition is highly dubious In-Reply-To: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> References: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> Message-ID: <065.12507d577ea874413dc4d26688a2199c@haskell.org> #13959: substTyVar's definition is highly dubious -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:14 goldfire]: > Ryan, are you working on this? No. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 18:38:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 18:38:06 -0000 Subject: [GHC] #14190: Typeable imposes seemingly redundant constraints on polykinded instances In-Reply-To: <045.10ac00c982131e42012d99b318054ca4@haskell.org> References: <045.10ac00c982131e42012d99b318054ca4@haskell.org> Message-ID: <060.e4c85410b9c5659a0fbe22d791c79317@haskell.org> #14190: Typeable imposes seemingly redundant constraints on polykinded instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Typeable Operating System: 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): I think the ideal ergonomics with the best performance would likely be to leave the class as it is, extract the typerep-of-kind info as needed in the `DFun`s, and hack the constraint solver to let it solve `Typeable k` from `Typeable (a :: k)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 20:24:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 20:24:30 -0000 Subject: [GHC] #13586: ghc --make seems to leak memory In-Reply-To: <054.b9022cd384af70aab8c44b70e8c723cb@haskell.org> References: <054.b9022cd384af70aab8c44b70e8c723cb@haskell.org> Message-ID: <069.6a032608652c48d8a83e875c40528fd8@haskell.org> #13586: ghc --make seems to leak memory -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13379 #13564 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): I've just made a change that lowered RAM usage a lot (it no longer trashes my computer; perhaps it uses the same total amount of RAM+swap, I didn't measure). Most of specialization was occurring originally in a single module and now I'm already specializing some of that in another module. This would indicate RAM usage of the compiler is not linear in the number of specializations occurring in a single module. Perhaps it really uses non-linear amounts of memory and perhaps it just looks through the list of specializations from the current module from time to time and so they can't just get swapped out and stay that way, but are brought to back to RAM too often, causing swap thrashing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 21:07:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 21:07:05 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism In-Reply-To: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> References: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> Message-ID: <063.7acb6b7a3abbd5a647b0c647f7f214b5@haskell.org> #13929: GHC panic with levity polymorphism -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vagarenko): Replying to [comment:14 bgamari]: Now I see. Thank you for the very thorough explanation! Replying to [comment:10 Ben Gamari ]: > In [changeset:"fa626f3b1c1140a1f10bba60fdde10f767863f70/ghc" fa626f3/ghc]: > {{{ > #!CommitTicketReference repository="ghc" revision="fa626f3b1c1140a1f10bba60fdde10f767863f70" > Fix #13929 by adding another levity polymorphism check > > test case: typecheck/should_fail/T13929 > }}} Have you tested that patch with unboxed sums? See my comment:8 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 21:18:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 21:18:47 -0000 Subject: [GHC] #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc In-Reply-To: <049.42fb65c94c9d58534f92e7ad520e593b@haskell.org> References: <049.42fb65c94c9d58534f92e7ad520e593b@haskell.org> Message-ID: <064.2d76cdd40dca15f2977bb30e446181b5@haskell.org> #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | rename/should_fail/T13644 Blocked By: | Blocking: Related Tickets: #13840, #13973, | Differential Rev(s): Phab:D3988 #14087 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * testcase: => rename/should_fail/T13644 * status: new => patch * differential: => Phab:D3988 Comment: Looking at this again, I realised that the fix to #13847 is entirely analogous. Diff away! @mpickering I probably broke this when implementing ORF, but AFAICS there is no ORF-related reason for us to compare field labels here, because we already know the selector names we want. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 21:20:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 21:20:46 -0000 Subject: [GHC] #13847: record construction accepts local unqualified name instead of qualified imported name In-Reply-To: <049.a967f3782f78e925a6ef9e3030f47afd@haskell.org> References: <049.a967f3782f78e925a6ef9e3030f47afd@haskell.org> Message-ID: <064.a5cb26e6fb6b6fb74ac7c39b185cce88@haskell.org> #13847: record construction accepts local unqualified name instead of qualified imported name -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | rename/should_fail/T13847 Blocked By: | Blocking: Related Tickets: #13644 | Differential Rev(s): Phab:D3988 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * testcase: => rename/should_fail/T13847 * status: new => patch * differential: => Phab:D3988 * related: => #13644 * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 21:27:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 21:27:09 -0000 Subject: [GHC] #12158: ghc: panic! (the 'impossible' happened) translateConPatVec: lookup In-Reply-To: <047.dbe3294939f168d779839dd776514e40@haskell.org> References: <047.dbe3294939f168d779839dd776514e40@haskell.org> Message-ID: <062.06c1d53fea926812d596794603964d85@haskell.org> #12158: ghc: panic! (the 'impossible' happened) translateConPatVec: lookup -------------------------------------+------------------------------------- Reporter: wozgonon | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #13644 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * related: => #13644 Comment: The panic here is a duplicate of #13644. With the fix in Phab:D3988 I get: {{{ Prelude> data Stock = Stock {name :: String, ric :: String, price :: Float} Prelude> price Stock{name=name,ric=ric,price=price} = price :2:31: error: • Constructor ‘Stock’ does not have field ‘price’ • In the pattern: Stock {name = name, ric = ric, price = price} In an equation for ‘price’: price Stock {name = name, ric = ric, price = price} = price Prelude> let price Stock{name=name,ric=ric,price=price} = price Prelude> }}} This is arguably still wrong, because if the explicit `let` binding works, the implicit one surely should work too. Presumably the GHCi name shadowing magic isn't quite consistent between the two cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 21:36:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 21:36:31 -0000 Subject: [GHC] #13127: Refactor AvailInfo to be more sensible In-Reply-To: <049.ff5c9319c6b1c1673fb808d42ce1b7f5@haskell.org> References: <049.ff5c9319c6b1c1673fb808d42ce1b7f5@haskell.org> Message-ID: <064.b3784ec6b041b9bcffed84454b289829@haskell.org> #13127: Refactor AvailInfo to be more sensible -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: task | Status: closed Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12662 Related Tickets: #13128 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * status: new => closed * resolution: => duplicate * related: => #13128 Comment: Closing as duplicate of #13128. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 21:58:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 21:58:05 -0000 Subject: [GHC] #14206: Add bit deposit and bit extraction primops In-Reply-To: <047.2543734720307265ea1bddd575e5fddb@haskell.org> References: <047.2543734720307265ea1bddd575e5fddb@haskell.org> Message-ID: <062.eb44a12f049e286b671a16392d9093f5@haskell.org> #14206: Add bit deposit and bit extraction primops -------------------------------------+------------------------------------- Reporter: newhoggy | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by newhoggy): Yes, I'm interested in offering a patch, but I'm very new to this. Before I can make a contribution, I need a working build from source don't I? Starting there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 22:21:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 22:21:21 -0000 Subject: [GHC] #14247: Fails to coerce between newtypes directly Message-ID: <051.620a661bd2b7c68990ff1e8817e40a68@haskell.org> #14247: Fails to coerce between newtypes directly -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs import Data.Coerce import Data.Type.Coercion newtype W a = W a newtype A = MkA (W A) a :: Coercion A A a = Coercion b :: Coercion a a' -> Coercion a (W a') b Coercion = Coercion c :: Coercion A (W A) c = b a }}} works just fine but the following fail: {{{#!hs -- • Couldn't match representation of type ‘A’ with that of ‘W A’ -- arising from a use of ‘Coercion’ -- • In the expression: Coercion -- In an equation for ‘d’: d = Coercion d :: Coercion A (W A) d = Coercion -- • Couldn't match representation of type ‘A’ with that of ‘W A’ -- arising from a use of ‘coerce’ -- • In the expression: coerce -- In an equation for ‘e’: e = coerce e :: A -> W A e = coerce }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 22:24:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 22:24:19 -0000 Subject: [GHC] #14248: GHC misses optimization opportunity Message-ID: <048.c098d45242a1ccdc04da1a82b82c67e9@haskell.org> #14248: GHC misses optimization opportunity -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this code: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE AllowAmbiguousTypes #-} module Unzip where import Prelude hiding (unzip) import GHC.TypeLits import Data.Kind -- | Data family of unboxed vectors. class IsVector (n :: Nat) e where data Vector n e :: Type fromList :: [e] -> Vector n e -- | Unrolled unzip. Type param @n@ is the length of the input list. class Unzip (n :: Nat) where unzip :: [(a, b)] -> ([a], [b]) instance {-# OVERLAPPING #-} Unzip 0 where unzip _ = ([], []) {-# INLINE unzip #-} instance {-# OVERLAPPABLE #-} (Unzip (n - 1)) => Unzip n where unzip [] = error "Not enough elements." unzip (x : xs) = (\(a, b) (as, bs) -> (a : as, b : bs)) x (unzip @(n - 1) xs) {-# INLINE unzip #-} -- | Make pair of vectors from list of pairs of vector's elements. unzipVec :: forall (n :: Nat) e. (IsVector n e, Unzip n) => [(e, e)] -> (Vector n e, Vector n e) unzipVec ps = let (es1, es2) = unzip @n ps in (fromList es1, fromList es2) {-# INLINE unzipVec #-} -------------------------------- instance IsVector 2 Float where data Vector 2 Float = Vector2f {-# UNPACK #-} !Float {-# UNPACK #-} !Float fromList [a, b] = Vector2f a b fromList [] = error "Not enough elements." unzipVecSpecialized :: [(Float, Float)] -> (Vector 2 Float, Vector 2 Float) unzipVecSpecialized = unzipVec }}} GHC-8.2.1 generates the following Core for `unzipVecSpecialized` function: {{{#!hs -- RHS size: {terms: 84, types: 113, coercions: 4, joins: 0/1} unzipVecSpecialized :: [(Float, Float)] -> (Vector 2 Float, Vector 2 Float) unzipVecSpecialized = \ (eta :: [(Float, Float)]) -> let { ds :: ([Float], [Float]) ds = case eta of { [] -> lvl20; : x xs -> case x of { (a, b) -> case xs of { [] -> lvl20; : x1 xs1 -> case x1 of { (a1, b1) -> (: @ Float a (: @ Float a1 ([] @ Float)), : @ Float b (: @ Float b1 ([] @ Float))) } } } } } in (case ds of { (es1, es2) -> case es1 of { [] -> $fIsVector2Float1; : a ds1 -> case ds1 of { [] -> $fIsVector2Float1; : b ds2 -> case ds2 of { [] -> case a of { F# dt1 -> case b of { F# dt3 -> (Vector2f dt1 dt3) `cast` } }; : ipv ipv1 -> $fIsVector2Float1 } } } }, case ds of { (es1, es2) -> case es2 of { [] -> $fIsVector2Float1; : a ds1 -> case ds1 of { [] -> $fIsVector2Float1; : b ds2 -> case ds2 of { [] -> case a of { F# dt1 -> case b of { F# dt3 -> (Vector2f dt1 dt3) `cast` } }; : ipv ipv1 -> $fIsVector2Float1 } } } }) }}} Notice how it constructs tuple of lists `ds :: ([Float], [Float])` and then deconstructs it twice. I would expect the compiler to get rid of intermediate tuple and lists, so the Core would look like this: {{{#!hs unzipVecSpecialized :: [(Float, Float)] -> (Vector 2 Float, Vector 2 Float) unzipVecSpecialized = \ (eta :: [(Float, Float)]) -> case eta of { [] -> lvl20; : x xs -> case x of { (a, b) -> case xs of { [] -> lvl20; : x1 xs1 -> case x1 of { (a1, b1) -> (case a of { F# dt1 -> case a1 of { F# dt2 -> (Vector2f dt1 dt2) }}, case b of { F# dt3 -> case b1 of { F# dt4 -> (Vector2f dt3 dt4) }} ) } } } } }}} I've tried putting different phase control options on the INLINE pragmas to no success. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 22:35:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 22:35:58 -0000 Subject: [GHC] #14248: GHC misses optimization opportunity In-Reply-To: <048.c098d45242a1ccdc04da1a82b82c67e9@haskell.org> References: <048.c098d45242a1ccdc04da1a82b82c67e9@haskell.org> Message-ID: <063.1854e2d1cb307b17c7b12b09424e4f45@haskell.org> #14248: GHC misses optimization opportunity -------------------------------------+------------------------------------- Reporter: vagarenko | 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 simonpj): Alas, your proposed optimsation changes the semantics of the function. As it stands, it's not strict in `eta`, but after your transformation it has become strict. If you make it strict yourself, I think it'll probably optimise right. This seems to do ths trick {{{ unzipVec ps = let (es1, es2) = unzip @n ps !a1 = fromList es1 !a2 = fromList es2 in (a1, a2) }}} gives {{{ unzipVecSpecialized = \ (eta_B1 :: [(Float, Float)]) -> case eta_B1 of { [] -> case lvl20_r2SX of wild1_00 { }; : x_a14H xs_a14I -> case x_a14H of { (a_a14J, b_a14K) -> case xs_a14I of { [] -> case lvl20_r2SX of wild3_00 { }; : x1_X18m xs1_X18o -> case x1_X18m of { (a1_X18u, b1_X18w) -> case a_a14J of { GHC.Types.F# dt1_a15E -> case a1_X18u of { GHC.Types.F# dt3_a15F -> case b_a14K of { GHC.Types.F# dt5_X17Q -> case b1_X18w of { GHC.Types.F# dt7_X17W -> ((Unzip.Vector2f dt1_a15E dt3_a15F) `cast` (Sym (Unzip.D:R:Vector2Float0[0]) :: (Unzip.R:Vector2Float :: *) ~R# (Vector 2 Float :: *)), (Unzip.Vector2f dt5_X17Q dt7_X17W) `cast` (Sym (Unzip.D:R:Vector2Float0[0]) :: (Unzip.R:Vector2Float :: *) ~R# (Vector 2 Float :: *))) } } } } } } } } }}} Does that make sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 22:44:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 22:44:51 -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.2f9f4fb83e1fe367d6ac9d479b51261d@haskell.org> #14247: Fails to coerce between newtypes directly -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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 goldfire): The `Coercible` solver is incomplete when recursive newtypes come into play. We admit this in the JFP paper. I don't know how to do better. And I'm pretty sure the problem is undecidable, anyway. Did this come up in the wild? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 23:03:29 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 23:03:29 -0000 Subject: [GHC] #14248: GHC misses optimization opportunity In-Reply-To: <048.c098d45242a1ccdc04da1a82b82c67e9@haskell.org> References: <048.c098d45242a1ccdc04da1a82b82c67e9@haskell.org> Message-ID: <063.ffdf90c55c090c774c60290c8de56fda@haskell.org> #14248: GHC misses optimization opportunity -------------------------------------+------------------------------------- Reporter: vagarenko | 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 vagarenko): Replying to [comment:1 simonpj]: Thank you! This works perfectly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 23:04:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 23:04:01 -0000 Subject: [GHC] #14248: GHC misses optimization opportunity In-Reply-To: <048.c098d45242a1ccdc04da1a82b82c67e9@haskell.org> References: <048.c098d45242a1ccdc04da1a82b82c67e9@haskell.org> Message-ID: <063.fffbd8ea8556812775407fe9d321cb28@haskell.org> #14248: GHC misses optimization opportunity -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 vagarenko): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 23:15:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 23:15:43 -0000 Subject: [GHC] #13038: implementation of Modus ponens and Modus tollens In-Reply-To: <044.ee87b0a017d5b08f838549b48bb4f0cf@haskell.org> References: <044.ee87b0a017d5b08f838549b48bb4f0cf@haskell.org> Message-ID: <059.afab4465cb608bfdf26a240a3bbde716@haskell.org> #13038: implementation of Modus ponens and Modus tollens -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:7 vanto]: > The H.M algorithm is based on the reasoning of the Modus Ponens.\\ > Yes: type inference is monotonic. That is, adding more definitions cannot make previously correct code become incorrect. (For example importing a compiled module and adding definitions in this module cannot invalidate the type inference in the imported module.) (That's not quite true in GHC with some of the 'advanced' extensions; and that's why type inference can become incoherent.) > > The inference algorithm tells us which type has a value, but it does > not tell us what type does not have the value. (Not sure I understand but ...) that's impossible in general: there might be a later definition, perhaps in another module, that will provide a suitable type. > The utility of Modus tollens is complementary for many checks. Please give some examples of the checks you're talking about. This is all very abstract so far. > I also propose that an inference algorithm based on Modus Tollens be > coded in GHC. > Coded where? You mean in a Library/as an operator? Or I think you are talking about type inference in general? Then you would need a very strong reason to overturn Hindley-Milner. I suggest you ask some questions on the cafe; especially to discuss examples. And far-reaching proposals should be submitted through the github process, rather than Trac. There is already one proposal to use [https://github.com/AntC2/ghc- proposals/blob/instance-apartness-guards/proposals/0000-instance- apartness-guards.rst 'negative information' in type inference] -- kinda. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 23:26:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 23:26:54 -0000 Subject: [GHC] #14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint Message-ID: <049.dc7f2b094945252a1bcc71f807a43fac@haskell.org> #14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint --------------------------------------+--------------------------- Reporter: mutantmell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: ApplicativeDo | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------- Pattern matching on a bind in 8.2.1 confuses ApplicativeDo, and causes the type to have a Monad constraint where a Functor constraint would suffice. In GHC 8.0: {{{#!hs > :set -XApplicativeDo > :t \x -> do { (a, _) <- x; pure (a+1) } \x -> do { (a, _) <- x; pure (a+1) } :: (Num b, Functor f) => f (b, t) -> f b }}} In GHC 8.2: {{{#!hs > :set -XApplicativeDo > :t \x -> do { (a, _) <- x; pure (a+1) } \x -> do { (a, _) <- x; pure (a+1) } :: (Num b1, Monad m) => m (b1, b2) -> m b1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 23:34:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 23:34:16 -0000 Subject: [GHC] #14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint In-Reply-To: <049.dc7f2b094945252a1bcc71f807a43fac@haskell.org> References: <049.dc7f2b094945252a1bcc71f807a43fac@haskell.org> Message-ID: <064.28dabad5736fc027533c6400e8410a0b@haskell.org> #14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint -------------------------------+-------------------------------------- Reporter: mutantmell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by Iceland_jack): Due to #13875? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 23:42:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 23:42:12 -0000 Subject: [GHC] #14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint In-Reply-To: <049.dc7f2b094945252a1bcc71f807a43fac@haskell.org> References: <049.dc7f2b094945252a1bcc71f807a43fac@haskell.org> Message-ID: <064.1e6e67994dac9eb63162b54e21484a88@haskell.org> #14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint -------------------------------+-------------------------------------- Reporter: mutantmell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by mutantmell): Adding the `~` to my pattern match changes the constraint, so it looks like it is due to #13875. I'll close the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 18 23:42:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Sep 2017 23:42:48 -0000 Subject: [GHC] #14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint In-Reply-To: <049.dc7f2b094945252a1bcc71f807a43fac@haskell.org> References: <049.dc7f2b094945252a1bcc71f807a43fac@haskell.org> Message-ID: <064.3680f6dda62e8f0011a3a4dbbc9b5d11@haskell.org> #14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint -------------------------------+-------------------------------------- Reporter: mutantmell | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: ApplicativeDo Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Changes (by mutantmell): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 00:09:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 00:09:08 -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.fd36dca99a2e46de7d805b27704c26ac@haskell.org> #14247: Fails to coerce between newtypes directly -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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 Iceland_jack): It's artificial and follows from me discussing "deriving via a `newtype`" with Ryan; we wondered if there could be a way to derive via a regular `data` type.. which lead me to something like {{{#!hs newtype W a = W a data A = MkA (W A) }}} where coercing `coerce :: A -> W A` actually works: make `A` a `newtype` and it stops working. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 00:17:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 00:17:15 -0000 Subject: [GHC] #14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint In-Reply-To: <049.dc7f2b094945252a1bcc71f807a43fac@haskell.org> References: <049.dc7f2b094945252a1bcc71f807a43fac@haskell.org> Message-ID: <064.6e065491f15bc9792b8b24b41bb35112@haskell.org> #14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint -------------------------------+-------------------------------------- Reporter: mutantmell | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: ApplicativeDo Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by Iceland_jack): Thanks for filing the ticket, I'm sure you aren't the only one confused by this behavior -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 00:48:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 00:48:56 -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.cd30cc7849e553f1596d1c758f6831c6@haskell.org> #14247: Fails to coerce between newtypes directly -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: RyanGlScott (added) Comment: For what it's worth, this is the only time I've had issue with the `Coercible` solver! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 00:52:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 00:52:07 -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.cf6baaee85bfaa864d271286251c9b57@haskell.org> #14247: Fails to coerce between newtypes directly -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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 RyanGlScott): It's quite amusing to see how one can work around the issue in the first example by manually wrapping `W` a single time using `b`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 01:12:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 01:12:47 -0000 Subject: [GHC] #14227: Add -fdefer-ffi-errors flag In-Reply-To: <048.d425d7353a8d9d520ea0edf2dab3c26a@haskell.org> References: <048.d425d7353a8d9d520ea0edf2dab3c26a@haskell.org> Message-ID: <063.2c828a59c7e68a473fb7c99134133a4b@haskell.org> #14227: Add -fdefer-ffi-errors flag -------------------------------------+------------------------------------- Reporter: tysonzero | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tysonzero): [https://github.com/ghc-proposals/ghc-proposals/pull/73 Proposal created] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 01:35:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 01:35:32 -0000 Subject: [GHC] #14206: Add bit deposit and bit extraction primops In-Reply-To: <047.2543734720307265ea1bddd575e5fddb@haskell.org> References: <047.2543734720307265ea1bddd575e5fddb@haskell.org> Message-ID: <062.c51e9f11dc9a530e64eaa13d080f79d1@haskell.org> #14206: Add bit deposit and bit extraction primops -------------------------------------+------------------------------------- Reporter: newhoggy | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by newhoggy): Okay, successfully built master. Can start working on a patch. I'll base it on the popcnt patch. Question: Do I need a new ghc flag? gcc uses -mbmi2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 03:25:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 03:25:23 -0000 Subject: [GHC] #12437: 20% regression in max_bytes_used for T1969 In-Reply-To: <047.090b2624111211cac9a272929b897b02@haskell.org> References: <047.090b2624111211cac9a272929b897b02@haskell.org> Message-ID: <062.378b6c4dc3a8cc6d4293da33f00388ff@haskell.org> #12437: 20% regression in max_bytes_used for T1969 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: dfeuer Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "hp-after.hp.gz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 03:25:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 03:25:47 -0000 Subject: [GHC] #12437: 20% regression in max_bytes_used for T1969 In-Reply-To: <047.090b2624111211cac9a272929b897b02@haskell.org> References: <047.090b2624111211cac9a272929b897b02@haskell.org> Message-ID: <062.091c1a35ffe6956f3066f212815df640@haskell.org> #12437: 20% regression in max_bytes_used for T1969 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: dfeuer Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * Attachment "hp-before.hp.gz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 03:26:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 03:26:29 -0000 Subject: [GHC] #12437: 20% regression in max_bytes_used for T1969 In-Reply-To: <047.090b2624111211cac9a272929b897b02@haskell.org> References: <047.090b2624111211cac9a272929b897b02@haskell.org> Message-ID: <062.81c0aeecc46c15e0d289830bdd219887@haskell.org> #12437: 20% regression in max_bytes_used for T1969 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: dfeuer Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I've attached before and after heap profiles. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 04:44:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 04:44:35 -0000 Subject: [GHC] #14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint In-Reply-To: <049.dc7f2b094945252a1bcc71f807a43fac@haskell.org> References: <049.dc7f2b094945252a1bcc71f807a43fac@haskell.org> Message-ID: <064.19b564a6acb71a87d10d9c126e832401@haskell.org> #14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint -------------------------------+-------------------------------------- Reporter: mutantmell | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: ApplicativeDo Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by mutantmell): I was updating a codebase to 8.2 when I ran into this -- the only thing ghc told me was that my previously valid signature was wrong. Having the compiler output extra information here similar to how it informs the user about Language Extensions would have helped. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 05:58:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 05:58:01 -0000 Subject: [GHC] #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) In-Reply-To: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> References: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> Message-ID: <057.f659b3a006fee8762a68079237fcba87@haskell.org> #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: libraries/base | 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: #10365 | Differential Rev(s): phab:D3927 Wiki Page: | prime:Libraries/Proposals/SemigroupMonoid| -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"10ca8018900364579123bf3912202176d338d3c6/ghc" 10ca801/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="10ca8018900364579123bf3912202176d338d3c6" Generalise constraint on `instance Monoid (Maybe a)` to Semigroup This now becomes possible due to the introduction of the Semigroup=>Monoid superclass relation (see #14191). Reviewers: ekmett, RyanGlScott, austin, bgamari Reviewed By: ekmett, RyanGlScott, bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3972 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 06:31:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 06:31:41 -0000 Subject: [GHC] #6084: Add stg_ap_pnnv and related call patterns In-Reply-To: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> References: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> Message-ID: <064.b1b6888d1cd2687361792134c127ef93@haskell.org> #6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------- Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8313 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): The problem I'm running into is, that I try to match up caller and callee signatures in my llvm code gen, as LLVM expect them to be properly typed. And as we are passing registers are argument in LLVM. I end up with signatures that do not match. Our current llvm backend, simply assumes it can safely call a function with more parameters than the function signature permitted. I'm not sure we could potentially create a function {{{ f :: BaseReg -> Sp -> Hp -> R1 -> R2 -> R3 -> R4 -> R5 -> R6 -> SpLim -> F1 -> D1 -> F2 -> D2 }}} and then elminate `F1` and `D1`. Thus actually having {{{ f :: BaseReg -> Sp -> Hp -> R1 -> R2 -> R3 -> R4 -> R5 -> R6 -> SpLim -> F2 -> D2 }}} and finally ending up calling it with {{{ f baseReg sp hp r1 r2 r3 r4 r5 r6 spLim f1 d1 f2 d2 }}} where we now pass `f1` where `f` expects `F2`? It might also just be the case, that generating the function signature from the `live` is suboptimal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 08:41:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 08:41:31 -0000 Subject: [GHC] #12470: Move LLVM code generator to LLVM bitcode format In-Reply-To: <046.2d176265e89a9f069bd8e76d6793e054@haskell.org> References: <046.2d176265e89a9f069bd8e76d6793e054@haskell.org> Message-ID: <061.71d10c260631cdd51812f3e151452cad@haskell.org> #12470: Move LLVM code generator to LLVM bitcode format -------------------------------------+------------------------------------- Reporter: bgamari | Owner: angermann Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * version: 8.0.1 => 8.3 Comment: A preview of this is now available as per https://mail.haskell.org/pipermail/ghc-devs/2017-September/014689.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 08:45:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 08:45:19 -0000 Subject: [GHC] #14250: GHCi by default opens .ghci files in local directories. Message-ID: <045.edec94df57b9e034f6589f0b71e29db4@haskell.org> #14250: GHCi by default opens .ghci files in local directories. -------------------------------------+------------------------------------- Reporter: merijn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- During a discussion on IRC I learned that `ghci` still opens `.ghci` in local directories by default (I think I raised this issue before). This means that if I'm looking through the source of an untrusted Haskell repo I can get my machine owned by simply running `ghci`. Now for simple shell use I could get solve this by aliasing `ghci` to `ghci -ignore-dot-files -ghci-script ~/.ghci`, but there are a lot of editor/IDE tools that also run `ghci` that wouldn't use this alias. Some sensible solutions that spring to mind are: 1) Only load `~/.ghci` by default and add a flag that enables scanning local files. 2) Adding `ghci` commands to enable/disable loading local `.ghci` files in the ghci prompt and change the load order of `.ghci` files so that `~/.ghci` loads first and can enable/disable loading local files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 08:50:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 08:50:21 -0000 Subject: [GHC] #14250: GHCi by default opens .ghci files in local directories. In-Reply-To: <045.edec94df57b9e034f6589f0b71e29db4@haskell.org> References: <045.edec94df57b9e034f6589f0b71e29db4@haskell.org> Message-ID: <060.cc6dd932d5d6ef572a0f0e50b5242418@haskell.org> #14250: GHCi by default opens .ghci files in local directories. -------------------------------------+------------------------------------- Reporter: merijn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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 davean): * cc: davean (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 08:56:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 08:56:52 -0000 Subject: [GHC] #13576: Runtime crashes on arm64 (iOS) In-Reply-To: <049.870e50852d766ed0e0b96a146b5b4e33@haskell.org> References: <049.870e50852d766ed0e0b96a146b5b4e33@haskell.org> Message-ID: <064.4055c80fb3961d86d8c6b2716fab9814@haskell.org> #13576: Runtime crashes on arm64 (iOS) ----------------------------------+------------------------------- Reporter: jp.rider63 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: aarch64 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------- Comment (by angerman): jp.rider63, do you have a full example that crashes? I'd be willing to take a look at this. But as I underhand without `hs_AAPublicKeyAlgorithm`, this won't crash :-/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 10:53:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 10:53:21 -0000 Subject: [GHC] #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.c89bfe2329635d5bcf458cd9369823a1@haskell.org> #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): A similar issue has been reported in this stack overflow question as well: https://stackoverflow.com/questions/46296919/haskell-webframeworks-speed- ghci-vs-compiled . There is an appalling difference in the ghc compiled code vs ghci code, in case of snap it is a 50x difference! That sounds unacceptable whatever the reason maybe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 11:38:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 11:38:39 -0000 Subject: [GHC] #14237: -Wredundant-constraints incorrectly treats all type equality constraints as redundant In-Reply-To: <050.e3dc094564bbfbd54906e6f9a94f2531@haskell.org> References: <050.e3dc094564bbfbd54906e6f9a94f2531@haskell.org> Message-ID: <065.137e806113e71572df32a716b38336ae@haskell.org> #14237: -Wredundant-constraints incorrectly treats all type equality constraints as redundant -------------------------------------+------------------------------------- Reporter: lexi.lambda | 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: #12700 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1db0f4a48e9db5e85782e32f074cc83bbc145cb7/ghc" 1db0f4a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1db0f4a48e9db5e85782e32f074cc83bbc145cb7" Fix unused-given-constraint bug This bug was shown up by Trac #14237. It turned out to be an outright error in TcSimplify.neededEvVars, easily fixed. I improved the comments. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 12:04:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 12:04:56 -0000 Subject: [GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" In-Reply-To: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> References: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> Message-ID: <062.6f773c7cc44757b14ca0c9cfcdf9c8f2@haskell.org> #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I agree that if the only difference is which exception is raised, then it's like `exn1 + exn2` and we can be imprecise about which one we get. But since you don't give an algorithm, it's hard to tell whether that's all that can happen. For example {{{ f :: T -> T -> Int f A A = 1 f B A = 2 f C _ = 3 f2 :: T -> T -> Int f2 A A = 1 f2 A B = 2 f2 _ C = 3 }}} Here `f1 C exn` will return 3, but `f2 exn C` will throw `exn`. So order matters here. I guess you need to prove that the algorithm you use doesn't change semantics. The other question is this: what performance is on the table? It'd be more convincing if you had some examples where better pattern-match compilation causes significantly less code, or better performance. I'm sure the pattern-match compiler will be more complicated, and we want to trade that complexity for some tangible benefit. You can probably start to answer this question with some hand-written A/B examples: "if we had a better compiler we'd get this much better code". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 12:06:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 12:06:53 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDI0MDogQ1NF4oCZaW5nIHcvd+KAmWVkIGNv?= =?utf-8?q?de_regresses_program_runtime?= In-Reply-To: <046.5c37d5e63156613df1c04fdc18ec8c04@haskell.org> References: <046.5c37d5e63156613df1c04fdc18ec8c04@haskell.org> Message-ID: <061.1b2a4fc76a1389ea27b981f76a41879f@haskell.org> #14240: CSE’ing w/w’ed code regresses program runtime -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new 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 simonpj): Wow that is surprising. I wonder if there is any allocation change, or only runtime... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 12:19:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 12:19:29 -0000 Subject: [GHC] #14237: -Wredundant-constraints incorrectly treats all type equality constraints as redundant In-Reply-To: <050.e3dc094564bbfbd54906e6f9a94f2531@haskell.org> References: <050.e3dc094564bbfbd54906e6f9a94f2531@haskell.org> Message-ID: <065.5f4437611f613860fa890188a20b11c5@haskell.org> #14237: -Wredundant-constraints incorrectly treats all type equality constraints as redundant -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #12700 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * milestone: => 8.2.2 Comment: Thanks for reporting this. It was an outright bug, but easy to fix. Merge to 8.2 if poss. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 12:35:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 12:35:59 -0000 Subject: [GHC] #14190: Typeable imposes seemingly redundant constraints on polykinded instances In-Reply-To: <045.10ac00c982131e42012d99b318054ca4@haskell.org> References: <045.10ac00c982131e42012d99b318054ca4@haskell.org> Message-ID: <060.186c84f936c64c3a492af49b22b0a36a@haskell.org> #14190: Typeable imposes seemingly redundant constraints on polykinded instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Typeable Operating System: 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): Regarding comment:7, I'm not sure how easy it would be to implement this. Goldfire will need to comment here, but it seems like this may be hard as there is nothing tying `k` back to `a`. One way of hacking around this might be to add `Typeable k` evidence to the solved dictionary cache every time we solve for `Typeable (a :: k)`. However, this would lead to the production of lots of redundant evidence and just feels terribly wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 12:36:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 12:36:12 -0000 Subject: [GHC] #13959: substTyVar's definition is highly dubious In-Reply-To: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> References: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> Message-ID: <065.28540c832699aaac016a3f59b95b3e6d@haskell.org> #13959: substTyVar's definition is highly dubious -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm not. Do add it to your queue, Richard. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 13:04:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 13:04:27 -0000 Subject: [GHC] #14206: Add bit deposit and bit extraction primops In-Reply-To: <047.2543734720307265ea1bddd575e5fddb@haskell.org> References: <047.2543734720307265ea1bddd575e5fddb@haskell.org> Message-ID: <062.538b8a436dbdbb0a2793357672b572f3@haskell.org> #14206: Add bit deposit and bit extraction primops -------------------------------------+------------------------------------- Reporter: newhoggy | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Yes, let's follow gcc. However, for better or worse GHC uses `-f` flags for machine characteristics (although perhaps this should change in the long-term). Perhaps just use `-fbmi2`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 13:46:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 13:46:55 -0000 Subject: [GHC] #13586: ghc --make seems to leak memory In-Reply-To: <054.b9022cd384af70aab8c44b70e8c723cb@haskell.org> References: <054.b9022cd384af70aab8c44b70e8c723cb@haskell.org> Message-ID: <069.23541f84b51911116d31e8a68befb855@haskell.org> #13586: ghc --make seems to leak memory -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13379 #13564 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Do you have an small-ish example which exhibits this? We should profile it if so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 14:21:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 14:21:54 -0000 Subject: [GHC] #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers In-Reply-To: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> References: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> Message-ID: <062.adb66c93a31079c21e7f18043d99cce5@haskell.org> #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Prelude | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #12537 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * milestone: => 8.4.1 Comment: This is quite bad; we should likely just require GCC 4.7 and use the new intrinsics in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 14:24:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 14:24:02 -0000 Subject: [GHC] #13586: ghc --make seems to leak memory In-Reply-To: <054.b9022cd384af70aab8c44b70e8c723cb@haskell.org> References: <054.b9022cd384af70aab8c44b70e8c723cb@haskell.org> Message-ID: <069.9a78dfa40196f249561135fb34903251@haskell.org> #13586: ghc --make seems to leak memory -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13379 #13564 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Nope, and reducing the example reduces the problem, because it needs lots of specializations, so lots of code, to trigger. However, I guess one could construct a cheaper, artificial example with n simple functions specialized to m types and thus get n*m specializations (I only have 1--2 types for each functions in my example, so I need lots of code). I wonder if we already have such example in GHC test suite. If so, we'd only need a variant where specializations is split between 2 modules and compare the time/heap as n and m grow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 14:28:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 14:28:37 -0000 Subject: [GHC] #14199: Document Type.Reflection better (Fun and Con') In-Reply-To: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> References: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> Message-ID: <060.25be5c8564a007930f216eaf3056ceaf@haskell.org> #14199: Document Type.Reflection better (Fun and Con') -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: bug | Status: merge Priority: high | Milestone: 8.2.2 Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3943 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks David, that is quite helpful feedback. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 14:34:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 14:34:21 -0000 Subject: [GHC] #14251: LLVM Code Gen messes up registers Message-ID: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> #14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.3 (LLVM) | 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: -------------------------------------+------------------------------------- Due to the way the LLVM Code Gen generates Function Singnatures, it is possible to end up mixed up registers. A slightly adapted T8064 {{{#!hs {-# LANGUAGE MagicHash, BangPatterns #-} module Main where import GHC.Exts {-# NOINLINE f #-} f :: (Int# -> Float# -> Double# -> Float# -> Double# -> String) -> String f g = g 3# 4.0# 5.0## 6.0# 6.9## ++ " World!" {-# NOINLINE p #-} p :: Int# -> Float# -> Double# -> Float# -> Double# -> String p i j k l m = "Hello" {-# NOINLINE q #-} q :: Int# -> Int# -> Float# -> Double# -> Float# -> Double# -> String q _ i j k l m = "Hello " ++ show (F# l) ++ " " ++ show (D# m) {-# NOINLINE r #-} r :: Int# -> Float# -> Double# -> Float# -> Double# -> String r i = let !(I# z) = length [I# 1# .. I# i] in \j k l m -> p z j k l m -- ghc won't eta-expand around the length, because it has unknown cost main = do putStrLn (f p) -- fast call putStrLn (f r) -- slow call: function but wrong arity let g = last [q 1#] putStrLn (f g) -- slow call: thunk }}} will produce the following results: {{{ ../inplace/bin/ghc-stage1 -fllvm -fforce-recomp T6084.hs -O2 -o T6084-llvm && ./T6084-llvm [1 of 1] Compiling Main ( T6084.hs, T6084.o ) Linking T6084-llvm ... Hello World! Hello World! Hello 4.0 5.0 World! ../inplace/bin/ghc-stage1 -fasm -fforce-recomp T6084.hs -O2 -o T6084-asm && ./T6084-asm [1 of 1] Compiling Main ( T6084.hs, T6084.o ) Linking T6084-asm ... Hello World! Hello World! Hello 6.0 6.9 World! }}} The underlying reason is that (at least for X86_64) the Float and Double registers alternate. The llvm code gen creates function signatures based on the live registers (instead of all). For `q` only the last Float and Double register are `live`. However when calling `q` we pass `f1: Float -> d1: Double -> f2: Float -> d2: Double`. `f2` and `d2` are silently ignored, and in the function body, we now have `f2 <- f1` and `d2 <- d1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 14:35:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 14:35:42 -0000 Subject: [GHC] #14251: LLVM Code Gen messes up registers In-Reply-To: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> References: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> Message-ID: <062.786eb490e150ef111b0712e8b7e54eea@haskell.org> #14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (LLVM) | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): Reasoing for `putStrLn (f g)` {{{ putStrLn (f g) = putStrLn (f (last [q 1#])) = putStrLn (f (q 1#)) = putStrLn ((q 1#) 3# 4.0# 5.0## 6.0# 6.9## ++ " World!") = putStrLn (q 1# 3# 4.0# 5.0## 6.0# 6.9## ++ " World!") = putStrLn ("Hello " ++ show (F# 6.0#) ++ " " ++ show (D# 6.9##) ++ " World!") = putStrLn ("Hello 6.0 6.9 World!") }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 14:37:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 14:37:31 -0000 Subject: [GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" In-Reply-To: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> References: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> Message-ID: <062.eceb4ca0bda74774ae49ea0fbd6c8b79@haskell.org> #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * Attachment "trac_pm_example1.hs" added. One case where PM currently generates very suboptimal code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 14:44:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 14:44:04 -0000 Subject: [GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" In-Reply-To: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> References: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> Message-ID: <062.63041e91f0d9b90bd946b9d86aeb2e76@haskell.org> #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * Attachment "trac_pm_example2.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 15:20:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 15:20:59 -0000 Subject: [GHC] #14199: Document Type.Reflection better (Fun and Con') In-Reply-To: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> References: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> Message-ID: <060.5c66bfa8318d724bdaeff23df1bf60c2@haskell.org> #14199: Document Type.Reflection better (Fun and Con') -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: bug | Status: merge Priority: high | Milestone: 8.2.2 Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3943, Wiki Page: | Phab:D3991 -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D3943 => Phab:D3943, Phab:D3991 Comment: There's some more documentation improvements in Phab:D3991. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 15:28:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 15:28:19 -0000 Subject: [GHC] #13604: ghci no longer loads dynamic .o files by default if they were built with -O In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.cc27359d1fcc70db7402a01e840323ef@haskell.org> #13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3514 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => RecompilationCheck -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 15:29:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 15:29:09 -0000 Subject: [GHC] #7414: plugins always trigger recompilation In-Reply-To: <045.791037be90cd943b6dd26df93dd060d8@haskell.org> References: <045.791037be90cd943b6dd26df93dd060d8@haskell.org> Message-ID: <060.7546f8510bc25376751b83056b0fa20a@haskell.org> #7414: plugins always trigger recompilation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: plugin, | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: plugin, recompilation => plugin, RecompilationCheck -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 15:30:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 15:30:45 -0000 Subject: [GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" In-Reply-To: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> References: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> Message-ID: <062.0e960e877cf0fd54fb9e4bd0f7adaad0@haskell.org> #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): > But since you don't give an algorithm, it's hard to tell whether that's all that can happen.\\ > > Here f1 C exn will return 3, but f2 exn C will throw exn. So order matters here. \\ > I guess you need to prove that the algorithm you use doesn't change semantics. Indeed. I aim to maintain strictness properties of the current algorithm and if I manage that this can't happen. Intuitively this follows from the fact that if we maintain strictness properties and one of the arguments contains a exception we are guaranteed to trigger or avoid it if the old algorithm would have done so. Actually matching the strictness is the hard part especially avoiding potential loss of strictness. So far I worked out a way to apply good decision trees when I ignore the loss of strictness and a way to prevent loss of strictness on paper. I haven't yet worked out completely how I will combine them and how this will impact the complexity of the algorithm. > You can probably start to answer this question with some hand-written A/B examples: "if we had a better compiler we'd get this much better code". It's easy to come up with examples where the current approach generates unnecessary large code sizes on paper. What I'm not sure about is how often these actually occur in regular code. So my next steps are: 1. Combine maintaining strictness with the approach in good trees. * Implement it for a subset of ghc's patterns outside of ghc. (Constructor/Variable/Wildcard) * Re implement the current approach in the same framework. 2. Put some instrumentation into the pattern matching code and sample patterns from as much code as I can. 3. Hopefully get results indicating that it's worth implementing in GHC. 4. Implement it as part of GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 15:30:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 15:30:58 -0000 Subject: [GHC] #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.122bfa4c042c5a805fb8349af6d7eb0d@haskell.org> #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This is odd. I can't reproduce what you are seeing. I get this, measuring allocation {{{ HEAD, separate modules, but with {-# INLINABLE #-} on toList -O0 496M -O1 160M -O1 -fno-pre-inlining 312M HEAD, One module -O0 496M -O1 160M -O1 -fno-pre-inlining 312M GHC-8.2-branch, one module -O0 496M -O1 160M -O1 -fno-pre-inlining 312M }}} Here's the code I'm using (I had to add `instance Semigroup (List a)`: {{{ module Main where import Control.Monad (liftM) import Data.Semigroup (Semigroup(..)) -- import T14208a ------------------------------- data List a = Stop | Yield a (List a) instance Monoid (List a) where mempty = Stop mappend x y = case x of Stop -> y Yield a r -> Yield a (mappend r y) instance Semigroup (List a) where (<>) = mappend toList :: Monad m => List a -> m [a] toList m = case m of Stop -> return [] Yield a r -> liftM (a :) (toList r) -------------------------------- len :: IO Int len = do xs <- toList $ (foldr mappend mempty $ map (\x -> Yield x Stop) [1..1000000 :: Int]) return (length xs) main = do { x <- len; print x } }}} With "two files" I pushed the stuff between the lines into a separate file. I did an an INLINABLE pragma for `toList`. And I multiplied the limit count by 10. I did not use Criterion (less to depend on). Can you say more precisely how to reproduce the problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 15:31:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 15:31:14 -0000 Subject: [GHC] #13002: :set -O does not work in .ghci file In-Reply-To: <045.1c938219ffdaa14f896f37fe62db4c60@haskell.org> References: <045.1c938219ffdaa14f896f37fe62db4c60@haskell.org> Message-ID: <060.a811514b92eafb8c296f3df8168510b6@haskell.org> #13002: :set -O does not work in .ghci file -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => RecompilationCheck -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 15:31:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 15:31:41 -0000 Subject: [GHC] #7277: Recompilation check fails for TH unless functions are inlined In-Reply-To: <050.603d1a84b9f7903399d4601701fdbcaa@haskell.org> References: <050.603d1a84b9f7903399d4601701fdbcaa@haskell.org> Message-ID: <065.4c4fe516b19a33bf5fe456cf0abcae1a@haskell.org> #7277: Recompilation check fails for TH unless functions are inlined -------------------------------------+------------------------------------- Reporter: orenbenkiki | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.4.2 Resolution: | Keywords: | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: 481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => RecompilationCheck -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 15:32:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 15:32:00 -0000 Subject: [GHC] #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS In-Reply-To: <048.43f14cd5930ab5b814c814d30cfc4c67@haskell.org> References: <048.43f14cd5930ab5b814c814d30cfc4c67@haskell.org> Message-ID: <063.e6337a4ccf0a5d04b3dc08ac45f125f1@haskell.org> #12567: `ghc --make` recompiles unchanged files when using `-fplugin` OPTIONS -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: plugin, | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => plugin, RecompilationCheck -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 15:38:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 15:38:22 -0000 Subject: [GHC] #14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint In-Reply-To: <049.dc7f2b094945252a1bcc71f807a43fac@haskell.org> References: <049.dc7f2b094945252a1bcc71f807a43fac@haskell.org> Message-ID: <064.4fbaedcec5d9d7d8e7593e9f6ab588c0@haskell.org> #14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint -------------------------------+-------------------------------------- Reporter: mutantmell | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: ApplicativeDo Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by bgamari): So you would like something like, {{{ ApplicativeDo is enabled yet Monad is required due to irrefutable pattern match; perhaps you want to make the match refutable by adding a ~? }}} Is this right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 15:43:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 15:43:00 -0000 Subject: [GHC] #14215: Coordinate re Cabal-2.0.0.3 or Cabal-2.0.1 release In-Reply-To: <042.f2da5496c03c753cd8a87d1fc1022cfc@haskell.org> References: <042.f2da5496c03c753cd8a87d1fc1022cfc@haskell.org> Message-ID: <057.b9c50348b908a453f479585484ff30f7@haskell.org> #14215: Coordinate re Cabal-2.0.0.3 or Cabal-2.0.1 release -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: task | Status: upstream Priority: high | Milestone: 8.2.2 Component: libraries | Version: 8.2.1 (other) | Resolution: | Keywords: Operating System: 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): hvr says that things are mostly ready now; I'll bump tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 15:46:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 15:46:25 -0000 Subject: [GHC] #14243: GHC doesn't add constraint when deriving In-Reply-To: <051.c8a69e4b23eafe74b02bc02a195cf182@haskell.org> References: <051.c8a69e4b23eafe74b02bc02a195cf182@haskell.org> Message-ID: <066.71fb49e47d86e6dd934d62020d2950d3@haskell.org> #14243: GHC doesn't add constraint when deriving -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: RyanGlScott (added) Comment: It seems like this may fall in Ryan's territory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 15:54:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 15:54:00 -0000 Subject: [GHC] #14229: Contraditions in users_guide/using-warnings.html In-Reply-To: <054.d6f9d16cc1b1fa988ffa9396c0d0581c@haskell.org> References: <054.d6f9d16cc1b1fa988ffa9396c0d0581c@haskell.org> Message-ID: <069.350980ca020ba5cc7ba163218b29f0c1@haskell.org> #14229: Contraditions in users_guide/using-warnings.html -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => newcomers Comment: Indeed we have the `newcomers` tag for precisely this reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 16:10:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 16:10:44 -0000 Subject: [GHC] #14243: GHC doesn't add constraint when deriving In-Reply-To: <051.c8a69e4b23eafe74b02bc02a195cf182@haskell.org> References: <051.c8a69e4b23eafe74b02bc02a195cf182@haskell.org> Message-ID: <066.48ac9b2335d693fa702b5bc41f0d7fc0@haskell.org> #14243: GHC doesn't add constraint when deriving -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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 Iceland_jack): I don't remember if GHC rejects constraints with type families / that require `FlexibleContexts`, but here it infers the missing constraint -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 16:17:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 16:17:56 -0000 Subject: [GHC] #14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint In-Reply-To: <049.dc7f2b094945252a1bcc71f807a43fac@haskell.org> References: <049.dc7f2b094945252a1bcc71f807a43fac@haskell.org> Message-ID: <064.58c6d04eabbf84372bf20be322044b9a@haskell.org> #14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint -------------------------------+-------------------------------------- Reporter: mutantmell | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: ApplicativeDo Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by mutantmell): That would be excellent, yes. Do you want me to file a ticket about this, or take some other action? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 16:50:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 16:50:30 -0000 Subject: [GHC] #14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint In-Reply-To: <049.dc7f2b094945252a1bcc71f807a43fac@haskell.org> References: <049.dc7f2b094945252a1bcc71f807a43fac@haskell.org> Message-ID: <064.4006f6f111ddf33178cb48be4c6e31c7@haskell.org> #14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint -------------------------------+-------------------------------------- Reporter: mutantmell | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: ApplicativeDo Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by bgamari): Yes, a ticket would be great. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 17:05:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 17:05:32 -0000 Subject: [GHC] #14252: ApplicativeDo: Add compiler message about irrefutable pattern matches and Monad constraints Message-ID: <049.ba8647167d92eb8735a641eef09d2a89@haskell.org> #14252: ApplicativeDo: Add compiler message about irrefutable pattern matches and Monad constraints -------------------------------------+------------------------------------- Reporter: mutantmell | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Add an error message to the compiler when ApplicativeDo desugaring: * requires a Monad constraint when a Functor/Applicative constraint is expected * Adding a lazy pattern match could allow the Functor/Applicative constraint bgamari suggests something like the following message: {{{#!hs ApplicativeDo is enabled yet Monad is required due to irrefutable pattern match; perhaps you want to make the match refutable by adding a ~? }}} Background: In GHC 8.2.1, ApplicativeDo desugaring was changed to require monad constraints when using a strict pattern match (see #13875 for details). While this behavior is a requirement for maintaining the intended semantics of ApplicativeDo, it is both a breaking change, and somewhat unintuitive (see #14249). Adding a message would provide both clarification around the requirement, and provide a simple resolution for the common use case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 17:06:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 17:06:20 -0000 Subject: [GHC] #14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint In-Reply-To: <049.dc7f2b094945252a1bcc71f807a43fac@haskell.org> References: <049.dc7f2b094945252a1bcc71f807a43fac@haskell.org> Message-ID: <064.48397937622753dd76c3fc77b034d033@haskell.org> #14249: ApplicativeDo: Pattern matching on a bind forces a Monad constraint -------------------------------+-------------------------------------- Reporter: mutantmell | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: ApplicativeDo Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by mutantmell): I created #14252, and referenced this ticket and #13875. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 17:06:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 17:06:25 -0000 Subject: [GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" In-Reply-To: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> References: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> Message-ID: <062.244ea83efa48b77318a8853ef6293944@haskell.org> #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): I realized I have no written anything about how to actually do this.\\ Nothing of this is set in stone yet but generally: To prevent additional strictness we can always limit argument evaluation to these columns which will be evaluated for any result (ignoring the possibility of pattern match failure). While we do have to compute that property for each column it should be able to do this while getting the data required to pick a good column. So I don't expect that to be too expensive. Preventing loss of strictness is a lot more expensive to calculate I fear. I also did not yet think much about how this impacts potential performance gains or how to optimize/implement it. So with this pretext here we go: Given a matrix of patterns based on your example {{{ A A A B _ C }}} My current idea is to associate constraints with each element starting without no constraints. If we chose column 2 we get on decomposition for C a matrix consisting only of `_`. However during matrix decomposition we check for constraints resulting from our selection and add these to the remaining matrix. In this case we would generate {Col1 != bot} for that entry.\\ When selecting a column we first have to resolve constraints associated with it. So while the resulting matrix has only a wildcard the constraint forces us the generate a case statement for the column ensuring the first parameter gets evaluated. Constraints are created by looking at the rows we eliminate based on the result we generate code for. But I have not yet formalized that to a degree where a detailed writeup on the specifics makes sense. While this is guaranteed to be more expensive then the current approach i hope to that performance gains as well as less work required by the simplifier makes up for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 17:22:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 17:22:22 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism In-Reply-To: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> References: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> Message-ID: <063.5b74fb9a4a2529dae7320969e59dd5da@haskell.org> #13929: GHC panic with levity polymorphism -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed this still fails with the unboxed sum example. Adding a test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 17:36:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 17:36:22 -0000 Subject: [GHC] #14252: ApplicativeDo: Add compiler message about irrefutable pattern matches and Monad constraints In-Reply-To: <049.ba8647167d92eb8735a641eef09d2a89@haskell.org> References: <049.ba8647167d92eb8735a641eef09d2a89@haskell.org> Message-ID: <064.abc670a1087ebe391b8a967171085812@haskell.org> #14252: ApplicativeDo: Add compiler message about irrefutable pattern matches and Monad constraints -------------------------------------+------------------------------------- Reporter: mutantmell | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Add an error message to the compiler when ApplicativeDo desugaring: > * requires a Monad constraint when a Functor/Applicative constraint is > expected > * Adding a lazy pattern match could allow the Functor/Applicative > constraint > > bgamari suggests something like the following message: > > {{{#!hs > ApplicativeDo is enabled yet Monad is required due to irrefutable pattern > match; > perhaps you want to make the match refutable by adding a ~? > }}} > > Background: > > In GHC 8.2.1, ApplicativeDo desugaring was changed to require monad > constraints when using a strict pattern match (see #13875 for details). > While this behavior is a requirement for maintaining the intended > semantics of ApplicativeDo, it is both a breaking change, and somewhat > unintuitive (see #14249). Adding a message would provide both > clarification around the requirement, and provide a simple resolution for > the common use case. New description: Add an error message to the compiler when ApplicativeDo desugaring: * requires a Monad constraint when a Functor/Applicative constraint is expected * Adding a lazy pattern match could allow the Functor/Applicative constraint bgamari suggests something like the following message: {{{ ApplicativeDo is enabled yet Monad is required due to irrefutable pattern match; perhaps you want to make the match refutable by adding a ~? }}} Background: In GHC 8.2.1, ApplicativeDo desugaring was changed to require monad constraints when using a strict pattern match (see #13875 for details). While this behavior is a requirement for maintaining the intended semantics of ApplicativeDo, it is both a breaking change, and somewhat unintuitive (see #14249). Adding a message would provide both clarification around the requirement, and provide a simple resolution for the common use case. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 17:36:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 17:36:35 -0000 Subject: [GHC] #14252: ApplicativeDo: Add compiler message about irrefutable pattern matches and Monad constraints In-Reply-To: <049.ba8647167d92eb8735a641eef09d2a89@haskell.org> References: <049.ba8647167d92eb8735a641eef09d2a89@haskell.org> Message-ID: <064.c1c2c75f6f6e8f802102b050d682337d@haskell.org> #14252: ApplicativeDo: Add compiler message about irrefutable pattern matches and Monad constraints -------------------------------------+------------------------------------- Reporter: mutantmell | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 17:43:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 17:43:32 -0000 Subject: [GHC] #14221: yaml-0.8.23.3 fails to build with -g In-Reply-To: <046.9dadad43b611bdb3c19cc87ee92d4f08@haskell.org> References: <046.9dadad43b611bdb3c19cc87ee92d4f08@haskell.org> Message-ID: <061.81ca06b213a722a289edf9f2efb87845@haskell.org> #14221: yaml-0.8.23.3 fails to build with -g -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | 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:D3977 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8b007abbeb3045900a11529d907a835080129176/ghc" 8b007ab/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8b007abbeb3045900a11529d907a835080129176" nativeGen: Consistently use blockLbl to generate CLabels from BlockIds This fixes #14221, where the NCG and the DWARF code were apparently giving two different names to the same block. Test Plan: Validate with DWARF support enabled. Reviewers: simonmar, austin Subscribers: rwbarton, thomie GHC Trac Issues: #14221 Differential Revision: https://phabricator.haskell.org/D3977 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 17:43:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 17:43:32 -0000 Subject: [GHC] #14235: Suspiciously missing closure types in isRetainer In-Reply-To: <046.29af8d0b9a3a3d8c4d9ba9ecb9f4e7a7@haskell.org> References: <046.29af8d0b9a3a3d8c4d9ba9ecb9f4e7a7@haskell.org> Message-ID: <061.ade315395dfd6da96a05869a58acd9ef@haskell.org> #14235: Suspiciously missing closure types in isRetainer -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3967 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6252292d4f4061f6e55c7f92a399160147c4ca74/ghc" 6252292d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6252292d4f4061f6e55c7f92a399160147c4ca74" rts/RetainerProfile: Adding missing closure types to isRetainer orzo in `#ghc` reported seeing a crash due to the retainer profiler encountering a BLOCKING_QUEUE closure, which isRetainer didn't know about. I performed an audit to make sure that all of the valid closure types were listed; they weren't. This is my guess of how they should appear. Test Plan: Validate Reviewers: simonmar, austin, erikd Reviewed By: simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #14235 Differential Revision: https://phabricator.haskell.org/D3967 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 17:43:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 17:43:32 -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.3e50b3452f9c37b23c91d8eb4f5014c7@haskell.org> #14242: Ticks and join points don't play well -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"12a92fedf8b1997f2e26800929be117d54536b7e/ghc" 12a92fed/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="12a92fedf8b1997f2e26800929be117d54536b7e" OccurAnal: Ensure SourceNotes don't interfere with join-point analysis In general ticks are problematic for join point analysis as described in #14242. However, source notes are intended to be a best-effort annotation which shouldn't interfere with optimization. Special-case these to ensure that tail-call information is still correct, even in the presence of source note ticks. Test Plan: Validate Reviewers: simonpj, austin Reviewed By: simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #14242 Differential Revision: https://phabricator.haskell.org/D3978 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 17:56:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 17:56:46 -0000 Subject: [GHC] #14243: GHC doesn't add constraint when deriving In-Reply-To: <051.c8a69e4b23eafe74b02bc02a195cf182@haskell.org> References: <051.c8a69e4b23eafe74b02bc02a195cf182@haskell.org> Message-ID: <066.3132e1be36bf10ad31612e22622c4ca9@haskell.org> #14243: GHC doesn't add constraint when deriving -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: #11008 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #11008 Comment: This is expected behavior. Here's a much simpler demonstration of this phenomenon: {{{#!hs {-# LANGUAGE TypeFamilies #-} type family Foo data Bar = Bar Foo deriving Show }}} {{{ Bug.hs:4:29: error: • No instance for (Show Foo) arising from the first field of ‘Bar’ (type ‘Foo’) Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (Show Bar) | 4 | data Bar = Bar Foo deriving Show | ^^^^ }}} As you noted, GHC could theoretically add this inferred `Show Foo` constraint to the derived instance context, but it chooses not to. The reasoning is outlined in [https://downloads.haskell.org/~ghc/8.2.1/docs/html/users_guide/glasgow_exts.html #inferred-context-for-deriving-clauses this section] of the users' guide. Essentially, GHC has a metric for determining whether an inferred context is "exotic", and if a constraint is considered too exotic, GHC will give up and demand that you write the context yourself using `StandaloneDeriving`. There are a couple of reasons why GHC does this. One reason is that exotic constraints are often not Haskell98/2010, so inferring them would be troublesome. But perhaps a more compelling reason is it can sometimes catch mistakes, like in this code: {{{#!hs data X a b = MkX (a -> b) deriving Eq }}} This fails, complaining about a missing `Eq (a -> b)` instance. This is almost certainly the desired behavior, since you probably didn't mean to use an `Eq` instance for function types in the first place! If you're determined that this is the right thing to do, however, GHC gives you a manual override in the form of `StandaloneDeriving`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 18:22:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 18:22:33 -0000 Subject: [GHC] #14235: Suspiciously missing closure types in isRetainer In-Reply-To: <046.29af8d0b9a3a3d8c4d9ba9ecb9f4e7a7@haskell.org> References: <046.29af8d0b9a3a3d8c4d9ba9ecb9f4e7a7@haskell.org> Message-ID: <061.f5941cbe9dd656ddf7dcc1b74995f8e3@haskell.org> #14235: Suspiciously missing closure types in isRetainer -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Runtime System | 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:D3967 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 18:43:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 18:43:40 -0000 Subject: [GHC] #13604: ghci no longer loads dynamic .o files by default if they were built with -O In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.5d8471674e5a002e7ecc013339f4fde0@haskell.org> #13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): elaforge, George, can you describe precisely what you would propose that you help with this? I'm not sure teaching `ghci` to ignore `-O` and `-fhpc` is a great idea since there may be users that want to use these flags from within an interactive session. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 18:49:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 18:49:54 -0000 Subject: [GHC] #13075: Top-level bang pattern accepted In-Reply-To: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> References: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> Message-ID: <062.9508e229b83072389d2fcde3887b2ba6@haskell.org> #13075: Top-level bang pattern accepted -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13075 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.2 => 8.4.1 Comment: Perhaps actually 8.4.1 would be more appropriate as it's not a regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 19:04:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 19:04:29 -0000 Subject: [GHC] #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL In-Reply-To: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> References: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> Message-ID: <061.dc061e5baf88a96170f7e9c876b84d77@haskell.org> #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13304 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: highest => high Comment: I'll admit I'm quite confused; I cannot reproduce this in a clean Debian 8 container. It seems that this really //is// WSL-only. In light of this and the fact that GHC isn't really usable on WSL at the moment anyways, I'm going to demote this to high priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 19:31:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 19:31:02 -0000 Subject: [GHC] #9157: cmm common block not eliminated In-Reply-To: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> References: <048.8d2730e58ddaeb1eb1c72b58cf8a9edb@haskell.org> Message-ID: <063.5d3659fe90004c6abcb029b909546ae5@haskell.org> #9157: cmm common block not eliminated -------------------------------------+------------------------------------- Reporter: wojteknar | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: duplicate | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14226 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #14226 Comment: This was reported and fixed as #14226. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 19:31:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 19:31:28 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks In-Reply-To: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> References: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> Message-ID: <061.4168dc00a551d9aaca73c5132b8ef5a2@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157 | Differential Rev(s): Phab:D3973 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #9157 Comment: It turns out this was also previously reported as #9157. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 21:55:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 21:55:20 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.e13e0291f5feb75f05df447e0c189154@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8684 Related Tickets: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c2a1fa7aec426727be6df79f3db109183e42cfdc/ghc" c2a1fa7a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c2a1fa7aec426727be6df79f3db109183e42cfdc" base: Fix fdReady() potentially running forever on Windows. This fixes #13497 for Windows -- at least for the `if (isSock)` part; I haven't investigated the case where it's not a socket yet. Solved by copying the new current-time based waiting logic from the non-Windows implementation above. Reviewers: bgamari, austin, hvr Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3954 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 21:55:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 21:55:20 -0000 Subject: [GHC] #13525: hWaitForInput with timeout causes program to abort In-Reply-To: <046.94d45988b3f89221effa39c9029b4490@haskell.org> References: <046.94d45988b3f89221effa39c9029b4490@haskell.org> Message-ID: <061.a77061ed1eae3aa05de16a16395ddf94@haskell.org> #13525: hWaitForInput with timeout causes program to abort ----------------------------------+-------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: 8684 Related Tickets: #12912, #8684 | Differential Rev(s): Phab:D3473 Wiki Page: | ----------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"ba4dcc7cb77a37486368911fec854d112a1db93c/ghc" ba4dcc7c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ba4dcc7cb77a37486368911fec854d112a1db93c" base: Make it less likely for fdReady() to fail on Windows sockets. See the added comment for details. It's "less likely" because it can still fail if the socket happens to have an FD larger than 1023, which can happen if many files are opened. Until now, basic socket programs that use `hWaitForInput` were broken on Windows. That is because on Windows `FD_SETSIZE` defaults to 64, but pretty much all GHC programs seem to have > 64 FDs open, so you can't actually create a socket on which you can `select()`. It errors with `fdReady: fd is too big` even with an example as simple as the following (in this case, on my machine the `fd` is `284`): {-# LANGUAGE OverloadedStrings #-} import Control.Monad (forever) import Network.Socket import System.IO -- Simple echo server: Reads up to 10 chars from network, echoes them back. -- Uses the Handle API so that `hWaitForInput` can be used. main :: IO () main = do sock <- socket AF_INET Stream 0 setSocketOption sock ReuseAddr 1 bind sock (SockAddrInet 1234 0x0100007f) -- 0x0100007f == 127.0.0.1 localhost listen sock 2 forever $ do (connSock, _connAddr) <- accept sock putStrLn "Got connection" h <- socketToHandle connSock ReadWriteMode hSetBuffering h NoBuffering ready <- hWaitForInput h (5 * 1000) -- 5 seconds putStrLn $ "Ready: " ++ show ready line <- hGetLine h putStrLn "Got line" hPutStrLn h ("Got: " ++ line) hClose h I'm not sure how this was not discovered earlier; for #13525 (where `fdReady()` breaking completely was also discovered late) at least it failed only when the timeout was non-zero, which is not used in ghc beyond in `hWaitForInput`, but in this Windows socket case it breaks even on the 0-timeout. Maybe there is not actually anybody who uses sockets as handles on Windows? The workaround for now is to increase `FD_SETSIZE` on Windows; increasing it is possible on Windows and BSD, see https://stackoverflow.com/questions/7976388/increasing-limit-of-fd-setsi ze-and-select A real fix would be to move to IO Completion Ports on Windows, and thus get rid of the last uses of `select()` (the other platforms already use `poll()` but Windows doesn't have that). Reviewers: bgamari, austin, hvr, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3959 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 21:56:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 21:56:41 -0000 Subject: [GHC] #14189: Renamer does not preserve location for IEThingWith list items In-Reply-To: <044.0c99d438de6c1244d5aee79758fc528d@haskell.org> References: <044.0c99d438de6c1244d5aee79758fc528d@haskell.org> Message-ID: <059.3a75740db126502c9f2622434c6731e0@haskell.org> #14189: Renamer does not preserve location for IEThingWith list items -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 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): Phab:D3968 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 21:56:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 21:56:49 -0000 Subject: [GHC] #14228: PatternSynonyms Non-exhaustive with UnboxedSums In-Reply-To: <045.20b2cde42b5eb75c44e10e92ba8e9b86@haskell.org> References: <045.20b2cde42b5eb75c44e10e92ba8e9b86@haskell.org> Message-ID: <060.2a0357f76d8197a50d38a6eb7e1ba3eb@haskell.org> #14228: PatternSynonyms Non-exhaustive with UnboxedSums -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: UnboxedSums, | PatternSynonyms 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:D3951 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 21:57:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 21:57:18 -0000 Subject: [GHC] #14158: (Control.Category.id @(->) >>=) causes GHC panic In-Reply-To: <051.7aaf122e6f5d5dda86e73aab654427db@haskell.org> References: <051.7aaf122e6f5d5dda86e73aab654427db@haskell.org> Message-ID: <066.de59cbdaf241ed9e90cab8c78d7712bb@haskell.org> #14158: (Control.Category.id @(->) >>=) causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T14158 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 21:57:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 21:57:34 -0000 Subject: [GHC] #14199: Document Type.Reflection better (Fun and Con') In-Reply-To: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> References: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> Message-ID: <060.36c9a08831c34d0998488d68bb08dd24@haskell.org> #14199: Document Type.Reflection better (Fun and Con') -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3943, Wiki Page: | Phab:D3991 -------------------------------------+------------------------------------- Changes (by bgamari): * owner: bgamari => (none) * status: merge => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 21:57:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 21:57:54 -0000 Subject: [GHC] #14199: Document Type.Reflection better (Fun and Con') In-Reply-To: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> References: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> Message-ID: <060.cdf92fd2edeac6cebb1715f3e33ed901@haskell.org> #14199: Document Type.Reflection better (Fun and Con') -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3943, Wiki Page: | Phab:D3991 -------------------------------------+------------------------------------- Comment (by bgamari): comment:4 merged to `ghc-8.2` as 14195b0982135668890f79b7790caf33c6147240. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 21:59:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 21:59:36 -0000 Subject: [GHC] #14158: (Control.Category.id @(->) >>=) causes GHC panic In-Reply-To: <051.7aaf122e6f5d5dda86e73aab654427db@haskell.org> References: <051.7aaf122e6f5d5dda86e73aab654427db@haskell.org> Message-ID: <066.81c6de6a48e964029e3feff4f4661132@haskell.org> #14158: (Control.Category.id @(->) >>=) causes GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T14158 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): comment:6 merged to `ghc-8.2` as 13cd53df15ab38a29c5dfcbdd916ae2ada6ff979. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 22:00:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 22:00:07 -0000 Subject: [GHC] #14189: Renamer does not preserve location for IEThingWith list items In-Reply-To: <044.0c99d438de6c1244d5aee79758fc528d@haskell.org> References: <044.0c99d438de6c1244d5aee79758fc528d@haskell.org> Message-ID: <059.4e66aacf30d87ecfc8be1b48de7f5006@haskell.org> #14189: Renamer does not preserve location for IEThingWith list items -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 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): Phab:D3968 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-8.2` as a153d2f26263181440156380559a90ab792d8260. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 22:00:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 22:00:36 -0000 Subject: [GHC] #14228: PatternSynonyms Non-exhaustive with UnboxedSums In-Reply-To: <045.20b2cde42b5eb75c44e10e92ba8e9b86@haskell.org> References: <045.20b2cde42b5eb75c44e10e92ba8e9b86@haskell.org> Message-ID: <060.d77ae600adcdd4932d15c16c5e599e02@haskell.org> #14228: PatternSynonyms Non-exhaustive with UnboxedSums -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: UnboxedSums, | PatternSynonyms 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:D3951 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): comment:3 merged to `ghc-8.2` as fb5190185b6819ff4f4b64167d37da85337c524c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 22:01:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 22:01:46 -0000 Subject: [GHC] #14163: Stack Overflow with ApplicativeDo In-Reply-To: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> References: <047.d57a4e335d4e0f3ebb5486285de666b9@haskell.org> Message-ID: <062.8a82a103eb33a4508e65b32efe0b2933@haskell.org> #14163: Stack Overflow with ApplicativeDo -------------------------------------+------------------------------------- Reporter: lippling | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: ApplicativeDo 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): Phab:D3900 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:14 merged to `ghc-8.2` as 55b27a3231d6c25bc257006d59b329dd43ac4118. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 22:02:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 22:02:14 -0000 Subject: [GHC] #14096: Residency profiling with eventlog enabled breaks In-Reply-To: <046.b0ac9cb699336e79142ee4ab7e9074ac@haskell.org> References: <046.b0ac9cb699336e79142ee4ab7e9074ac@haskell.org> Message-ID: <061.d335c965e7bab5f8f01a964915014a71@haskell.org> #14096: Residency profiling with eventlog enabled breaks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.2 Component: Runtime System | 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:D3922 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as 46367997b8fab50d442cad0ba75d13340afc8d6b. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 22:02:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 22:02:52 -0000 Subject: [GHC] #13481: T12622 fails in ghci way In-Reply-To: <046.f9d04c6c728f8f80bc5f7c5da4765696@haskell.org> References: <046.f9d04c6c728f8f80bc5f7c5da4765696@haskell.org> Message-ID: <061.cc3760ac79a4bdda81ee4d280b012f17@haskell.org> #13481: T12622 fails in ghci way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: T12622 Blocked By: | Blocking: Related Tickets: #12622, #12356 | Differential Rev(s): Phab:D3920 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as 9565e5267c3376f94f501ec0e1f9ee712a1f6f10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 22:03:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 22:03:25 -0000 Subject: [GHC] #14197: Flag "dump-rn-ast" only dumps the declarations, not the whole RenamedSource In-Reply-To: <044.cc22bc6c087d1948925080ce049a8ac5@haskell.org> References: <044.cc22bc6c087d1948925080ce049a8ac5@haskell.org> Message-ID: <059.f3a8b794c5e63a8e6b6ad80f36966e66@haskell.org> #14197: Flag "dump-rn-ast" only dumps the declarations, not the whole RenamedSource -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 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:D3949 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as 31bf20032ace1caddb540f45f8be4486185dff83. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 22:49:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 22:49:28 -0000 Subject: [GHC] #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable Message-ID: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this program, {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} module Test where import GHC.Exts import Data.Kind data TypeRep (a :: k) where Con :: TypeRep (a :: k) TrFun :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2). TypeRep a -> TypeRep b -> TypeRep (a -> b) pattern Fun :: forall k (fun :: k). () => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (arg :: TYPE r1) (res :: TYPE r2). (k ~ Type, fun ~~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun pattern Fun arg res <- TrFun arg res where Fun arg res = undefined data Dynamic where Dynamic :: forall a. TypeRep a -> a -> Dynamic -- Removing this allows compilation to proceed {-# COMPLETE Con #-} dynApply :: Dynamic -> Dynamic -> Maybe Dynamic -- Changing Fun to TrFun allows compilation to proceed dynApply (Dynamic (Fun ta tr) f) (Dynamic ta' x) = undefined dynApply _ _ = Nothing }}} As written the program fails with, {{{ test.hs:34:1: warning: [-Woverlapping-patterns] Pattern match has inaccessible right hand side In an equation for ‘dynApply’: dynApply (Dynamic (Fun ta tr) f) (Dynamic ta' x) = ... | 34 | dynApply (Dynamic (Fun ta tr) f) (Dynamic ta' x) = undefined | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} This can be worked around by doing one of the following, 1. Removing the `COMPLETE` pragma 2. Changing the use of the `Fun` pattern synonym into a use of the `TrFun` constructor. Something is quite wrong here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 22:54:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 22:54:32 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks In-Reply-To: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> References: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> Message-ID: <061.5da646f6667beab0bfa6a9f5f0e8f2a9@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157 | Differential Rev(s): Phab:D3973 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7920a7d9c53083b234e060a3e72f00b601a46808/ghc" 7920a7d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7920a7d9c53083b234e060a3e72f00b601a46808" cmm/CBE: Collapse blocks equivalent up to alpha renaming of local registers As noted in #14226, the common block elimination pass currently implements an extremely strict equivalence relation, demanding that two blocks are equivalent including the names of their local registers. This is quite restrictive and severely hampers the effectiveness of the pass. Here we allow the CBE pass to collapse blocks which are equivalent up to alpha renaming of locally-bound local registers. This is completely safe and catches many more duplicate blocks. Test Plan: Validate Reviewers: austin, simonmar, michalt Reviewed By: michalt Subscribers: rwbarton, thomie GHC Trac Issues: #14226 Differential Revision: https://phabricator.haskell.org/D3973 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 22:54:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 22:54:32 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.ac5d012fb63ba39de44cee29f30f38de@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Resolution: fixed | Keywords: integer-gmp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8647 #9818 | Differential Rev(s): Phab:D82 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0aba999f60babe6878a1fd2cc8410139358cad16/ghc" 0aba999/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0aba999f60babe6878a1fd2cc8410139358cad16" Restore function powModSecInteger The function existed in integer-gmp-0.5.1.0 but was removed as part of integer-gmp2 rewrite in #9281. This is to bring it back. Test Plan: Case integerGmpInternals, with GMP 4.3.2 and GMP 6.1.2 Reviewers: austin, hvr, goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3947 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 22:54:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 22:54:32 -0000 Subject: [GHC] #13391: PolyKinds is more permissive in GHC 8 In-Reply-To: <047.7921462df1c636dc7a1bfe3d9149887d@haskell.org> References: <047.7921462df1c636dc7a1bfe3d9149887d@haskell.org> Message-ID: <062.7b46b71de05273313d4738e2e8dcca0e@haskell.org> #13391: PolyKinds is more permissive in GHC 8 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3859 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"bbb8cb92b66d83bb7d472e7905c84c28cbb0997c/ghc" bbb8cb92/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bbb8cb92b66d83bb7d472e7905c84c28cbb0997c" users-guide: Mention changes necessary due to #13391 Some variant of this should also be added to the migration guide. [skip ci] Test Plan: Read it Reviewers: goldfire, austin Reviewed By: goldfire Subscribers: rwbarton, thomie GHC Trac Issues: #13391 Differential Revision: https://phabricator.haskell.org/D3966 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 22:54:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 22:54:32 -0000 Subject: [GHC] #14224: zipWith does not inline In-Reply-To: <045.ed8abb37df246f8ea9c4fff482d8cd1e@haskell.org> References: <045.ed8abb37df246f8ea9c4fff482d8cd1e@haskell.org> Message-ID: <060.11086a36901fa6ae27b449585daadcd1@haskell.org> #14224: zipWith does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | 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): Phab:D3986 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"11d9615e9f751d6ed084f1cb20c24ad6b408230e/ghc" 11d9615/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="11d9615e9f751d6ed084f1cb20c24ad6b408230e" Make zipWith and zipWith3 inlinable. Reviewers: austin, hvr, bgamari, dfeuer Reviewed By: dfeuer Subscribers: rwbarton, thomie GHC Trac Issues: #14224 Differential Revision: https://phabricator.haskell.org/D3986 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 22:56:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 22:56:59 -0000 Subject: [GHC] #14224: zipWith does not inline In-Reply-To: <045.ed8abb37df246f8ea9c4fff482d8cd1e@haskell.org> References: <045.ed8abb37df246f8ea9c4fff482d8cd1e@haskell.org> Message-ID: <060.74f59c7cb2c1599f6f5977571dfc97ee@haskell.org> #14224: zipWith does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3986 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Thanks sighingnow! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 23:16:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 23:16:47 -0000 Subject: [GHC] #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable In-Reply-To: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> References: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> Message-ID: <061.e34a57d0a01cf958bce0bdbcf1d9666e@haskell.org> #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: gkaracha, dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 23:25:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 23:25:30 -0000 Subject: [GHC] #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable In-Reply-To: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> References: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> Message-ID: <061.5e5afcb894fae859d2ade3b6fe6fea7e@haskell.org> #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings 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: RyanGlScott (added) * keywords: => PatternSynonyms, PatternMatchWarnings Comment: Here is a much simpler way to trigger the issue: {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Test where data T = MkT1 | MkT2 pattern MkT2' = MkT2 {-# COMPLETE MkT1 #-} newtype S = MkS T u :: S -> Bool u (MkS MkT2') = True u _ = False }}} The fact that `MkT2'` occurs inside of another constructor `MkS` seems to be important, since changing `u` to be of type `T -> Bool` and matching directly on `MkT2'` in the first case resolves the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 19 23:59:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Sep 2017 23:59:19 -0000 Subject: [GHC] #13604: ghci no longer loads dynamic .o files by default if they were built with -O In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.fbed8233498349238b214c08a8451b10@haskell.org> #13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): I'll settle for what Simon suggested: " if the user manual documented the behaviour and the underlying principles. And describes how to work around it if you want something different." Whatever the solution, I'd like to be able to specify the optimization level of compilation, e.g. -O or -02 in a .ghci file as well as by an argument to ghci, so that it will take effect when I compile inside of emacs. i.e. in other words I'd like 13002 fixed too, if possible. The use case here is working with optimized compiled code in emacs/ghci, making changes and measuring the performance; thus you want to be able to compile those changes in emacs at a given optimization level. I think elaforge may want something more specific but I'll let him speak for himself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 00:01:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 00:01:11 -0000 Subject: [GHC] #13002: :set -O does not work in .ghci file In-Reply-To: <045.1c938219ffdaa14f896f37fe62db4c60@haskell.org> References: <045.1c938219ffdaa14f896f37fe62db4c60@haskell.org> Message-ID: <060.5b33d394ef9b66b84fdb485d6c38b819@haskell.org> #13002: :set -O does not work in .ghci file -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by George: Old description: > {{{#!hs > {-# OPTIONS_GHC -Wall #-} > > module Foo where > > testFromTo :: Int -> Int > testFromTo n = length ([0..(10^n)] :: [Int]) > }}} > {{{ > cat ~/.ghci > :set +s > :set -fobject-code > :set -O > bash-3.2$ touch Foo.hs > bash-3.2$ ghci > GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /Users/gcolpitts/.ghci > Prelude> :load Foo > :load Foo > [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) > Ok, modules loaded: Foo (Foo.o). > (0.15 secs,) > Prelude Foo> testFromTo 5 > testFromTo 5 > 100001 > (0.02 secs, 8,885,888 bytes) > Prelude Foo> :quit > :quit > Leaving GHCi. > bash-3.2$ touch Foo.hs > bash-3.2$ ghci -fobject-code -O > GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /Users/gcolpitts/.ghci > Prelude> :load Foo > :load Foo > [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) > Ok, modules loaded: Foo (Foo.o). > (0.15 secs,) > Prelude Foo> testFromTo 5 > testFromTo 5 > 100001 > (0.02 secs, 98,400 bytes) > }}} > > While supplying -fobject-code -O as an argument to ghci seems like an > easy workaround that isn't feasible as far as I know when using emacs > thus setting priority to normal rather than low. New description: {{{#!hs {-# OPTIONS_GHC -Wall #-} module Foo where testFromTo :: Int -> Int testFromTo n = length ([0..(10^n)] :: [Int]) }}} {{{ cat ~/.ghci :set +s :set -fobject-code :set -O bash-3.2$ touch Foo.hs bash-3.2$ ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/gcolpitts/.ghci Prelude> :load Foo :load Foo [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Ok, modules loaded: Foo (Foo.o). (0.15 secs,) Prelude Foo> testFromTo 5 testFromTo 5 100001 (0.02 secs, 8,885,888 bytes) Prelude Foo> :quit :quit Leaving GHCi. bash-3.2$ touch Foo.hs bash-3.2$ ghci -fobject-code -O GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/gcolpitts/.ghci Prelude> :load Foo :load Foo [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Ok, modules loaded: Foo (Foo.o). (0.15 secs,) Prelude Foo> testFromTo 5 testFromTo 5 100001 (0.02 secs, 98,400 bytes) }}} While supplying -fobject-code -O as an argument to ghci seems like an easy workaround; it isn't feasible, as far as I know, when using emacs thus setting priority to normal rather than low. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 01:16:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 01:16:25 -0000 Subject: [GHC] #11984: Pattern match incompleteness / inaccessibility discrepancy In-Reply-To: <047.1cf132bd89a1199ee00c683072ed7b2c@haskell.org> References: <047.1cf132bd89a1199ee00c683072ed7b2c@haskell.org> Message-ID: <062.0ba916e112a7767bd4adf0424257e3f5@haskell.org> #11984: Pattern match incompleteness / inaccessibility discrepancy -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14098 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): In case you're reading this ticket and looking for a workaround, you can add an extra `case` to make it compile without warnings: {{{#!hs {-# LANGUAGE PolyKinds, TypeOperators, DataKinds, TypeFamilies, GADTs #-} module Bug where data family Sing (a :: k) data Schema = Sch [Bool] data instance Sing (x :: Schema) where SSch :: Sing x -> Sing ('Sch x) data instance Sing (x :: [k]) where SNil :: Sing '[] SCons :: Sing a -> Sing b -> Sing (a ': b) data G a where GCons :: G ('Sch (a ': b)) eval :: G s -> Sing s -> () eval GCons s = case s of SSch y -> case y of SCons _ _ -> undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 02:09:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 02:09:17 -0000 Subject: [GHC] #14254: The Binary instance for TypeRep smells a bit expensive Message-ID: <045.b0b485439de28cadfa61420f4ccc13a7@haskell.org> #14254: The Binary instance for TypeRep smells a bit expensive -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: Typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In particular, `get` uses `getSomeTypeRep`. `getSomeTypeRep`, in turn, calls `typeRepKind` through its recursion. But `typeRepKind` is itself recursive, fully inspecting the spine of its argument. That smells quadratic to me. The solution, I believe, is to change the type of `getSomeTypeRep` to `BinHandle -> IO (SomeTypeRep, TypeRep Type)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 02:15:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 02:15:25 -0000 Subject: [GHC] #14254: The Binary instance for TypeRep smells a bit expensive In-Reply-To: <045.b0b485439de28cadfa61420f4ccc13a7@haskell.org> References: <045.b0b485439de28cadfa61420f4ccc13a7@haskell.org> Message-ID: <060.3132178c3281f8ecb3f3c44161aa6d01@haskell.org> #14254: The Binary instance for TypeRep smells a bit expensive -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > In particular, `get` uses `getSomeTypeRep`. `getSomeTypeRep`, in turn, > calls `typeRepKind` through its recursion. But `typeRepKind` is itself > recursive, fully inspecting the spine of its argument. That smells > quadratic to me. The solution, I believe, is to change the type of > `getSomeTypeRep` to `BinHandle -> IO (SomeTypeRep, TypeRep Type)`. New description: In particular, `get` uses `getSomeTypeRep`. `getSomeTypeRep`, in turn, calls `typeRepKind` through its recursion. But `typeRepKind` is itself recursive, fully inspecting the spine of its argument. That smells quadratic to me. The solution, I believe, is to change the type of `getSomeTypeRep` to `BinHandle -> IO (SomeTypeRep, SomeTypeRep)`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 02:32:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 02:32:10 -0000 Subject: [GHC] #14254: The Binary instance for TypeRep smells a bit expensive In-Reply-To: <045.b0b485439de28cadfa61420f4ccc13a7@haskell.org> References: <045.b0b485439de28cadfa61420f4ccc13a7@haskell.org> Message-ID: <060.0e494b9a61f3b73df0a66646b1a68bf1@haskell.org> #14254: The Binary instance for TypeRep smells a bit expensive -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): No, that may not quite solve it, because the `Fun` case has to calculate `typeRepKind res`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 02:55:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 02:55:17 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDI0MDogQ1NF4oCZaW5nIHcvd+KAmWVkIGNv?= =?utf-8?q?de_regresses_program_runtime?= In-Reply-To: <046.5c37d5e63156613df1c04fdc18ec8c04@haskell.org> References: <046.5c37d5e63156613df1c04fdc18ec8c04@haskell.org> Message-ID: <061.366ce3d5cbe774daa8c3594cb9a27e8d@haskell.org> #14240: CSE’ing w/w’ed code regresses program runtime -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: invalid | 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 nomeata): * status: new => closed * resolution: => invalid Comment: changeset:28a115e/ghc “fixed” the `lambda` regression. I conclude that this is a layout issue… I really wish we could get a better handle on these things. Whenever the RTS is touched, even by completely minuscule changes, a few benchmarks go up or down by 3 to 5 runtime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 02:56:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 02:56:26 -0000 Subject: [GHC] #14254: The Binary instance for TypeRep smells a bit expensive In-Reply-To: <045.b0b485439de28cadfa61420f4ccc13a7@haskell.org> References: <045.b0b485439de28cadfa61420f4ccc13a7@haskell.org> Message-ID: <060.89b299e88d01f32f173cfd88e5174f30@haskell.org> #14254: The Binary instance for TypeRep smells a bit expensive -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Typeable 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:D3998 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D3998 * milestone: => 8.4.1 Comment: Very good observation. I think Phab:D3998 should greatly improve the situation. We also need to get a fix into `binary` when an approach has been decided. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 06:39:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 06:39:32 -0000 Subject: [GHC] #14254: The Binary instance for TypeRep smells a bit expensive In-Reply-To: <045.b0b485439de28cadfa61420f4ccc13a7@haskell.org> References: <045.b0b485439de28cadfa61420f4ccc13a7@haskell.org> Message-ID: <060.3b575784d9f0c2a4c1aee9b175e3a66c@haskell.org> #14254: The Binary instance for TypeRep smells a bit expensive -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Typeable 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:D3998 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I have the feeling that `typeRepKind` is just too expensive, considering that it has to be called for `dynApply`, `funResultTy`, and deserialization. Just how bad would it be to expand the `TrApp` and `TrFun` constructors just enough to fit the result kind? Alternatively, would it make sense to add the kind representation to `Dynamic` and to the constraints on `funResultTy` and deserialization? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 07:27:20 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 07:27:20 -0000 Subject: [GHC] #14255: Type-indexed type fingerprints Message-ID: <045.c1ec2f0ceaf2c14abbc2ecd752ef0c71@haskell.org> #14255: Type-indexed type fingerprints -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 8.2.1 Libraries | Keywords: Typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have the feeling that it might well be possible to reduce the size of the trusted codebase somewhat by introducing type-indexed fingerprints. Imagine {{{#!hs data TypeRep (a :: k) where TrTyCon :: {-# UNPACK #-} !FingerprintIx a -> !TyCon -> [SomeTypeRep] -> TypeRep (a :: k) TrApp :: forall k1 k2 (a :: k1 -> k2) (b :: k1). {-# UNPACK #-} !FingerprintIx (a b) -> TypeRep (a :: k1 -> k2) -> TypeRep (b :: k1) -> TypeRep (a b) TrFun :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2). {-# UNPACK #-} !FingerprintIx (a -> b) -> TypeRep a -> TypeRep b -> TypeRep (a -> b) }}} We could have some primitive operations like {{{#!hs mkFunFP :: FingerPrintIx a -> FingerPrintIx b -> FingerPrintIx (a -> b) mkAppFP :: FingerPrintIx (a -> b) -> FingerPrintIx a -> FingerPrintIx b eq :: FingerPrintIx a -> FingerPrintIx b -> Maybe (a :~~: b) eqE :: FingerPrintIx a -> FingerPrintIx b -> Either (a :~~: b -> c) (a :~~: b) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 07:48:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 07:48:11 -0000 Subject: [GHC] #14252: ApplicativeDo: Add compiler message about irrefutable pattern matches and Monad constraints In-Reply-To: <049.ba8647167d92eb8735a641eef09d2a89@haskell.org> References: <049.ba8647167d92eb8735a641eef09d2a89@haskell.org> Message-ID: <064.84195dc2baf24e59fcb5521b5ad30315@haskell.org> #14252: ApplicativeDo: Add compiler message about irrefutable pattern matches and Monad constraints -------------------------------------+------------------------------------- Reporter: mutantmell | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): When you add warnings like this you end up needing another flag to suppress the warning. What if the user says "No, I didn't to make the match irrefutable; quit bugging me". And then a per-module suppression flag is a bit of a blunt instrument. I'm not sure what's best; it would be good to get feedback from `ApplicativeDo` users. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 07:49:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 07:49:46 -0000 Subject: [GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" In-Reply-To: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> References: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> Message-ID: <062.65c53d79063a800ba774b64e19a984a0@haskell.org> #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Sounds complicated enough to be worth a Haskell Symposium paper! Seriously, writing a paper is often a good way to refine an idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 08:00:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 08:00:27 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks In-Reply-To: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> References: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> Message-ID: <061.14ccaab4e6134eb58facb7b64dea41c7@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157 | Differential Rev(s): Phab:D3973 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ben I forgot to mention this. In `CmmExpr` you'll find `foldLocalRegsDefd`, which is, I think, precisely what you need to answer the question "which local regs does this node define". It would be much better to use it than to duplicate the logic into `hash_node` and `eqMiddleWith`. Might you look at doing that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 08:07:15 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 08:07:15 -0000 Subject: [GHC] #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable In-Reply-To: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> References: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> Message-ID: <061.610de42413820e6ec7c80ed834387665@haskell.org> #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings 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'm puzzled though. The `{-# COMPLETE MkT1 #-}` pragma seems like a manifest lie. It claims that any matching on `MkT2` is inaccessible doesn't it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 08:09:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 08:09:21 -0000 Subject: [GHC] #11984: Pattern match incompleteness / inaccessibility discrepancy In-Reply-To: <047.1cf132bd89a1199ee00c683072ed7b2c@haskell.org> References: <047.1cf132bd89a1199ee00c683072ed7b2c@haskell.org> Message-ID: <062.f72a57fd7ff86d2db6336badb7fce72a@haskell.org> #11984: Pattern match incompleteness / inaccessibility discrepancy -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14098 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I'd need someone to give a tour of that section of the codebase, highlighting what each thing does I volunteer to do this. Yell when you'd like a Skype call. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 08:19:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 08:19:17 -0000 Subject: [GHC] #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable In-Reply-To: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> References: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> Message-ID: <061.5e4e3b311d2e740814e45eed281cb1ee@haskell.org> #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:3 simonpj]: > I'm puzzled though. The `{-# COMPLETE MkT1 #-}` pragma seems like a manifest lie. It claims that any matching on `MkT2` is inaccessible doesn't it? `COMPLETE` pragmas are allowed to be lies. Perhaps values built from `MkT1` are never visible outside this module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 08:19:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 08:19:31 -0000 Subject: [GHC] #14255: Type-indexed type fingerprints In-Reply-To: <045.c1ec2f0ceaf2c14abbc2ecd752ef0c71@haskell.org> References: <045.c1ec2f0ceaf2c14abbc2ecd752ef0c71@haskell.org> Message-ID: <060.2e706dcaea0c34cdf409968bfe617b97@haskell.org> #14255: Type-indexed type fingerprints -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: 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 100% lost. What is a fingerprint? How do you create them? How does it reduce the size of the TCB? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 08:22:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 08:22:33 -0000 Subject: [GHC] #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable In-Reply-To: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> References: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> Message-ID: <061.2c928286e2adbf8a6ab91c6b3eff6254@haskell.org> #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings 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): OK, but then lies might give rise to error messages or warnings that lie, mightn't they. As here. We need a specification of the expected behaviour of lying COMPLETE pragmas before we can discuss what programs like these "should" do. Or we could say "if the pragma lies, the compiler can do what it likes". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 08:26:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 08:26:12 -0000 Subject: [GHC] #14255: Type-indexed type fingerprints In-Reply-To: <045.c1ec2f0ceaf2c14abbc2ecd752ef0c71@haskell.org> References: <045.c1ec2f0ceaf2c14abbc2ecd752ef0c71@haskell.org> Message-ID: <060.7253ab03277c199092df9c4562046918@haskell.org> #14255: Type-indexed type fingerprints -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:1 simonpj]: > I'm 100% lost. What is a fingerprint? How do you create them? How does it reduce the size of the TCB? A fingerprint is just a number (a sort of hash) assigned to a type. Fingerprints are used to allow fast comparisons between `TypeRep`s. But they're not really attached to the types they represent, and the unsafe bits of handling them are woven into the larger/more complex `TypeRep` code. I hypothesize that we could compact, if not technically reduce, the TCB by using a separate module for a simple newtype {{{#!hs newtype FingerprintIx a = FingerprintIx Fingerprint }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 08:32:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 08:32:22 -0000 Subject: [GHC] #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable In-Reply-To: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> References: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> Message-ID: <061.8930cacf0377baa367b998e1451df32d@haskell.org> #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Ah, I think Ryan's simplification goes a bit too far, perhaps. I think you'll find Ben's original version convincing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 08:53:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 08:53:33 -0000 Subject: [GHC] #14256: GHCi is faster than compiled code Message-ID: <049.81e3e16f4addaa1f394251f9117591e6@haskell.org> #14256: GHCi is faster than compiled code -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A stackoverflow user Milad Zahedi reports that running his code in GHCi is 50x faster than compiling it and running the compiled binary. > Today I did little benchmarking on my local machine to compare plain text speed of different Haskell web frameworks, and I noticed something strange. Almost all the frameworks that I tested, performed better when they were run from GHCi compared to compiled version. here are my results > {{{ +------------------------------------ |framework| GHCi rpm | compiled rpm +---------+------------+------------- |snap | 8000 | 150 +---------+------------+------------- |yesod | 6000 | 2500 +---------+------------+------------- |scotty | 22000 | 9500 +---------+------------+------------- |servant | 17000 | 8500 +---------+------------+------------- |spock | 3300 | 2700 +---------+------------+------------- }}} > I know that these numbers do not reflect on these frameworks speed, since they are not well tuned or optimized, but my question is why are these frameworks performing better when launched from GHCi. Am I doing something wrong ? > > in order to build them I simply run stack build The benchmarks are from https://github.com/miladz68/haskell-webframework- comparison This ticket is to verify and investigate these claims. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 08:57:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 08:57:00 -0000 Subject: [GHC] #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.53dbaec09360e326907f7b7cb56363c0@haskell.org> #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sibi): * cc: sibi (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 08:58:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 08:58:33 -0000 Subject: [GHC] #14256: GHCi is faster than compiled code In-Reply-To: <049.81e3e16f4addaa1f394251f9117591e6@haskell.org> References: <049.81e3e16f4addaa1f394251f9117591e6@haskell.org> Message-ID: <064.ceb96967dbc15912b22c48ca42b32f15@haskell.org> #14256: GHCi is faster than compiled code -------------------------------------+------------------------------------- Reporter: mpickering | 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: | -------------------------------------+------------------------------------- Changes (by sibi): * cc: sibi (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 09:12:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 09:12:47 -0000 Subject: [GHC] #14190: Typeable imposes seemingly redundant constraints on polykinded instances In-Reply-To: <045.10ac00c982131e42012d99b318054ca4@haskell.org> References: <045.10ac00c982131e42012d99b318054ca4@haskell.org> Message-ID: <060.c299d301df7191bbf1eb26c726ffd917@haskell.org> #14190: Typeable imposes seemingly redundant constraints on polykinded instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Typeable Operating System: 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): Here's how I think of it: 1. Given `r :: TypeRep (t :: k)`, can I somehow obtain `rk :: TypeRep k`? The current answer is "yes": use `typeRepKind r`. 2. Given `d :: Typeable (t :: k)`, can I somehow obtain `dk :: Typeable k`? The answer clearly should be "yes of course", because a `Typeable` dictionary is no more than a wrapper around a `TypeRep`. 3. One way to achieve (2) would to make `Typeable k` a superclass of `Typeable (a::k)`. But that would be stupid. * It'd mean that every `Typeable (t::k)` dictionary was represented as a pair of a dictionary for `Typeable k` and a `TypeRep t`. * But the latter already can provide a `TypeRep k`, via (1) * Moreover that `Typeable k` dictionary would itself be a pair, and so on infinitely. So, assuming we want to continue to have `typeRepKind`, the obvious way forward is to teach the solver that it behaves as a kind of virtual superclass of `Typeable`. That is, if you have `[G] Typeable (t::k)` then, when expanding superclasses, you can extract `Typeable k`. Not terribly hard; we'd need a new `EvTerm` to express that extraction. As with undecidable superclasses we'd only want to do one step at a time. Then, quite separately, we might like to think about how to make `typeRepKind` more efficient. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 10:00:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 10:00:13 -0000 Subject: [GHC] #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best In-Reply-To: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> References: <047.6317840cf59137baa377ba42bf7a7392@haskell.org> Message-ID: <062.4474433f073d808d814be07b8617ea9e@haskell.org> #14208: Performance with O0 is much better than the default or with -O2, runghc performs the best -------------------------------------+------------------------------------- Reporter: harendra | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): It seems, in my repo the cabal file is building the library without any optimization flag and in the different benchmark runs the flag is being changed only on the benchmark module and not on the library. So there is a mixup of optimization flags. Here is the new matrix taking that into account: {{{ Main.hs List.hs INLINE Default ---------------------------------------------------- Identical Flags ---------------------------------------------------- -O1 -O1 4.6 ms 14.2 ms -O0 -O0 14.2 ms 14.2 ms -fno-pre-inlining -fno-pre-inlining 4.6 ms 9.9 ms ---------------------------------------------------- Mixed Flags ---------------------------------------------------- -fno-pre-inlining -O1 4.6 ms 8.8 ms -O0 -O1 8.8 ms 8.8 ms ---------------------------------------------------- runghc ---------------------------------------------------- runghc -O0 5.2 ms 5.2 ms runghc -O1 4.7 ms 4.7 ms }}} Observations: 1. When `toList` is INLINEd the results are more or less expected. Simon, what you are seeing is the INLINE column with identical flags. 2. In the default case (no pragmas are used) `-fno-pre-inlining` does better than `-O1` and runghc seems to be doing well irrespective of the flag used to build the library (i.e. List.hs). Does it mean that `-O1` can also do better in this case? 3. Mixing up the optimization flags brings one more variable in the picture. I would like to ignore those cases. What does GHC recommend? If this is not recommended, is there a way to warn the user when the flags are mixed up? If not, will it be possible to implement something like that? 4. In my original package I am still seeing `-O0` as well as `runghc` doing much better than `-O2`, even when using INLINE pragmas and identical optimization options for all code. I guess, I need to work again to get a simplified example keeping these in mind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 11:15:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 11:15:39 -0000 Subject: [GHC] #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable In-Reply-To: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> References: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> Message-ID: <061.95aabf6bb137e2cf9b974fc2c5137a67@haskell.org> #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings 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): I'm not sure why the original program would be any more honest, since it claims that matching on `TrFun` is inaccessible, right? That is, `Con` is to `MkT1` as `TrFun` is to `MkT2` as `Fun` is to `MkT2'` as `Dynamic` is to `S` as `dynApply` is to `u`. Or am I missing something? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 13:14:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 13:14:04 -0000 Subject: [GHC] #14255: Type-indexed type fingerprints In-Reply-To: <045.c1ec2f0ceaf2c14abbc2ecd752ef0c71@haskell.org> References: <045.c1ec2f0ceaf2c14abbc2ecd752ef0c71@haskell.org> Message-ID: <060.81faa9a03ae24464a1648465f7f0d776@haskell.org> #14255: Type-indexed type fingerprints -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: 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 assume that by "reduce the size of the trusted codebase", you mean eliminating uses of `unsafeCoerce`. But I don't see how indexing fingerprints with types would accomplish this. For example, fingerprints are used in `eqTypeRep`: {{{#!hs eqTypeRep :: forall k1 k2 (a :: k1) (b :: k2). TypeRep a -> TypeRep b -> Maybe (a :~~: b) eqTypeRep a b | typeRepFingerprint a == typeRepFingerprint b = Just (unsafeCoerce HRefl) | otherwise = Nothing }}} Are you envisioning changing this to the following? {{{#!hs eqTypeRep :: forall k1 k2 (a :: k1) (b :: k2). TypeRep a -> TypeRep b -> Maybe (a :~~: b) eqTypeRep a b = eq (typeRepFingerprint a) (typeRepFingerprint b) eq :: FingerPrintIx a -> FingerPrintIx b -> Maybe (a :~~: b) }}} If so, then that would axe one use of `unsafeCoerce`... but how are you planning to implement `eq`? I'm not sure how you would aside from using `unsafeCoerce` again! So we've traded one use of `unsafeCoerce` for another. Perhaps I'm way off base in my assumptions, so please correct me if you had a different vision in mind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 13:32:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 13:32:39 -0000 Subject: [GHC] #8919: Why is xhtml library installed but not exported to users? In-Reply-To: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> References: <045.ff43846276358ed8eb8ece32c648e51e@haskell.org> Message-ID: <060.ed678ee0f76dadcfd6d55bf41b79d289@haskell.org> #8919: Why is xhtml library installed but not exported to users? -------------------------------------+--------------------------------- Reporter: simons | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Build System | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"02ff70563e490d2a7f3141eab7229803c523da57/ghc" 02ff705/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="02ff70563e490d2a7f3141eab7229803c523da57" Add 'stm' package to the global package database This is a preparation for `haskeline` picking up a dependency on `stm` real soon now. See https://github.com/judah/haskeline/pull/61 for details. If we figure out a way to not bundle the libraries depended upon by the GHCi executable in the global package database (see #8919 for the original reason why we had to start bundling terminfo/haskeline in the first place) we can get rid of `stm` again... On the bright side, we were able to avoid uploading new `stm` releases for over two years already, so it shouldn't cause too much trouble if GHC imposes a strong preference on the `stm` package's version (this most likely will mostly affect Linux distributions & similiar). While at it, this also update the stm submodule to include relaxed bounds to allow the upcoming base-4.11 version. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 14:10:07 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 14:10:07 -0000 Subject: [GHC] #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) Message-ID: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) -------------------------------------+------------------------------------- Reporter: carlostome | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.2.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14006 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program generates an invalid .hp file when compiled with ghc 8.2.1 but it does not when using ghc 8.0.2. {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} module Main where eval :: forall a b. (a -> b -> b) -> b -> [a] -> b eval f b xs = load xs [] where load :: [a] -> [a] -> b load [] stk = unload b stk load (x:xs) stk = load xs (x : stk) unload :: b -> [a] -> b unload v [] = v unload v (x : stk) = unload ((f $! x) $! v) stk main :: IO () main = print (eval (||) False (True : replicate 10000000 False)) }}} If strict application ($!) is substituted for normal application ($) or removed then the .hp generated file is correct. For reproducing the error: {{{ ghc -O2 --make -prof -fprof-auto Example.hs -fforce-recomp ./Example +RTS -hc hp2ps -e8in -c Example.hp }}} It outputs: {{{ hp2ps: Example.hp, line 43, samples out of sequence }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 14:36:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 14:36:05 -0000 Subject: [GHC] #14252: ApplicativeDo: Add compiler message about irrefutable pattern matches and Monad constraints In-Reply-To: <049.ba8647167d92eb8735a641eef09d2a89@haskell.org> References: <049.ba8647167d92eb8735a641eef09d2a89@haskell.org> Message-ID: <064.cfe7a4c1f476a2839daeb69c97893f76@haskell.org> #14252: ApplicativeDo: Add compiler message about irrefutable pattern matches and Monad constraints -------------------------------------+------------------------------------- Reporter: mutantmell | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.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: | -------------------------------------+------------------------------------- Description changed by mutantmell: Old description: > Add an error message to the compiler when ApplicativeDo desugaring: > * requires a Monad constraint when a Functor/Applicative constraint is > expected > * Adding a lazy pattern match could allow the Functor/Applicative > constraint > > bgamari suggests something like the following message: > > {{{ > ApplicativeDo is enabled yet Monad is required due to irrefutable pattern > match; > perhaps you want to make the match refutable by adding a ~? > }}} > > Background: > > In GHC 8.2.1, ApplicativeDo desugaring was changed to require monad > constraints when using a strict pattern match (see #13875 for details). > While this behavior is a requirement for maintaining the intended > semantics of ApplicativeDo, it is both a breaking change, and somewhat > unintuitive (see #14249). Adding a message would provide both > clarification around the requirement, and provide a simple resolution for > the common use case. New description: Add an error message to the compiler when: * A user-provided signature specifies a Functor/Applicative constraint * ApplicativeDo desugaring requires a Monad constraint * Adding a lazy pattern match could allow the Functor/Applicative constraint bgamari suggests something like the following message: {{{ ApplicativeDo is enabled yet Monad is required due to irrefutable pattern match; perhaps you want to make the match refutable by adding a ~? }}} Background: In GHC 8.2.1, ApplicativeDo desugaring was changed to require monad constraints when using a strict pattern match (see #13875 for details). While this behavior is a requirement for maintaining the intended semantics of ApplicativeDo, it is both a breaking change, and somewhat unintuitive (see #14249). Adding a message would provide both clarification around the requirement, and provide a simple resolution for the common use case. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 14:41:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 14:41:51 -0000 Subject: [GHC] #14252: ApplicativeDo: Add compiler message about irrefutable pattern matches and Monad constraints In-Reply-To: <049.ba8647167d92eb8735a641eef09d2a89@haskell.org> References: <049.ba8647167d92eb8735a641eef09d2a89@haskell.org> Message-ID: <064.e3957be4128570ef02704d7443eb8e04@haskell.org> #14252: ApplicativeDo: Add compiler message about irrefutable pattern matches and Monad constraints -------------------------------------+------------------------------------- Reporter: mutantmell | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mutantmell): I changed the wording of the ticket to be more clear with my original intent: add a message when a user provided signature clashes with what ApplicativeDo allows, similar to when enabling an extension would allow code to compile. This should be less obtrusive for users who don't want to be bugged, while providing a message that would help people make their code compile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 15:14:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 15:14:44 -0000 Subject: [GHC] #14258: n-body runtime regressed badly due to CoreFVs patch Message-ID: <046.af089daa358f5c8ac207a50826db38ff@haskell.org> #14258: n-body runtime regressed badly due to CoreFVs patch -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- While looking through nofib numbers I noticed that `n-body` regressed in runtime by around 20% due to 751996e90a964026a3f86853338f10c82db6b610. Yikes! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 15:16:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 15:16:36 -0000 Subject: [GHC] #14258: n-body runtime regressed badly due to CoreFVs patch In-Reply-To: <046.af089daa358f5c8ac207a50826db38ff@haskell.org> References: <046.af089daa358f5c8ac207a50826db38ff@haskell.org> Message-ID: <061.676a84651acbf96d2bac57f7cc505430@haskell.org> #14258: n-body runtime regressed badly due to CoreFVs patch -------------------------------------+------------------------------------- Reporter: bgamari | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I should note that there was no corresponding change in allocations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 16:09:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 16:09:48 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.d627fbab4269f5a5c40b8601b71364ca@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 mpickering): Here are the results of running nofib with and without `-fstatic-argument- transformation`. {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- CS 0.0% 0.0% 0.181 0.180 0.0% CSD -0.6% -100.0% -98.0% -98.0% 0.0% FS 0.0% 0.0% -7.5% -7.5% 0.0% S 0.0% 0.0% -0.1% -0.1% 0.0% VS 0.0% 0.0% -0.1% -0.1% 0.0% VSD 0.0% 0.0% 0.008 0.008 0.0% VSM 0.0% 0.0% -10.9% -10.9% 0.0% anna -0.4% +1.4% 0.059 0.059 0.0% ansi 0.0% 0.0% 0.000 0.000 0.0% atom +0.2% -98.6% 0.003 0.003 -33.3% awards 0.0% 0.0% 0.000 0.000 0.0% banner 0.0% 0.0% 0.000 0.000 0.0% bernouilli -0.0% 0.0% 0.093 0.093 0.0% binary-trees 0.0% 0.0% -1.6% -1.6% 0.0% boyer 0.0% 0.0% 0.023 0.023 0.0% boyer2 0.0% 0.0% 0.004 0.004 0.0% bspt +1.0% -0.4% 0.004 0.004 0.0% cacheprof 0.0% -0.1% -0.9% -0.9% -0.9% calendar 0.0% 0.0% 0.000 0.000 0.0% cichelli +0.4% -8.3% 0.037 0.037 0.0% circsim +0.0% 0.0% +1.3% +1.3% 0.0% clausify +0.0% 0.0% 0.020 0.020 0.0% comp_lab_zift +0.9% +0.1% 0.102 0.102 0.0% compress -0.0% -0.1% 0.075 0.075 0.0% compress2 0.0% 0.0% 0.086 0.086 0.0% constraints 0.0% 0.0% +0.3% +0.3% 0.0% cryptarithm1 0.0% 0.0% +8.3% +8.2% 0.0% cryptarithm2 0.0% 0.0% 0.004 0.004 0.0% cse -0.0% 0.0% 0.001 0.001 0.0% digits-of-e1 0.0% 0.0% +5.2% +5.2% 0.0% digits-of-e2 0.0% 0.0% +5.7% +5.7% 0.0% eliza 0.0% 0.0% 0.000 0.000 0.0% event +0.0% +1.2% 0.085 0.085 +9.5% exact-reals 0.0% 0.0% +1.2% +1.2% 0.0% exp3_8 0.0% 0.0% 0.129 0.130 0.0% expert -0.0% +0.0% 0.000 0.000 0.0% fannkuch-redux 0.0% 0.0% -1.2% -1.2% 0.0% fasta 0.0% 0.0% +2.0% +2.1% 0.0% fem 0.0% 0.0% 0.013 0.013 0.0% fft +0.0% -1.0% 0.018 0.018 0.0% fft2 0.0% 0.0% 0.026 0.026 0.0% fibheaps -0.0% +5.9% 0.014 0.014 0.0% fish 0.0% 0.0% 0.006 0.006 0.0% fluid 0.0% 0.0% 0.004 0.004 0.0% fulsom 0.0% 0.0% 0.161 0.161 0.0% gamteb 0.0% 0.0% 0.025 0.025 0.0% gcd 0.0% 0.0% 0.024 0.024 0.0% gen_regexps 0.0% 0.0% 0.000 0.000 0.0% genfft -0.0% -2.6% 0.017 0.017 0.0% gg +0.0% -1.8% 0.005 0.005 0.0% grep 0.0% 0.0% 0.000 0.000 0.0% hidden +0.0% 0.0% -4.9% -5.0% 0.0% hpg +0.0% -0.0% 0.049 0.049 0.0% ida +0.7% +0.1% 0.046 0.046 0.0% infer -0.0% +0.0% 0.029 0.029 0.0% integer 0.0% 0.0% -4.5% -4.5% 0.0% integrate 0.0% 0.0% 0.079 0.079 0.0% k-nucleotide 0.0% 0.0% +0.7% +0.7% 0.0% kahan 0.0% 0.0% 0.195 0.195 0.0% knights +0.0% -0.2% 0.002 0.002 0.0% lambda 0.0% 0.0% 0.0% -0.0% 0.0% last-piece -0.2% +4.6% +3.2% +3.2% 0.0% lcss 0.0% 0.0% -0.6% -0.6% 0.0% life 0.0% 0.0% 0.149 0.149 0.0% lift 0.0% 0.0% 0.001 0.001 0.0% linear 0.0% 0.0% +0.1% +0.1% 0.0% listcompr +0.0% -0.4% 0.055 0.055 0.0% listcopy +0.0% -0.4% 0.059 0.059 0.0% maillist 0.0% 0.0% 0.032 0.033 -2.3% mandel -0.1% 0.0% 0.040 0.040 0.0% mandel2 +0.1% 0.0% 0.002 0.002 0.0% mate +0.2% -5.5% -4.6% -4.6% 0.0% minimax 0.0% 0.0% 0.001 0.001 0.0% mkhprog 0.0% 0.0% 0.001 0.001 0.0% multiplier +0.9% +0.7% 0.054 0.054 0.0% n-body 0.0% 0.0% -0.5% -0.5% 0.0% nucleic2 0.0% 0.0% 0.045 0.045 0.0% para +0.7% -0.5% 0.162 0.162 0.0% paraffins 0.0% 0.0% 0.064 0.064 0.0% parser 0.0% 0.0% 0.015 0.015 0.0% parstof +1.0% +4.0% 0.004 0.004 0.0% pic +0.0% 0.0% 0.004 0.004 0.0% pidigits 0.0% 0.0% -0.1% -0.3% 0.0% power +0.7% +1.5% 0.210 0.210 +9.1% pretty 0.0% 0.0% 0.000 0.000 0.0% primes 0.0% 0.0% 0.039 0.039 0.0% primetest 0.0% 0.0% 0.060 0.060 0.0% prolog +0.1% +0.0% 0.001 0.001 0.0% puzzle 0.0% 0.0% 0.073 0.073 0.0% queens 0.0% 0.0% 0.007 0.007 0.0% reptile +0.3% +0.0% 0.006 0.006 0.0% reverse-complem 0.0% 0.0% 0.061 0.061 0.0% rewrite -0.1% -1.8% 0.010 0.010 0.0% rfib 0.0% 0.0% 0.009 0.009 0.0% rsa +0.1% +0.0% 0.014 0.014 0.0% scc +0.0% +0.2% 0.000 0.000 0.0% sched 0.0% 0.0% 0.012 0.012 0.0% scs 0.0% 0.0% -0.1% -0.1% 0.0% simple 0.0% 0.0% 0.119 0.119 0.0% solid +0.6% -14.8% 0.065 0.065 0.0% sorting -0.1% 0.0% 0.001 0.001 0.0% spectral-norm 0.0% 0.0% +0.9% +0.9% 0.0% sphere 0.0% 0.0% 0.027 0.027 0.0% symalg +0.0% -0.8% 0.005 0.005 0.0% tak 0.0% 0.0% 0.007 0.007 0.0% transform -0.1% -0.4% 0.190 0.190 0.0% treejoin +0.0% +2.3% 0.094 0.094 -3.6% typecheck +0.5% -1.9% 0.151 0.151 0.0% veritas -1.3% -0.0% 0.001 0.001 0.0% wang +0.1% -1.1% 0.055 0.055 -5.3% wave4main -0.0% -0.0% 0.156 0.156 0.0% wheel-sieve1 0.0% 0.0% +10.1% +10.0% 0.0% wheel-sieve2 0.0% 0.0% 0.135 0.135 0.0% x2n1 0.0% 0.0% 0.003 0.003 0.0% -------------------------------------------------------------------------------- Min -1.3% -95.0% -95.0% -95.0% -33.3% Max +1.0% +5.9% +10.1% +10.0% +9.5% Geometric Mean +0.1% -5.3% -10.2% -10.2% -0.3% }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 16:59:01 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 16:59:01 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks In-Reply-To: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> References: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> Message-ID: <061.358ff77b392ac31d34dec26a789ef594@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157 | Differential Rev(s): Phab:D3973, Wiki Page: | Phab:D3999 -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D3973 => Phab:D3973, Phab:D3999 Comment: Suggestion in comment:11 done in Phab:D3999. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 17:03:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 17:03:44 -0000 Subject: [GHC] #14190: Typeable imposes seemingly redundant constraints on polykinded instances In-Reply-To: <045.10ac00c982131e42012d99b318054ca4@haskell.org> References: <045.10ac00c982131e42012d99b318054ca4@haskell.org> Message-ID: <060.f785ea439c7c5e1448c36d858d464bab@haskell.org> #14190: Typeable imposes seemingly redundant constraints on polykinded instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4000 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4000 Comment: See Phab:D4000 for an implementation of comment:9. It currently doesn't validate but I'll try to finish it up tonight. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 17:16:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 17:16:43 -0000 Subject: [GHC] #14190: Typeable imposes seemingly redundant constraints on polykinded instances In-Reply-To: <045.10ac00c982131e42012d99b318054ca4@haskell.org> References: <045.10ac00c982131e42012d99b318054ca4@haskell.org> Message-ID: <060.0ca891827e60d0aede4f07c4a3201ec3@haskell.org> #14190: Typeable imposes seemingly redundant constraints on polykinded instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4000 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I guess we really do want `typeRepKind`. Without it, we have no way to get the kinds of the pieces once we decompose. This doesn't seem to have been considered in the original paper, perhaps because the authors were thinking of `TypeInType` only as part of the solution, and not as part of the problem. I think we almost certainly want to expand the data constructors (probably all of them) to accommodate typereps of kinds. One thing I'm rather unclear on is just what information is stored in a `TyCon` (most particularly, what a `KindRep` is about) and whether we really need all that information in that form in the typerep of a tycon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 17:52:09 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 17:52:09 -0000 Subject: [GHC] #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers In-Reply-To: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> References: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> Message-ID: <062.9872e0eb3626d79b4b84a152f833daf0@haskell.org> #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Prelude | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #12537 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * owner: (none) => trommler Comment: I'll prepare a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 18:04:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 18:04:57 -0000 Subject: [GHC] #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable In-Reply-To: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> References: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> Message-ID: <061.34abbef86e0e45976f7a8fe41ecf00de@haskell.org> #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:7 RyanGlScott]: > I'm not sure why the original program would be any more honest, since it claims that matching on `TrFun` is inaccessible, right? That is, `Con` is to `MkT1` as `TrFun` is to `MkT2` as `Fun` is to `MkT2'` as `Dynamic` is to `S` as `dynApply` is to `u`. Or am I missing something? Ah, simply because I didn't read it correctly. Ben came to this dishonest reduction from a perfectly honest example! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 18:18:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 18:18:32 -0000 Subject: [GHC] #14256: GHCi is faster than compiled code In-Reply-To: <049.81e3e16f4addaa1f394251f9117591e6@haskell.org> References: <049.81e3e16f4addaa1f394251f9117591e6@haskell.org> Message-ID: <064.2b036b2424636032b01515bd8fb1f825@haskell.org> #14256: GHCi is faster than compiled code -------------------------------------+------------------------------------- Reporter: mpickering | 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: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 18:23:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 18:23:44 -0000 Subject: [GHC] #14254: The Binary instance for TypeRep smells a bit expensive In-Reply-To: <045.b0b485439de28cadfa61420f4ccc13a7@haskell.org> References: <045.b0b485439de28cadfa61420f4ccc13a7@haskell.org> Message-ID: <060.8de378263df68fd68c42515a6458d077@haskell.org> #14254: The Binary instance for TypeRep smells a bit expensive -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Typeable 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:D3998 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I think you need to define what your cost model is; it's not clear that anyone expects `dynApply` to be as cheap as a static application. The same goes for serialisation; it's going to be expensive even if you cache the kind. This is why packages like `distributed-process` go to some lengths to avoid serialising unnecessarily. On the other hand, packages like `vault` really don't care how expensive kind computation is, so optimizing for this case may be counterproductive from their perspective. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 18:29:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 18:29:51 -0000 Subject: [GHC] #14258: n-body runtime regressed badly due to CoreFVs patch In-Reply-To: <046.af089daa358f5c8ac207a50826db38ff@haskell.org> References: <046.af089daa358f5c8ac207a50826db38ff@haskell.org> Message-ID: <061.ea410451e80c26ea063d6dcebd6665f8@haskell.org> #14258: n-body runtime regressed badly due to CoreFVs patch -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13570 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #13570 Comment: Oh dear; I just remembered that this was already reported some months ago as #13570. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 18:31:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 18:31:24 -0000 Subject: [GHC] #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable In-Reply-To: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> References: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> Message-ID: <061.100534685ea9ab7168a28d1212bc07d6@haskell.org> #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings 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): Regardless of the example's moral integrity, I posit that it exhibits buggy behavior. First, let's try to hammer out what //should// happen here. There's something of a specification buried in the annals of the GHC wiki [https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/CompleteSigs#ErrorMessages here]. (Why is this not in the users' guide?) The relevant bit is: > When the pattern match checker requests a set of constructors for a type constructor `T`, we now return a list of sets which include the normal data constructor set and also any `COMPLETE` pragmas of type `T`. We then try each of these sets, not warning if any of them are a perfect match. In the case the match isn't perfect, we select one of the branches of the search depending on how good the result is. > > The results are prioritised in this order. > > 1. Fewest uncovered clauses > 2. Fewest redundant clauses > 3. Fewest inaccessible clauses > 4. Whether the match comes from a `COMPLETE` pragma or the built-in set of data constructors for a type constructor. In the example above, we're matching on something of type `T`, so we have the built-in constructor set `{MkT1, MkT2}` as well as the `COMPLETE` set `{MkT1}`. Since `u` only matches on `MkT2'`, the latter set `{MkT1}` (the `COMPLETE` set) has the fewest number of uncovered clauses, so we use that for reporting warnings. Therefore, the error that we would //expect// to get (but don't, due to this bug) is: {{{ Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: MkT1 }}} Does that sound agreeable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 18:34:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 18:34:05 -0000 Subject: [GHC] #14254: The Binary instance for TypeRep smells a bit expensive In-Reply-To: <045.b0b485439de28cadfa61420f4ccc13a7@haskell.org> References: <045.b0b485439de28cadfa61420f4ccc13a7@haskell.org> Message-ID: <060.a4a005714e9a882f9cf41d6f5fe1a138@haskell.org> #14254: The Binary instance for TypeRep smells a bit expensive -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Typeable 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:D3998 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Well no, but they probably also don't expect more than a constant overhead. My bet is that users split mostly into two groups: those who really just want a type-indexed fingerprint and those who want cheap `typeRepKind`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 19:26:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 19:26:16 -0000 Subject: [GHC] #14259: Worker/Wrapper for sum return Message-ID: <044.5a0430da39545698959781c6e8d2c6e5@haskell.org> #14259: Worker/Wrapper for sum return -------------------------------------+------------------------------------- Reporter: jheek | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC version 8.2 introduces Unboxed Sum types. It would be great if the worker/wrapper transformation could make use of this new functionality. For clarification I would expect a function like this: {{{#!haskell maybeEven :: Int -> Maybe Int maybeEven n = case even n of True -> Just n False -> Nothing }}} to be transformed into (the core equivalent) of {{{#!haskell maybeEven :: Int -> Maybe Int MaybeEven (I# n#) = case workerMaybeEven n# of (# | x #) -> Just x (# (# #) | #) -> Nothing workerMaybeEven :: Int# -> (# (# #) | Int #) {-# NOINLINE workerMaybeEven #-} workerMaybeEven n# = case even (I# n#) of True -> (# | I# n# #) False -> (# (# #) | #) }}} Currently the core output for the maybeEven worker is: {{{#!haskell Main.$wmaybeEven :: Int# -> Maybe Int Main.$wmaybeEven = \ (ww_s4WH :: Int#) -> case remInt# ww_s4WH 2# of { __DEFAULT -> GHC.Base.Nothing @ Int; 0# -> GHC.Base.Just @ Int (GHC.Types.I# ww_s4WH) } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 19:42:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 19:42:18 -0000 Subject: [GHC] #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) In-Reply-To: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> References: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> Message-ID: <064.91d71ecf0afea82e74785cc4611f872d@haskell.org> #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) -------------------------------------+------------------------------------- Reporter: carlostome | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14006 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed I can reproduce this verbatim. Interestingly enough, the sample in question is at the very end up the `hp` file and has no cost centers in it, {{{ ... BEGIN_SAMPLE 0.455729 MAIN 160 (198)GHC.IO.Handle.FD.CAF 680 (218)GHC.Conc.Signal.CAF 640 (225)main 152 (223)Main.CAF 16 (206)GHC.IO.Encoding.Iconv.CAF 120 (208)GHC.IO.Encoding.CAF 1096 (114)PINNED 36816 END_SAMPLE 0.455729 BEGIN_SAMPLE 0.455359 END_SAMPLE 0.455359 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 19:42:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 19:42:57 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.d7c3185d97b1425296d7d81cca4d4348@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 bgamari): Wow, a geometric mean of -10% is quite impressive if it is real. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 19:57:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 19:57:22 -0000 Subject: [GHC] #14259: Worker/Wrapper for sum return In-Reply-To: <044.5a0430da39545698959781c6e8d2c6e5@haskell.org> References: <044.5a0430da39545698959781c6e8d2c6e5@haskell.org> Message-ID: <059.a5cce3f3e0a06c11c53e924ab436bd12@haskell.org> #14259: Worker/Wrapper for sum return -------------------------------------+------------------------------------- Reporter: jheek | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: osa1 (added) Comment: Note that osa1 had some work in the direction. See Phab:D2436. I should also mention Phab:D2424, which is also a bit of unboxed sums work that is in limbo. osa1, perhaps you would care to say a few words about the status of these? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 19:59:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 19:59:17 -0000 Subject: [GHC] #14259: Worker/Wrapper for sum return In-Reply-To: <044.5a0430da39545698959781c6e8d2c6e5@haskell.org> References: <044.5a0430da39545698959781c6e8d2c6e5@haskell.org> Message-ID: <059.4eb399b1dca9358c9e57355027033730@haskell.org> #14259: Worker/Wrapper for sum return -------------------------------------+------------------------------------- Reporter: jheek | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12364 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => UnboxedSums * related: => #12364 Comment: Also relevant is #12364. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 20:43:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 20:43:34 -0000 Subject: [GHC] #14260: Type family in instance signature confuses GHC Message-ID: <051.303818ece4faf09adefcc4998ed04c6f@haskell.org> #14260: Type family in instance signature confuses GHC -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This works: {{{#!hs class F a where type T a u :: T a -> a -> a newtype W a = W a instance F (W a) where type T (W a) = T a u = undefined instance F () where type T () = T (W ()) u _ = undefined }}} Remove one argument to `u` and you get {{{#!hs • Reduction stack overflow; size = 201 When simplifying the following type: T (W ()) Use -freduction-depth=0 to disable this check (any upper bound you could choose might fail unpredictably with minor updates to GHC, so disabling the check is recommended if you're sure that type checking should terminate) • In the expression: undefined In an equation for ‘u’: u = undefined In the instance declaration for ‘F ()’ }}} It is also not accepted to {{{#!hs u :: T (W ()) -> () -> () u _ = id @() }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 21:11:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 21:11:54 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.284a3aaea922e962be42010e5151a9ab@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 nomeata): It seems that this mean is greatly skewed by `CSD` with -98%. There is one other with -10, the rest of the improvements are less extreme, and there are some regressions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 21:22:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 21:22:26 -0000 Subject: [GHC] #14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: Message-ID: <045.3936f21bdd3848870db3bf9280c23e0a@haskell.org> #14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Build failure on current ghc-HEAD as: Build failure for armv7a-hardfloat-linux-gnueabi: {{{ Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64 -unknown-windows","arm-unknown-linux-gnueabihf","armv6-unknown-linux- gnueabihf","armv7-unknown-linux-gnueabihf","aarch64-unknown-linux- gnu","aarch64-unknown-linux","i386-unknown-linux-gnu","i386-unknown- linux","x86_64-unknown-linux-gnu","x86_64-unknown-linux","armv7-unknown- linux-androideabi","aarch64-unknown-linux-android","arm-unknown-nto-qnx- eabi","i386-apple-darwin","x86_64-apple-darwin","armv7-apple-ios","aarch64 -apple-ios","i386-apple-ios","x86_64-apple-ios"] }}} Build failure for armv7a-unknown-linux-gnueabi {{{ Failed to lookup the datalayout for armv7a-unknown-linux-gnueabi; available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64 -unknown-windows","arm-unknown-linux-gnueabihf","armv6-unknown-linux- gnueabihf","armv7-unknown-linux-gnueabihf","aarch64-unknown-linux- gnu","aarch64-unknown-linux","i386-unknown-linux-gnu","i386-unknown- linux","x86_64-unknown-linux-gnu","x86_64-unknown-linux","armv7-unknown- linux-androideabi","aarch64-unknown-linux-android","arm-unknown-nto-qnx- eabi","i386-apple-darwin","x86_64-apple-darwin","armv7-apple-ios","aarch64 -apple-ios","i386-apple-ios","x86_64-apple-ios"] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 21:42:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 21:42:40 -0000 Subject: [GHC] #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) In-Reply-To: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> References: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> Message-ID: <064.f5c8f701d4e919d98342a61c245118d9@haskell.org> #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) -------------------------------------+------------------------------------- Reporter: carlostome | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14006 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): So the bad sample is being written by `endHeapProfiling` which gets its timestamp from `mut_user_time`. This is in contrast to the samples produced during the bulk of the program's execution, which come from `dumpCensus`, which takes its timestamp from `mut_user_time_until(t)`, where `t` comes from `getProcessTimes` (by way of `gct->gc_start_cpu`). I've added a bit of instrumentation, {{{#!patch --- a/rts/ProfHeap.c +++ b/rts/ProfHeap.c @@ -363,6 +363,12 @@ void endProfiling( void ) static void printSample(bool beginSample, StgDouble sampleValue) { + static StgDouble lastValue = 0; + CHECK(sampleValue >= lastValue); + printf("sampleValue=%f\n", sampleValue); + lastValue = sampleValue; + (void) lastValue; + fprintf(hp_file, "%s %f\n", (beginSample ? "BEGIN_SAMPLE" : "END_SAMPLE"), sampleValue); diff --git a/rts/Stats.c b/rts/Stats.c index 6a5f80130e..773c55e431 100644 --- a/rts/Stats.c +++ b/rts/Stats.c @@ -77,6 +77,7 @@ Time stat_getElapsedTime(void) double mut_user_time_until( Time t ) { + printf("mut_user_time_until %f %f \n", TimeToSecondsDbl(t), TimeToSecondsDbl(stats.gc_cpu_ns)); return TimeToSecondsDbl(t - stats.gc_cpu_ns); // heapCensus() time is included in GC_tot_cpu, so we don't need // to subtract it here. @@ -331,6 +332,7 @@ stat_endGC (Capability *cap, gc_thread *gct, stats.cumulative_par_balanced_copied_bytes += stats.gc.par_balanced_copied_bytes; } + printf("end gc %f\n", TimeToSecondsDbl(NSToTime(stats.gc.cpu_ns))); stats.gc_cpu_ns += stats.gc.cpu_ns; stats.gc_elapsed_ns += stats.gc.elapsed_ns; }}} Which produces the following, {{{ ... end gc 0.000205 end gc 0.000195 mut_user_time_until 0.930493 0.603123 sampleValue=0.327370 sampleValue=0.327370 end gc 0.000200 True end gc 0.014411 mut_user_time_until 0.945025 0.617734 hi: internal error: ASSERTION FAILED: file rts/ProfHeap.c, line 367 (GHC version 8.3.20170919 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} I believe what is happening here is that we are producing the second-to- last sample before `stat_endGC` has been run. This means that `stats.gc_cpu_ns` is stale as it does not include the time spent during this present GC. Then, some time later we go to emit the final sample. However, now `stats.gc_cpu_ns` includes the time spent in the final GC, meaning that it may appear that we have "gone backwards" in time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 22:19:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 22:19:46 -0000 Subject: [GHC] #14206: Add bit deposit and bit extraction primops In-Reply-To: <047.2543734720307265ea1bddd575e5fddb@haskell.org> References: <047.2543734720307265ea1bddd575e5fddb@haskell.org> Message-ID: <062.3b94badfb41b123683d249f642a0c4f3@haskell.org> #14206: Add bit deposit and bit extraction primops -------------------------------------+------------------------------------- Reporter: newhoggy | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by newhoggy): I thought to use `-mbmi2` because there are already a bunch of `-m` flags. Would that be fine? {{{#!haskell ------ Machine dependent (-m) stuff --------------------------- , make_ord_flag defGhcFlag "msse" (noArg (\d -> d { sseVersion = Just SSE1 })) , make_ord_flag defGhcFlag "msse2" (noArg (\d -> d { sseVersion = Just SSE2 })) , make_ord_flag defGhcFlag "msse3" (noArg (\d -> d { sseVersion = Just SSE3 })) , make_ord_flag defGhcFlag "msse4" (noArg (\d -> d { sseVersion = Just SSE4 })) , make_ord_flag defGhcFlag "msse4.2" (noArg (\d -> d { sseVersion = Just SSE42 })) , make_ord_flag defGhcFlag "mavx" (noArg (\d -> d { avx = True })) , make_ord_flag defGhcFlag "mavx2" (noArg (\d -> d { avx2 = True })) , make_ord_flag defGhcFlag "mavx512cd" (noArg (\d -> d { avx512cd = True })) , make_ord_flag defGhcFlag "mavx512er" (noArg (\d -> d { avx512er = True })) , make_ord_flag defGhcFlag "mavx512f" (noArg (\d -> d { avx512f = True })) , make_ord_flag defGhcFlag "mavx512pf" (noArg (\d -> d { avx512pf = True })) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 22:24:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 22:24:45 -0000 Subject: [GHC] #14153: Change worker thread name to something mentioning original process name In-Reply-To: <045.51d1772d93ea20bf954892cfb97d76de@haskell.org> References: <045.51d1772d93ea20bf954892cfb97d76de@haskell.org> Message-ID: <060.771f5dcb888f4b7b3f28079b3077eefe@haskell.org> #14153: Change worker thread name to something mentioning original process name -------------------------------------+------------------------------------- Reporter: enolan | Owner: enolan Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D4001 Wiki Page: | -------------------------------------+------------------------------------- Changes (by enolan): * status: new => patch * differential: => phab:D4001 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 23:15:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 23:15:53 -0000 Subject: [GHC] #14262: fdReady cannot wait more than 49 days Message-ID: <042.48524b8eed487d5020c916aed0a23739@haskell.org> #14262: fdReady cannot wait more than 49 days -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: #8684, #13497 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ import System.IO hWaitForInput stdin 4294968296 }}} This code waits for 1 second instead of 49.something days. The culprit: {{{ hWaitForInput :: Handle -> Int -> IO Bool fdReady(..., int msecs, ...) }}} Haskell `Int` is usally 64 bits. C `int` is usually 32 bits. Called here: {{{ ready :: FD -> Bool -> Int -> IO Bool ready fd write msecs = do r <- throwErrnoIfMinus1Retry "GHC.IO.FD.ready" $ fdReady (fdFD fd) (fromIntegral $ fromEnum $ write) (fromIntegral msecs) foreign import ccall safe "fdReady" fdReady :: CInt -> CInt -> CInt -> CInt -> IO CInt }}} We `fromIntegral` `Int` to `CInt` (== `Int32`), overflowing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 20 23:16:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Sep 2017 23:16:49 -0000 Subject: [GHC] #14262: fdReady cannot wait more than 49 days In-Reply-To: <042.48524b8eed487d5020c916aed0a23739@haskell.org> References: <042.48524b8eed487d5020c916aed0a23739@haskell.org> Message-ID: <057.dd659e276cf807373b7e898c1a657e10@haskell.org> #14262: fdReady cannot wait more than 49 days -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8684, #13497 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): `fromIntegral` is somewhere between partial functions and `unsafeCoerce` on the evilness scale. IMO think it's time to split `fromIntegral` into `safeFromIntegral` (that can only cast into larger domains) and `overflowingFromIntegral`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 00:00:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 00:00:30 -0000 Subject: [GHC] #14262: fdReady cannot wait more than 49 days In-Reply-To: <042.48524b8eed487d5020c916aed0a23739@haskell.org> References: <042.48524b8eed487d5020c916aed0a23739@haskell.org> Message-ID: <057.744e6e56397c3c39beac0f060a81a3bd@haskell.org> #14262: fdReady cannot wait more than 49 days -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8684, #13497 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 00:31:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 00:31:17 -0000 Subject: [GHC] #14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: In-Reply-To: <045.3936f21bdd3848870db3bf9280c23e0a@haskell.org> References: <045.3936f21bdd3848870db3bf9280c23e0a@haskell.org> Message-ID: <060.c25eabb88cd637e4d47ca6d487c5c6e2@haskell.org> #14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): I believe the error message could be better :-( Targets are not hardcoded into GHC anymore, they are read from the `llvm- targets` file, at the top level. (It is also copied during install/...), which is read by ghc at runtime, and thus changes to it are directly reflected without recompilation. The `llvm-targets` file can be generated via the `utils/llvm-targets/gen- data-layout.sh` script. That being said, I am a bit confused about the `armv7a-hardfloat-linux- gnueabi` target. Shouldn't that be `armv7-unknown-linux-gnueabihf`? Should we use Autoconf triple canonicalization here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 00:45:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 00:45:34 -0000 Subject: [GHC] #14260: Type family in instance signature confuses GHC In-Reply-To: <051.303818ece4faf09adefcc4998ed04c6f@haskell.org> References: <051.303818ece4faf09adefcc4998ed04c6f@haskell.org> Message-ID: <066.33071d7c2355614b0f29fbef66ecef17@haskell.org> #14260: Type family in instance signature confuses GHC -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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 RyanGlScott): You //almost// pulled the wool over my eyes and made me think that GHC was infinitely looping without provocation. But then I realized that you conveniently left off some important language extensions needed to compile this code :) {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} }}} The fact that you have to enable `UndecidableInstances` should be an important clue as to what's happening. You have these two type family instances: {{{#!hs type T () = T (W ()) type T (W a) = T a }}} So if you have `u :: T (W ()) -> () -> (); u = undefined`, GHC attempts to generalize the type `T (W ()) -> () -> ()`, and thus reduce `T (W ())`. But that means: {{{ T (W ()) -> T () -> T (W ()) -> ... }}} Bam. Stack overflow. So I claim there is no bug here, only reckless use of `UndecidableInstances` and type families. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 00:50:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 00:50:29 -0000 Subject: [GHC] #14243: GHC doesn't add constraint when deriving In-Reply-To: <051.c8a69e4b23eafe74b02bc02a195cf182@haskell.org> References: <051.c8a69e4b23eafe74b02bc02a195cf182@haskell.org> Message-ID: <066.dc210b1df591689555d95f6fbdba0267@haskell.org> #14243: GHC doesn't add constraint when deriving -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11008 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 03:48:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 03:48:19 -0000 Subject: [GHC] #14263: typeKind is quadratic Message-ID: <047.347eff46dcda74aa975a5781e6cb08f5@haskell.org> #14263: typeKind is quadratic -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While pondering Phab:D3998, I realized that any computation of a type's kind should be careful in the presence of nested `AppTy`s. And, to my horror, I realized that GHC's very own `typeKind` isn't! That is, if you have the type `a b c d e`, GHC will take a quadratic (or worse -- haven't benchmarked) amount of time computing its kind. This can be easily fixed by looking for nested `AppTy`s and using `piResultTys`, instead of repeated uses of `piResultTy` (as is currently done). NB: This was not discovered through witnessing poor performance, but it does seem like very low-hanging compiler-performance fruit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 03:54:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 03:54:58 -0000 Subject: [GHC] #14263: typeKind is quadratic In-Reply-To: <047.347eff46dcda74aa975a5781e6cb08f5@haskell.org> References: <047.347eff46dcda74aa975a5781e6cb08f5@haskell.org> Message-ID: <062.42d342db50bd521942d3e5acd901c06c@haskell.org> #14263: typeKind is quadratic -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | 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 goldfire): I have often wondered if it wouldn't be better to change `Type`s concrete representation to avoid this kind of problem structurally. To wit: {{{#!hs data Type = TyVarTy TyVar | TyConTy TyCon | AppTys Type [Type] -- INVARIANT 1: List is not empty. -- INVARIANT 2: The head type is not an AppTys | ForAllTy ... | LitTy ... | CastTy ... | CoercionTy ... }}} Note that INVARIANT 1 is needed to avoid confusion between, e.g., `AppTys (TyVarTy a) []` and `TyVarTy a`. We could perhaps do even better using `Seq Type` instead of `[Type]` as the container in `AppTys`, given that we sometimes need access to both ends. It might be an interesting experiment to see if performance improves with this change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 03:57:21 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 03:57:21 -0000 Subject: [GHC] #14254: The Binary instance for TypeRep smells a bit expensive In-Reply-To: <045.b0b485439de28cadfa61420f4ccc13a7@haskell.org> References: <045.b0b485439de28cadfa61420f4ccc13a7@haskell.org> Message-ID: <060.127384e9722ea2928be5bc94049adc32@haskell.org> #14254: The Binary instance for TypeRep smells a bit expensive -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Typeable 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:D3998 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): We could, perhaps, consider a representation like I describe in comment:1:ticket:14263 for `TypeRep` to avoid these performance problems. Doing so would, at the least, be a nice stress test for `TypeInType`. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 04:05:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 04:05:17 -0000 Subject: [GHC] #13959: substTyVar's definition is highly dubious In-Reply-To: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> References: <050.3f592ff946bef3395ff35399eb27f420@haskell.org> Message-ID: <065.f4acb0c0c66cd536e8679aedf7732be5@haskell.org> #13959: substTyVar's definition is highly dubious -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire 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 goldfire): * owner: (none) => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 05:49:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 05:49:22 -0000 Subject: [GHC] #14259: Worker/Wrapper for sum return In-Reply-To: <044.5a0430da39545698959781c6e8d2c6e5@haskell.org> References: <044.5a0430da39545698959781c6e8d2c6e5@haskell.org> Message-ID: <059.6e77ef97369b7efe70b80576b5be41de@haskell.org> #14259: Worker/Wrapper for sum return -------------------------------------+------------------------------------- Reporter: jheek | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12364 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > osa1, perhaps you would care to say a few words about the status of these? Sure. CPR and worker/wrapper are easy to implement and I even have patches for these. (all of which should be up on phabricator) Demand analysis on the other hand is not that easy to extend (conceptually) and implement. We had some work on this too but we couldn't finish it (after several weeks of work) and these days I unfortunately don't have time & energy to work on this ;-( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 07:47:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 07:47:45 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.6c5758c8fab6378cd7e7b5ad89aeb6de@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 simonpj): Good data, thank you. Next step: * Characterise where the big wins come from * Characterise where the regressions come from I usually start with allocations and use `-ticky` to localise it. I think SAT is quite hard to ALWAYS win. But I speculate that SAT on a join point IS always a win. Joachim is the expert there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 07:56:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 07:56:22 -0000 Subject: [GHC] #6084: Add stg_ap_pnnv and related call patterns In-Reply-To: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> References: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> Message-ID: <064.dcc73021f452a3f6205cb4621b8c25ab@haskell.org> #6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------- Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8313 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Ok, so is it something that should be addressed in the LLVM code generator, or do we need to also retain more information in Cmm? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 08:41:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 08:41:15 -0000 Subject: [GHC] #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) In-Reply-To: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> References: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> Message-ID: <065.d3b9caa93982fbdc591b53d735f4ac56@haskell.org> #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: carlostome Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: | 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): Phab:D3981 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK I can see what is happening here. The trouble is with the COMPLETE pragma (again!). Suppose we'd written {{{ f :: Foo a -> a f (Foo1 x) = x f (MyFoo2 y) = y }}} This definition is rejected as ill-typed: {{{ T14135.hs:13:4: error: * Couldn't match type `a' with `Int' `a' is a rigid type variable bound by the type signature for: f :: forall a. Foo a -> a at T14135.hs:11:1-15 Expected type: Foo a Actual type: Foo Int }}} Reason: the pattern synonym `MyFoo2` demands that its scrutinee has type `Foo Int`. This is unlike a GADT, whose data constructors can have a return type `Foo Int` but which can match a scrutinee of type `Foo a`. It's a conscious design choice, described in the user manual (I hope). See `Note [Pattern synonym result type]` in `PatSyn`. Now, the overlap checker, when looking for missing patterns, effectively adds that extra equation. But the extra equation is ill-typed which crashes the overlap checker. (So yes, I think the `tcMatchTy` is fine; it's relying on the scrutinee having the right type.) So what are we to make of `{-# COMPLETE Foo1, MyFoo2 #-}`? The simplest thing to do is to insist that all the constructors in a COMPLETE pragma match the same type of scrutinee, where * A constructor `K` declared thus {{{ data T a b where K :: .... }}} matches a scrutinee of type `T a b` (NB: NOT the return type in K's signature which for a GADT might be `T Int Bool`) * A constructor `K` declared in a `data instance` {{{ data instance T ty1 ty2 where K :: .... }}} matches a scrutinee of type `T ty1 ty2`. (NB: again, not the return type in K's signature which may an instance of `K ty1 ty2`) * A constructor `K` declared in a pattern synonym {{{ pattern K :: .... -> T ty1 ty2 }}} matches a scrutinee of type `T ty1 ty2`. If we did this check when dealing with the COMPLETE pragma, I think that's solve this crash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 08:46:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 08:46:08 -0000 Subject: [GHC] #14239: Let -fspecialise-aggressively respect NOINLINE (or NOSPECIALISABLE?) In-Reply-To: <054.3fc353cace424f353779f664cd491f56@haskell.org> References: <054.3fc353cace424f353779f664cd491f56@haskell.org> Message-ID: <069.e6565af851229802136ff200f8b801d0@haskell.org> #14239: Let -fspecialise-aggressively respect NOINLINE (or NOSPECIALISABLE?) -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: feature request | Status: new 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 simonpj): There is something odd here. In comment:2 I proposed: * NOSPECIALISABLE: please do not specialise this function (even if it would otherwise be easy to do so) * NOINLINE: please do not inline or specialise this function (even if it would otherwise be easy to do so). That is, hide its implementation from the caller. But it seems odd to allow a function to be inlined, but not to allow it to be specialised, doesn't it? After all, inlining is really just a drastic form of specialisation: once per call site! You can think of specialisation as a way to economise on all these inlinings by sharing them among similar call sites. So I wonder whether we should reverse the semantics thus: * NOINLINE: please do not inline this function (even if it would otherwise be easy to do so). But GHC is free to specialise it. * NOSPECIALISABLE: please do not inline or specialise this function (even if it would otherwise be easy to do so). You could also argue for inlining and specialisation to be orthogonal, but that'd lead to strange cases where you (accidentally perhaps) say to inline but never specialise or some other odd combination. I'm inclined to stick with four mutually-exclusive settings for now. Anyone else care to comment? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 09:03:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 09:03:12 -0000 Subject: [GHC] #14190: Typeable imposes seemingly redundant constraints on polykinded instances In-Reply-To: <045.10ac00c982131e42012d99b318054ca4@haskell.org> References: <045.10ac00c982131e42012d99b318054ca4@haskell.org> Message-ID: <060.a61feba54c1de1b501ac779486498d26@haskell.org> #14190: Typeable imposes seemingly redundant constraints on polykinded instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4000 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Without it, we have no way to get the kinds of the pieces once we decompose I think it would be useful to give a concrete example of this, and put that example in a Note with the code for `typeRepKind`. So far I have always supposed that it's a convenience mechanism: you can always pass a `TypeRep` for the kind separately. But maybe I'm wrong. I'm not against `typeRepKind`, just wanting a slam-dunk argument that we need it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 09:18:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 09:18:50 -0000 Subject: [GHC] #14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: In-Reply-To: <045.3936f21bdd3848870db3bf9280c23e0a@haskell.org> References: <045.3936f21bdd3848870db3bf9280c23e0a@haskell.org> Message-ID: <060.1c54d2b19f27cb73a82e8e016bdfdd68@haskell.org> #14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): > That being said, I am a bit confused about the armv7a-hardfloat-linux- gnueabi target. Shouldn't that be armv7-unknown-linux-gnueabihf This triplet is recognized by autoconf, gcc, glibc and binutils just fine and generated by GHC binaries worked. > Should we use Autoconf triple canonicalization here? I don't think canonicalization will give you much here. You can't match triples for exat match anyways. A few fields can be used to inject custom strings, like ${vendor}. I use ${vendor} a lot to distinct between locally installed toolchains (default-pie, default-nopie, etc.) {{{ ghc $ ./config.sub armv7a-hardfloat-linux-gnueabi armv7a-hardfloat-linux-gnueabi ghc $ ./config.sub armv7a-unknown-linux-gnueabi armv7a-unknown-linux-gnueabi ghc $ ./config.sub x86_64-UNREG-linux-gnu x86_64-UNREG-linux-gnu }}} I guess it depends what gen-data-layout.sh script tries to fish out of the triple. It looks like what it really needs is: - CPU architecture (that's the first field of triple) - FPU ABI Normally how autoconf scripts do it is they match for known templates: {{{ case ${target} in armv[78]-*) something;; *-ghueabihf) something-else;; armv[678]-hardfloat-*) another-thing;; ... }}} It's a bit fragile though. More precise way would be to interrogate available toolchain. Either through dumping of defined macros for a target compiler and check for features you need to construct proper llvm string or compile-test things in autoconf way. If all above it tedious I'm fine to have a manual mechanism of passing required info manually at ./configure time (or whenever appropriate). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 09:21:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 09:21:51 -0000 Subject: [GHC] #14263: typeKind is quadratic In-Reply-To: <047.347eff46dcda74aa975a5781e6cb08f5@haskell.org> References: <047.347eff46dcda74aa975a5781e6cb08f5@haskell.org> Message-ID: <062.d8c35df0b0d4993ca816efbd8d847856@haskell.org> #14263: typeKind is quadratic -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | 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 simonpj): I agree with comment:1. Worth a try. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 09:32:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 09:32:16 -0000 Subject: [GHC] #14264: unregisterised GHC fails buid as: ghc-stage1: panic! (the 'impossible' happened): pprCLbl AsmTempLabel Message-ID: <045.736322f9e774df505f8958e70b609542@haskell.org> #14264: unregisterised GHC fails buid as: ghc-stage1: panic! (the 'impossible' happened): pprCLbl AsmTempLabel -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- How to repdoruce on amd64: {{{ $ ./configure --enable-unregisterised $ make }}} Build failure: {{{ rts_dist_HC rts/dist/build/PrimOps.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170920 for x86_64-unknown-linux): ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170920 for x86_64-unknown-linux): ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170920 for x86_64-unknown-linux): pprCLbl AsmTempLabel }}} Normally UNREG backend has no asm labels. changeset:8b007abbeb3045900a11529d907a835080129176 looks vaguely relevant as it adds AsmTempLabel in one place. But I did not look in detail yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 09:47:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 09:47:43 -0000 Subject: [GHC] #14264: unregisterised GHC fails buid as: ghc-stage1: panic! (the 'impossible' happened): pprCLbl AsmTempLabel In-Reply-To: <045.736322f9e774df505f8958e70b609542@haskell.org> References: <045.736322f9e774df505f8958e70b609542@haskell.org> Message-ID: <060.566362312d725df9cae59df6888b60a0@haskell.org> #14264: unregisterised GHC fails buid as: ghc-stage1: panic! (the 'impossible' happened): pprCLbl AsmTempLabel -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): This tiny change (reverts only change from changeset:8b007abbeb3045900a11529d907a835080129176) seems to restore the build: {{{#!diff --- a/compiler/cmm/BlockId.hs +++ b/compiler/cmm/BlockId.hs @@ -42,3 +42,3 @@ newBlockId = mkBlockId <$> getUniqueM blockLbl :: BlockId -> CLabel -blockLbl label = mkAsmTempLabel (getUnique label) +blockLbl label = mkEntryLabel (mkFCallName (getUnique label) "block") NoCafRefs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 09:59:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 09:59:41 -0000 Subject: [GHC] #11671: Allow labels starting with uppercase with OverloadedLabels In-Reply-To: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> References: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> Message-ID: <059.6d0047f2e80577aca27d3e4173789a63@haskell.org> #11671: Allow labels starting with uppercase with OverloadedLabels -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 (Parser) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 10:07:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 10:07:22 -0000 Subject: [GHC] #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable In-Reply-To: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> References: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> Message-ID: <061.2058ac55d4647578ebbb4f6c5ea9f816@haskell.org> #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings 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): > Does that sound agreeable? OK with me. * Do add those rules to the documentation of COMPLETE in the user guide * See also #14135 comment:6, which is in the same territory -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 10:33:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 10:33:51 -0000 Subject: [GHC] #14211: Compiler is unable to INLINE as well as the programmer can manually In-Reply-To: <047.2a53ecf1e57ab8268d4f765d1da08a61@haskell.org> References: <047.2a53ecf1e57ab8268d4f765d1da08a61@haskell.org> Message-ID: <062.d9e33af7620d6eb0cad7cfd0728a66df@haskell.org> #14211: Compiler is unable to INLINE as well as the programmer can manually -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | StaticArgumentTransformation, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm a bit lost in all this. Is there a small reproducible test case I can look at? What exactly is being compared with what? I'm also lost with the SAT discussion. I think SAT is off by default; and it usually applies to recursive definitions, which in turn usually do not have ININE pragmas. Sorry to be dim. Maybe start from zero and explain one bit at a time? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 10:36:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 10:36:33 -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.c232e17bf5864a40723329c35520a1b9@haskell.org> #14231: Core lint error "in result of Static argument" -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => StaticArgumentTransformation Comment: That indeed looks like a (not very serious) bug. But Matthew, I think you are studying SAT anyway. Maybe this one will come out in the wash as you do so? If so it may not be worth fixing the current pass? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 10:51:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 10:51:06 -0000 Subject: [GHC] #14239: Let -fspecialise-aggressively respect NOINLINE (or NOSPECIALISABLE?) In-Reply-To: <054.3fc353cace424f353779f664cd491f56@haskell.org> References: <054.3fc353cace424f353779f664cd491f56@haskell.org> Message-ID: <069.4c8020a6c76158760ccff963d6af017f@haskell.org> #14239: Let -fspecialise-aggressively respect NOINLINE (or NOSPECIALISABLE?) -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: feature request | Status: new 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 MikolajKonarski): I think there are many way to interpret the negative flags. I can easily think about two: by trigger (passes) and by mechanism (micro-decisions). Let me explain by sketching the semantics of NOSPECIALISABLE pragma. For simplicity I assume GHC works by making separate passes over code, e.g., inlining pass and specialising pass. I think this is a good mental model for a programmer, as opposed to a tangled mess of iterated optimization micro-decisions, even if the latter is much closer to reality. NOSPECIALISABLE by trigger: when GHC is looking for functions to specialise, ignore the function. The inlining pass may independently decide to inline it. NOSPECIALISABLE by mechanism: in the specialisation pass, if the function meets the criteria for specialisation *and* specialisation-by-inlining, inline it, otherwise ignore it, never create a specialised copy. The inlining pass is free to make its own decisions, in particular, criteria for inlining may be different than for specialisation-by-inlining. For my use case, for simplicity of the mental model, I'd prefer by-trigger semantics, because I want the NOSPECIALISABLE to just mark an exception to the `-fspecialise-aggressively` option and I understand such global default-changing options to affect passes --- decisions whether a functions should be transformed at all, not micro-decisions how to best transform it (e.g., whether to specialize it by copy or by inlining). If one wants to risk forcing particular micro-decisions, there are other GHC flags to use, e.g., the thresholds for inlining and other fine-tuning, but the results are hard to predict and context-sensitive, so I'd keep them separate. Examples of the by-trigger semantics, SPECIALISABLE+NOINLINE is free to perform specialisation-by-inlining, because NOINLINE just says to ignore the function during the inlining pass (but not during the specialising pass). INLINE+NOSPECIALISABLE is not equivalent to INLINE, I guess, because a recursive function can't be inlined, but might be specialized by copy. The by-trigger semantics probably doesn't match the reality of GHC code and the current semantics of NOINLINE. For the trigger semantics there would need to be separate code that checks whether a function should be considered for inlining and a separate code that checks if a function we are specializing should instead be inlined. The NOINLINE pragma would only be inspected in the former. This also implies NOINLINE should not inhibit exposing of unfoldings. The by-trigger semantics in full: * NOINLINE: please do not consider this function when deciding which functions to inline (even if it fits the criteria). But GHC is free to specialise it, even inlining it in the process. * NOSPECIALISABLE: please do not specialise this function (even if it would otherwise be easy to do so). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 11:01:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 11:01:32 -0000 Subject: [GHC] #14263: typeKind is quadratic In-Reply-To: <047.347eff46dcda74aa975a5781e6cb08f5@haskell.org> References: <047.347eff46dcda74aa975a5781e6cb08f5@haskell.org> Message-ID: <062.503d0188e928aa2cd0e6613c11cd91c4@haskell.org> #14263: typeKind is quadratic -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 11:03:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 11:03:14 -0000 Subject: [GHC] #14254: The Binary instance for TypeRep smells a bit expensive In-Reply-To: <045.b0b485439de28cadfa61420f4ccc13a7@haskell.org> References: <045.b0b485439de28cadfa61420f4ccc13a7@haskell.org> Message-ID: <060.4713ea04992cfec54ab712f5621c8cd3@haskell.org> #14254: The Binary instance for TypeRep smells a bit expensive -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Typeable 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:D3998 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 11:07:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 11:07:07 -0000 Subject: [GHC] #14260: Type family in instance signature confuses GHC In-Reply-To: <051.303818ece4faf09adefcc4998ed04c6f@haskell.org> References: <051.303818ece4faf09adefcc4998ed04c6f@haskell.org> Message-ID: <066.95ef8042cffb9dfa4fed46d67dbee85f@haskell.org> #14260: Type family in instance signature confuses GHC -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 11:18:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 11:18:49 -0000 Subject: [GHC] #14211: Compiler is unable to INLINE as well as the programmer can manually In-Reply-To: <047.2a53ecf1e57ab8268d4f765d1da08a61@haskell.org> References: <047.2a53ecf1e57ab8268d4f765d1da08a61@haskell.org> Message-ID: <062.126d8a2d2c01200074c69d1eca26c8d0@haskell.org> #14211: Compiler is unable to INLINE as well as the programmer can manually -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | StaticArgumentTransformation, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The reproducible example is in this github repo https://github.com /harendra-kumar/ghc-perf/tree/inlining-issue in the `inlining-issue` branch. You can compile it with `cabal new-build all` and then run the benchmark. The interesting point is the definition of `bindWith` which is a self- recursive function with 2 static arguments. Harendra observes that by "manually inlining" it, ie replacing the arguments with the statically known values produces much faster code than GHC produces on its own. I then observe that 1. Removing the `INLINE` pragma and turning on `-fstatic-argument- transformation` has the same effect. 2. The `INLINE` (or `INLINABLE`) pragma inhibits `-fstatic-argument- transformation` by creating a mutually recursive group (see https://mail.haskell.org/pipermail/ghc-devs/2017-September/014672.html). 3. However, there is no way to make sure the optimised satted unfolding for `bindWith` is exposed so it can be inlined across modules (hence the comment about `-fexpose-all-unfoldings`). Harendra then has two questions about how this information should be communicated to users. 1. Whether the `INLINE` section should mention about SAT. 2. Whether we have a warning option which warns the programmer about missed inlining. This is only communicated by running `-dcore-lint` currently. Does that clear things up? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 11:42:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 11:42:31 -0000 Subject: [GHC] #14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: In-Reply-To: <045.3936f21bdd3848870db3bf9280c23e0a@haskell.org> References: <045.3936f21bdd3848870db3bf9280c23e0a@haskell.org> Message-ID: <060.331b5590ddd2f283fc3c4d5fa7cd1f1b@haskell.org> #14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * cc: bgamari, kavon (added) Comment: Just for the record. The `*-hardfloat-*` vendor seems to be gentoo specific: https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/toolchain.eclass#n1069. The `gen-data-layout.sh` script actually interrogates `clang`, to obtain the `data-layout`, cpu, and additional flags. Frankly the additional flags are still a bit fragile. I'm ok with adding: `armv7a-unknown-linux-gnueabi` to the list of llvm-targets. The case of `armv7a-hardfloat-linux-gnueabi`, which is not recognized as a proper llvm target, and llvm would only recognize as `armv7a-unknown-linux-gnueabihf`, I'm a bit reluctant to add, as it would result in a seemingly accepted target, while llvm would generate code for soft float, which seem unintentional. The customizable vendor flag though, I believe we should allow. I'm not perfectly sure if we should just strip it out in autoconf, and replace any vendor that's not part of the llvm-targets, with `unknown` as a fallback. E.g. `x86_64-UNREG-linux-gnu` would end up as `LLVM_TARGET=x86_64-unknown- linux-gnu`. I'm also more comfortable to make the `*-hardfloat-*-gnueabi` gentoo hack into a special casing in the configure script to have it end up as `LLVM_TARGET=...-unknown-...-gnueabihf`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 11:49:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 11:49:46 -0000 Subject: [GHC] #14265: kinded holes Message-ID: <048.88de9bb3140b448f46cfc61f85a9bdb3@haskell.org> #14265: kinded holes -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For value-level holes, ghc kindly mentions the expected type. It does not do the same for holes in type signatures: mentioning the expected kind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 12:26:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 12:26:04 -0000 Subject: [GHC] #13707: xmobar crashes with segmentation faults? In-Reply-To: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> References: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> Message-ID: <061.16fd55633967055855c9ddeebaad9347@haskell.org> #13707: xmobar crashes with segmentation faults? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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 Emantor): Hello, I just produced an unstripped version of xmobar, here is the coredump from coredumpctl. Unfortunately it is bigger than the allowed upload limit, you can download it [https://magratgarlick.emantor.de/xmobar_dump.xz here]. I also built a version with the configure option `--with-debug-info=1`, weirdly I could not reproduce the crashes with that binary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 12:33:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 12:33:01 -0000 Subject: [GHC] #14262: fdReady cannot wait more than 49 days In-Reply-To: <042.48524b8eed487d5020c916aed0a23739@haskell.org> References: <042.48524b8eed487d5020c916aed0a23739@haskell.org> Message-ID: <057.ecd1653758456decc25e4431a2bdb612@haskell.org> #14262: fdReady cannot wait more than 49 days -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8684, #13497 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mboes): * cc: mboes (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 12:48:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 12:48:50 -0000 Subject: [GHC] #14265: kinded holes In-Reply-To: <048.88de9bb3140b448f46cfc61f85a9bdb3@haskell.org> References: <048.88de9bb3140b448f46cfc61f85a9bdb3@haskell.org> Message-ID: <063.c68d16b591bfccc89bc82b67a8eb1072@haskell.org> #14265: kinded holes -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | 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 RyanGlScott): * keywords: => PartialTypeSignatures * component: Compiler => Compiler (Type checker) Comment: You didn't give a concrete example of what you'd like to see, so I'm forced to guess. My shot-in-the-dark attempt is this program: {{{#!hs {-# LANGUAGE PolyKinds #-} f :: proxy _ -> () f _ = () }}} {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:3:12: error: • Found type wildcard ‘_’ standing for ‘w’ Where: ‘w’ is a rigid type variable bound by the inferred type of f :: proxy w -> () at Bug.hs:4:1-8 ‘k’ is a rigid type variable bound by the inferred type of f :: proxy w -> () at Bug.hs:4:1-8 To use the inferred type, enable PartialTypeSignatures • In the type signature: f :: proxy _ -> () | 3 | f :: proxy _ -> () | ^ }}} This output is indeed pretty skeevy-looking¸ since it points out a kind variable `k` in a `Where:` clause, but `k` isn't used anywhere else! Perhaps you wanted to see something like this instead? {{{ • Found type wildcard ‘_’ standing for ‘w’ (of kind ‘k’) Where: ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 12:58:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 12:58:33 -0000 Subject: [GHC] #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) In-Reply-To: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> References: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> Message-ID: <065.dfb0b57e3a0ed42cf6560f928964df13@haskell.org> #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: carlostome Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: | 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): Phab:D3981 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This type-of-scrutinee check is interesting, but it would come at a cost. Currently, it is quite possible to use `Foo1` and `MyFoo2` together, in this function: {{{#!hs g :: Foo Int -> Int g (Foo1 x) = x g (MyFoo2 y) = y }}} But if we adopted your proposed type-of-scrutinee validity check, then we'd no longer be able to write a `COMPLETE` program that covers this use case, since `{-# COMPLETE Foo1, MyFoo2 #-}` wouldn't typecheck. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 13:21:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 13:21:17 -0000 Subject: [GHC] #14265: kinded holes In-Reply-To: <048.88de9bb3140b448f46cfc61f85a9bdb3@haskell.org> References: <048.88de9bb3140b448f46cfc61f85a9bdb3@haskell.org> Message-ID: <063.c5c08044c3e690dc48ee21b2e5e55691@haskell.org> #14265: kinded holes -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by lspitzner): That is exactly what I meant. Polykinded was not even in my mind; it would not hurt to have the same in simpler (non-polykind) cases too, like {{{#!hs foo :: StateT _ _ (); foo = undefined }}} could produce {{{ :7:15: error: • Found type wildcard ‘_’ standing for ‘w’ (of kind ‘*’) Where: ‘w’ is a rigid type variable bound by the inferred type of foo :: StateT w w1 () at :7:23-37 To use the inferred type, enable PartialTypeSignatures • In the type signature: foo :: StateT _ _ () :7:17: error: • Found type wildcard ‘_’ standing for ‘w1’ (of kind ‘* -> *’) … }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 13:56:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 13:56:35 -0000 Subject: [GHC] #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable In-Reply-To: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> References: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> Message-ID: <061.228e0819e1e7b26b7c74cb33177871bd@haskell.org> #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11984, #14098 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #11984, #14098 Comment: Phab:D4005 adds the rules to the GHC users' guide (proofreaders wanted). As for why this bug happens in the first place, I have a strong hunch that there's a symptom in common with #11984 (and #14098). The reason is because while this give a warning: {{{#!hs u :: S -> Bool u (MkS MkT2') = True }}} {{{ Pattern match has inaccessible right hand side In an equation for ‘u’: u (MkS MkT2') = ... }}} You can work around the issue using the same trick in https://ghc.haskell.org/trac/ghc/ticket/11984#comment:7 : {{{#!hs u :: S -> Bool u (MkS x) = case x of MkT2' -> True }}} After this, instead of emitting the garbage inaccessible right-hand-side warning from before, GHC will warn: {{{ Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: MkT1 }}} As we would expect. So now we need to figure out why there is a discrepancy between the pattern match checker's coverage of `case` and nested constructors. (I'm hoping I gain some insight after talking to SPJ about this part of the codebase tomorrow.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 14:08:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 14:08:22 -0000 Subject: [GHC] #13964: Pattern-match warnings for datatypes with COMPLETE sets break abstraction In-Reply-To: <050.b7cea59b1fbd8d41c8cf345641492ba3@haskell.org> References: <050.b7cea59b1fbd8d41c8cf345641492ba3@haskell.org> Message-ID: <065.c07fb264287a42968ba6fb97ee751b5e@haskell.org> #13964: Pattern-match warnings for datatypes with COMPLETE sets break abstraction -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Another way of phrasing the problem is that the observed behavior here doesn't match the specification laid out in [https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/CompleteSigs#ErrorMessages the GHC wiki] (and which I'm attempting to enshrine in the GHC users' guide in Phab:D4005). Quoth the wiki: > When the pattern match checker requests a set of constructors for a type constructor `T`, we now return a list of sets which include the normal data constructor set and also any `COMPLETE` pragmas of type `T`. We then try each of these sets, not warning if any of them are a perfect match. In the case the match isn't perfect, we select one of the branches of the search depending on how good the result is. > > The results are prioritised in this order. > > 1. Fewest uncovered clauses > 2. Fewest redundant clauses > 3. Fewest inaccessible clauses > 4. Whether the match comes from a `COMPLETE` pragma or the built-in set of data constructors for a type constructor. Going to back to the original example: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} module Bug (Boolean(F, TooGoodToBeTrue), catchAll) where data Boolean = F | T deriving Eq pattern TooGoodToBeTrue :: Boolean pattern TooGoodToBeTrue <- ((== T) -> True) where TooGoodToBeTrue = T {-# COMPLETE F, TooGoodToBeTrue #-} }}} {{{#!hs module Foo where import Bug catchAll2 :: Boolean -> Int catchAll2 F = 0 -- catchAll2 TooGoodToBeTrue = 1 }}} Here, we have two sets of conlikes to consider: the original set of data constructors `{F, T}`, as well as the `COMPLETE` set `{F, TooGoodToBeTrue}`. Both sets have exactly one uncovered clause and no redundant or inaccessible clauses, so to break the tie, it must use the fourth rule, which states that the `COMPLETE` pragma should be favored over the built-in set of data constructors. But this isn't happening here, since the original data constructor `T` is being warned about. So we could "fix" this example by just tightening the implementation to actually match the specification. Granted, one could tweak this example slightly to the point where the original data constructor set is once again favored over the `COMPLETE` set (while still following the specification), once again breaking abstraction. In such a scenario, we should consider revising the specification to factor in whether all of the conlikes in a particular set are in-scope. That should supplant "Fewest uncovered clauses" as the new top priority, I believe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 14:25:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 14:25:34 -0000 Subject: [GHC] #14190: Typeable imposes seemingly redundant constraints on polykinded instances In-Reply-To: <045.10ac00c982131e42012d99b318054ca4@haskell.org> References: <045.10ac00c982131e42012d99b318054ca4@haskell.org> Message-ID: <060.51f465f07668d4b36f7439a9e3440756@haskell.org> #14190: Typeable imposes seemingly redundant constraints on polykinded instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4000 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:12 simonpj]: > > Without it, we have no way to get the kinds of the pieces once we decompose > > I think it would be useful to give a concrete example of this, and put that example in a Note with the code for `typeRepKind`. > > So far I have always supposed that it's a convenience mechanism: you can always pass a `TypeRep` for the kind separately. But maybe I'm wrong. > > I'm not against `typeRepKind`, just wanting a slam-dunk argument that we need it. I haven't dug into enough examples of type reflection to know how often this is important. The one place I've seen so far is in de/serialization, where we need it if we want to check well-kindedness of deserialized typereps. Richard's suggestion that we dig into nested `App`s to find the constructor and build from there seems likely to be a good way to avoid needing a general `typeRepKind` there. For `dynApply`, storing the representation of the kind separately is sufficient, I think. But I don't know if some more sophisticated use of `Typeable` will really need kinds of deconstructed typereps. Ben: when we serialize a nest of applications, I think we probably don't want to emit a tag for each `App`. Use an `Apps` tag instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 14:38:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 14:38:00 -0000 Subject: [GHC] #14221: yaml-0.8.23.3 fails to build with -g In-Reply-To: <046.9dadad43b611bdb3c19cc87ee92d4f08@haskell.org> References: <046.9dadad43b611bdb3c19cc87ee92d4f08@haskell.org> Message-ID: <061.4580020f0f3287db9836da24092743a9@haskell.org> #14221: yaml-0.8.23.3 fails to build with -g -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | 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:D3977 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 14:51:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 14:51:19 -0000 Subject: [GHC] #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) In-Reply-To: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> References: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> Message-ID: <065.d892bb9d8ce3cd4bddb52537e6a4fd7f@haskell.org> #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: carlostome Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: | 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): Phab:D3981 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, well, another alternative (triggered by #14253 comment:9), filter the candidate COMPLETE sets, to choose only those all of whose constructors match the type of the scrutinee. So in the example in comment:7 we'd use the COMPLETE pragma, but in the example in the Description we would ignore it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 14:57:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 14:57:17 -0000 Subject: [GHC] #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) In-Reply-To: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> References: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> Message-ID: <065.5d4356b4e8ee4612839899dda95f6dba@haskell.org> #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: carlostome Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: | 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): Phab:D3981 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): That sounds like a great suggestion to me! This might even scratch an itch I discovered in https://ghc.haskell.org/trac/ghc/ticket/14059#comment:2. There, I lamented that fact that I wanted to write a `COMPLETE` set for a group of conlikes whose types are headed by `Sing`. The problem was that each conlike wasn't of type, say, `Sing (a :: k)`, but rather the more specific type `Sing (a :: Bool)`. But with the proposal laid out in comment:8, I don't believe this would be an issue, since we could simply filter out anything in a `COMPLETE` set that wasn't of type `Sing (a :: Bool)`. Nice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 14:58:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 14:58:42 -0000 Subject: [GHC] #14059: COMPLETE sets don't work at all with data family instances In-Reply-To: <050.1b97217d892621b52fdef83d9bc47bf0@haskell.org> References: <050.1b97217d892621b52fdef83d9bc47bf0@haskell.org> Message-ID: <065.bbf13ca3911463985674b33857ddfc49@haskell.org> #14059: COMPLETE sets don't work at all with data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): https://ghc.haskell.org/trac/ghc/ticket/14135#comment:9 offers some peace of mind for one problem I encountered in comment:2 (where I bemoaned the fact that I can only write `{-# COMPLETE SFalse, STooGoodToBeTrue :: Sing #-}` (and not `{-# COMPLETE SFalse, STooGoodToBeTrue :: Sing (z :: Bool) #-}`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 15:29:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 15:29:26 -0000 Subject: [GHC] #14128: Possible bug in Renamer when dealing with orphans In-Reply-To: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> References: <050.482d35beb665b1c9b3cb561a55ada089@haskell.org> Message-ID: <065.784b75b0698d59eb6802658e95cd3e24@haskell.org> #14128: Possible bug in Renamer when dealing with orphans -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.2.1 checker) | 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:D3892 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I briefly looked at doing the treatment in comment:14 to `dep_finsts` but it seems unnecessary as you cannot define type family instances in `hs- boot` files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 15:47:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 15:47:55 -0000 Subject: [GHC] #14251: LLVM Code Gen messes up registers In-Reply-To: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> References: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> Message-ID: <062.682ebaed261fd4e9308b72f67e9ada61@haskell.org> #14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (LLVM) | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kavon): I'll take a look at this later today. I fixed a bug almost exactly the same as this problem in my LLVM backend. This fix should not require a lot of changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 16:09:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 16:09:47 -0000 Subject: [GHC] #14236: Typeable App pattern doesn't match function types In-Reply-To: <046.ae944f6e95c597c7005a5662aad01714@haskell.org> References: <046.ae944f6e95c597c7005a5662aad01714@haskell.org> Message-ID: <061.473940667cbb5562b3ec4dd5755e9010@haskell.org> #14236: Typeable App pattern doesn't match function types -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.4.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:D3969 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"cc6be3a2f23c9b2e04f9f491099149e1e1d4d20b/ghc" cc6be3a2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cc6be3a2f23c9b2e04f9f491099149e1e1d4d20b" Typeable: Allow App to match arrow types Test Plan: T14236 Reviewers: austin, hvr, goldfire Reviewed By: goldfire Subscribers: RyanGlScott, simonpj, rwbarton, goldfire, thomie, dfeuer GHC Trac Issues: #14236 Differential Revision: https://phabricator.haskell.org/D3969 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 16:09:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 16:09:47 -0000 Subject: [GHC] #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc In-Reply-To: <049.42fb65c94c9d58534f92e7ad520e593b@haskell.org> References: <049.42fb65c94c9d58534f92e7ad520e593b@haskell.org> Message-ID: <064.ad1128205e1ea506239e5ab05e361262@haskell.org> #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | rename/should_fail/T13644 Blocked By: | Blocking: Related Tickets: #13840, #13973, | Differential Rev(s): Phab:D3988 #14087 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"72b00c34c73ff6c63ee4928006b0cc60034a7638/ghc" 72b00c34/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="72b00c34c73ff6c63ee4928006b0cc60034a7638" Identify fields by selector when type-checking (fixes #13644) Test Plan: new test for #13847, and the test for #13644 now passes Reviewers: mpickering, austin, bgamari, simonpj Reviewed By: mpickering, simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #13644, #13847 Differential Revision: https://phabricator.haskell.org/D3988 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 16:09:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 16:09:47 -0000 Subject: [GHC] #13847: record construction accepts local unqualified name instead of qualified imported name In-Reply-To: <049.a967f3782f78e925a6ef9e3030f47afd@haskell.org> References: <049.a967f3782f78e925a6ef9e3030f47afd@haskell.org> Message-ID: <064.854853201a762c22fcca95a3504355ac@haskell.org> #13847: record construction accepts local unqualified name instead of qualified imported name -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | rename/should_fail/T13847 Blocked By: | Blocking: Related Tickets: #13644 | Differential Rev(s): Phab:D3988 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"72b00c34c73ff6c63ee4928006b0cc60034a7638/ghc" 72b00c34/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="72b00c34c73ff6c63ee4928006b0cc60034a7638" Identify fields by selector when type-checking (fixes #13644) Test Plan: new test for #13847, and the test for #13644 now passes Reviewers: mpickering, austin, bgamari, simonpj Reviewed By: mpickering, simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #13644, #13847 Differential Revision: https://phabricator.haskell.org/D3988 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 16:09:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 16:09:47 -0000 Subject: [GHC] #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable In-Reply-To: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> References: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> Message-ID: <061.15bf8432e97b5a889acf25d727781f6b@haskell.org> #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11984, #14098 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"acd346e3fad4d138cd8f421bb84ec6a1b357e326/ghc" acd346e3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="acd346e3fad4d138cd8f421bb84ec6a1b357e326" testsuite: Add testcase for #14253 Reviewers: austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3997 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 16:09:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 16:09:48 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism In-Reply-To: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> References: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> Message-ID: <063.eeb586cbabada03bc477b8a86a7cc375@haskell.org> #13929: GHC panic with levity polymorphism -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d86b237d612bf6ca1faa61ff1130ad9144e32a52/ghc" d86b237d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d86b237d612bf6ca1faa61ff1130ad9144e32a52" testsuite: Add unboxed sum to T13929 Test Plan: Validate Reviewers: austin Subscribers: rwbarton, thomie GHC Trac Issues: #13929 Differential Revision: https://phabricator.haskell.org/D3993 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 16:12:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 16:12:41 -0000 Subject: [GHC] #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc In-Reply-To: <049.42fb65c94c9d58534f92e7ad520e593b@haskell.org> References: <049.42fb65c94c9d58534f92e7ad520e593b@haskell.org> Message-ID: <064.d91743ec9f4367244d0c063fcbc39a4e@haskell.org> #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | rename/should_fail/T13644 Blocked By: | Blocking: Related Tickets: #13840, #13973, | Differential Rev(s): Phab:D3988 #14087 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 16:12:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 16:12:47 -0000 Subject: [GHC] #14236: Typeable App pattern doesn't match function types In-Reply-To: <046.ae944f6e95c597c7005a5662aad01714@haskell.org> References: <046.ae944f6e95c597c7005a5662aad01714@haskell.org> Message-ID: <061.55557a4119c92e4e93bb00c6c12c5ad6@haskell.org> #14236: Typeable App pattern doesn't match function types -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.4.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:D3969 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 17:54:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 17:54:39 -0000 Subject: [GHC] #13847: record construction accepts local unqualified name instead of qualified imported name In-Reply-To: <049.a967f3782f78e925a6ef9e3030f47afd@haskell.org> References: <049.a967f3782f78e925a6ef9e3030f47afd@haskell.org> Message-ID: <064.2ffcf23da45b0526bb7d2932448edd76@haskell.org> #13847: record construction accepts local unqualified name instead of qualified imported name -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | rename/should_fail/T13847 Blocked By: | Blocking: Related Tickets: #13644 | Differential Rev(s): Phab:D3988 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 19:38:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 19:38:33 -0000 Subject: [GHC] #14266: AllowAmbiguousTypes doesn't play well with default class methods Message-ID: <051.38c1a194c842b23e120b2589c2db8665@haskell.org> #14266: AllowAmbiguousTypes doesn't play well with default class methods -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This example does compile, {{{ {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ExplicitForAll #-} class A t where f :: forall x m. Monoid x => t m -> m f = undefined instance A [] where f = undefined }}} and it seems that the following really ought to be equivalent to it, since all I have done is remove a method definition which is identical to the default: {{{ {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ExplicitForAll #-} class A t where f :: forall x m. Monoid x => t m -> m f = undefined instance A [] }}} But instead GHC 8.0.2 gives an error of "Could not deduce (Monoid x0)" on the instance declaration. (I've also posed the same question on stackoverflow: https://stackoverflow.com/q/46350839/402884.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 19:45:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 19:45:48 -0000 Subject: [GHC] #14266: AllowAmbiguousTypes doesn't play well with default class methods In-Reply-To: <051.38c1a194c842b23e120b2589c2db8665@haskell.org> References: <051.38c1a194c842b23e120b2589c2db8665@haskell.org> Message-ID: <066.16450727357d79a064929478b5f92ed5@haskell.org> #14266: AllowAmbiguousTypes doesn't play well with default class methods -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by chris-martin: Old description: > This example does compile, > > {{{ > {-# LANGUAGE AllowAmbiguousTypes #-} > {-# LANGUAGE ExplicitForAll #-} > > class A t where > f :: forall x m. Monoid x => t m -> m > f = undefined > > instance A [] where > f = undefined > }}} > > and it seems that the following really ought to be equivalent to it, > since all I have done is remove a method definition which is identical to > the default: > > {{{ > {-# LANGUAGE AllowAmbiguousTypes #-} > {-# LANGUAGE ExplicitForAll #-} > > class A t where > f :: forall x m. Monoid x => t m -> m > f = undefined > > instance A [] > }}} > > But instead GHC 8.0.2 gives an error of "Could not deduce (Monoid x0)" on > the instance declaration. > > (I've also posed the same question on stackoverflow: > https://stackoverflow.com/q/46350839/402884.) New description: This example does compile, {{{ {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ExplicitForAll #-} class A t where f :: forall x m. Monoid x => t m -> m f = undefined instance A [] where f = undefined }}} and it seems that the following really ought to be equivalent to it, since all I have done is remove a method definition which is identical to the default: {{{ {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ExplicitForAll #-} class A t where f :: forall x m. Monoid x => t m -> m f = undefined instance A [] }}} But instead GHC 8.0.2 gives an error of "Could not deduce (Monoid x0)" on the instance declaration. (I've also first posed this as a question on stackoverflow: https://stackoverflow.com/q/46350839/402884.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 21:01:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 21:01:49 -0000 Subject: [GHC] #14267: CLong is not what it seems on Windows Message-ID: <042.7d897249509b84a5be39b0ee0f6babd8@haskell.org> #14267: CLong is not what it seems on Windows -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: #14262 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [https://hackage.haskell.org/package/base-4.10.0.0/docs/Foreign-C-Types.html#t:CLong The docs of CLong] say {{{ newtype CLong = CLong Int64 Haskell type representing the C long type. }}} But on 64-bit Windows, [https://stackoverflow.com/questions/384502/what- is-the-bit-size-of-long-on-64-bit-windows#384672 long is 32 bits]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 21:03:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 21:03:05 -0000 Subject: [GHC] #14267: CLong is not what it seems on Windows In-Reply-To: <042.7d897249509b84a5be39b0ee0f6babd8@haskell.org> References: <042.7d897249509b84a5be39b0ee0f6babd8@haskell.org> Message-ID: <057.8d521660c449770dda938e6cae4646d4@haskell.org> #14267: CLong is not what it seems on Windows -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #14262 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I've marked it "documentation bug" for now but we should probably check all places where types are converted to `CLong`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 21:12:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 21:12:37 -0000 Subject: [GHC] #14267: CLong is not what it seems on Windows In-Reply-To: <042.7d897249509b84a5be39b0ee0f6babd8@haskell.org> References: <042.7d897249509b84a5be39b0ee0f6babd8@haskell.org> Message-ID: <057.ede9ba3079199034f33f281aa2f5002a@haskell.org> #14267: CLong is not what it seems on Windows -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #14262 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): I wonder if it's just how haddock expands INTEGRAL_TYPE on amd64-linux: {{{#!hs -- | Haskell type representing the C @long@ type. INTEGRAL_TYPE(CLong,HTYPE_LONG) }}} I suspect on i386-linux haddock would say Int32. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 21:13:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 21:13:22 -0000 Subject: [GHC] #14267: CLong is not what it seems on Windows In-Reply-To: <042.7d897249509b84a5be39b0ee0f6babd8@haskell.org> References: <042.7d897249509b84a5be39b0ee0f6babd8@haskell.org> Message-ID: <057.532e5fedb50a6452468cd5f10095e0e6@haskell.org> #14267: CLong is not what it seems on Windows -------------------------------------+------------------------------------- Reporter: nh2 | 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: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #14262 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: Phyx- (added) * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 22:02:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 22:02:58 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks In-Reply-To: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> References: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> Message-ID: <061.ce3c5943a0d79d361dc7a196efc719fb@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157 | Differential Rev(s): Phab:D3973, Wiki Page: | Phab:D3999 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9aa73892e10e90a1799b9277da593e816a827364/ghc" 9aa73892/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9aa73892e10e90a1799b9277da593e816a827364" cmm/CBE: Use foldLocalRegsDefd Simonpj suggested this as a follow-on to #14226 to avoid code duplication. This also gives us the ability to CBE cases involving foreign calls for free. Test Plan: Validate Reviewers: austin, simonmar, simonpj Reviewed By: simonpj Subscribers: michalt, simonpj, rwbarton, thomie GHC Trac Issues: #14226 Differential Revision: https://phabricator.haskell.org/D3999 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 22:26:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 22:26:54 -0000 Subject: [GHC] #14267: CLong is not what it seems on Windows In-Reply-To: <042.7d897249509b84a5be39b0ee0f6babd8@haskell.org> References: <042.7d897249509b84a5be39b0ee0f6babd8@haskell.org> Message-ID: <057.b395666127f8afda6520c7b960c038e1@haskell.org> #14267: CLong is not what it seems on Windows -------------------------------------+------------------------------------- Reporter: nh2 | 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: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #14262 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): These types are generated by configure checks, so they're dependent on the machine that builds the docs. On a Windows machine it says {{{ /* Define to Haskell type for long */ #define HTYPE_LONG Int32 }}} so the types are fine, and the documentation would be correct if it was generated on Windows. This is a short coming of the haddock infrastructure and the main reason I do not like configure based packages. Also this isn't the biggest problem at all, the documentation of the Win32 package is mostly always wrong, since it's generated on Linux, so it points to base documentation for Linux. I have added disclaimers to the primitive types on Win32. Maybe one should be added here as well. Internally these types are to be avoided and instead use fixed width C99 types, which is what the majority of the Windows code is being converted to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 22:29:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 22:29:35 -0000 Subject: [GHC] #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) In-Reply-To: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> References: <042.0aadb43263d56b871c202e854c7ea816@haskell.org> Message-ID: <057.7936016ad276fbef80a5aa104972a583@haskell.org> #14191: Implement Semigroup as a superclass of Monoid Proposal (Phase 2) -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: libraries/base | 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: #10365 | Differential Rev(s): phab:D3927 Wiki Page: | prime:Libraries/Proposals/SemigroupMonoid| -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"feac0a3bc69fd376231aa3c83d031c131156ddb9/ghc" feac0a3b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="feac0a3bc69fd376231aa3c83d031c131156ddb9" Reexport Semigroup's <> operator from Prelude (#14191) This completes the 2nd phase of the Semigroup=>Monoid Proposal (SMP) initiated in 8ae263ceb3566a7c82336400b09cb8f381217405. This updates a couple submodules to address <> naming clashes. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 22:47:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 22:47:26 -0000 Subject: [GHC] #14268: Implement Explicit Foralls Proposal Message-ID: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> #14268: Implement Explicit Foralls Proposal -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Implement Richard Eisenberg's Explicit Foralls proposal. https://github.com/ghc-proposals/ghc-proposals/pull/55 For details see the proposal: https://github.com/goldfirere/ghc-proposals/blob/instance- forall/proposals/0000-instance-foralls.rst -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 22:49:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 22:49:12 -0000 Subject: [GHC] #14268: Implement Explicit Foralls Proposal In-Reply-To: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> References: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> Message-ID: <061.706d172736d1db0ab2cbc7de2035ed37@haskell.org> #14268: Implement Explicit Foralls Proposal -------------------------------------+------------------------------------- Reporter: johnleo | Owner: johnleo Type: task | Status: new Priority: normal | Milestone: 8.4.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 johnleo): * owner: (none) => johnleo * cc: goldfire (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 23:28:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 23:28:49 -0000 Subject: [GHC] #14262: fdReady cannot wait more than 49 days In-Reply-To: <042.48524b8eed487d5020c916aed0a23739@haskell.org> References: <042.48524b8eed487d5020c916aed0a23739@haskell.org> Message-ID: <057.c7a11f4ef134b5d87d2c3e89ceac2555@haskell.org> #14262: fdReady cannot wait more than 49 days -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8684, #13497, | Differential Rev(s): #14267 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * related: #8684, #13497 => #8684, #13497, #14267 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 23:33:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 23:33:36 -0000 Subject: [GHC] #14267: CLong is not what it seems on Windows In-Reply-To: <042.7d897249509b84a5be39b0ee0f6babd8@haskell.org> References: <042.7d897249509b84a5be39b0ee0f6babd8@haskell.org> Message-ID: <057.790051fbd74de0bd8a60ecf7d97b9546@haskell.org> #14267: CLong is not what it seems on Windows -------------------------------------+------------------------------------- Reporter: nh2 | 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: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #14262 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Phew, that is great to hear. > Maybe one should be added here as well. That sounds like a great idea; improved the documentation for the `Foreign.C.Types` module that makes this obvious would have saved us some worry over in `#ghc` :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 23:34:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 23:34:15 -0000 Subject: [GHC] #14268: Implement Explicit Foralls Proposal In-Reply-To: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> References: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> Message-ID: <061.9dae5437455cff7cf7d84254c1ebb15b@haskell.org> #14268: Implement Explicit Foralls Proposal -------------------------------------+------------------------------------- Reporter: johnleo | Owner: johnleo Type: task | Status: new Priority: normal | Milestone: 8.4.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: #13809 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) * related: => #13809 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 23:35:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 23:35:08 -0000 Subject: [GHC] #13809: TH-reified type familly and data family instances have a paucity of kinds In-Reply-To: <050.0c3063c06a387a87a3b53a78ba487043@haskell.org> References: <050.0c3063c06a387a87a3b53a78ba487043@haskell.org> Message-ID: <065.7aeeaf8e566b096f90fad89961389eab@haskell.org> #13809: TH-reified type familly and data family instances have a paucity of kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8953, #14268 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #8953 => #8953, #14268 Comment: See #14268 to track the implementation of the aforementioned GHC proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 23:53:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 23:53:27 -0000 Subject: [GHC] #14266: AllowAmbiguousTypes doesn't play well with default class methods In-Reply-To: <051.38c1a194c842b23e120b2589c2db8665@haskell.org> References: <051.38c1a194c842b23e120b2589c2db8665@haskell.org> Message-ID: <066.86205711f4403b6b0a11dff16f8925bf@haskell.org> #14266: AllowAmbiguousTypes doesn't play well with default class methods -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) Comment: I can at least explain why you're seeing that error. GHC doesn't typecheck default methods by inlining their bodies like you suggest. Instead, it defines an auxiliary method and defines default `f` implementations in terms of that, like so: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ExplicitForAll #-} {-# LANGUAGE TypeApplications #-} class A t where f :: forall x m. Monoid x => t m -> m instance A [] where f = df @[] df :: forall t. A t => forall x m. Monoid x => t m -> m df = undefined }}} You'll get the same sort of error from this code as well: {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:9:7: error: • Could not deduce (Monoid x0) arising from a use of ‘df’ from the context: Monoid x bound by the type signature for: f :: forall x m. Monoid x => [m] -> m at Bug.hs:9:3 The type variable ‘x0’ is ambiguous These potential instances exist: instance Monoid a => Monoid (IO a) -- Defined in ‘GHC.Base’ instance Monoid Ordering -- Defined in ‘GHC.Base’ instance Monoid a => Monoid (Maybe a) -- Defined in ‘GHC.Base’ ...plus 7 others (use -fprint-potential-instances to see them all) • In the expression: df @[] In an equation for ‘f’: f = df @[] In the instance declaration for ‘A []’ | 9 | f = df @[] | ^^^^^^ }}} As for how one would change this code to make this typecheck, I'm not sure. At first, I thought one could solve this by simply applying more arguments via `TypeApplications`, like so: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} class A t where f :: forall x m. Monoid x => t m -> m instance A [] where f :: forall x m. Monoid x => [m] -> m f = df @[] @x @m df :: forall t. A t => forall x m. Monoid x => t m -> m df = undefined }}} But this just shifts the location of the error around: {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:10:8: error: • Could not deduce (Monoid x0) from the context: Monoid x bound by the type signature for: f :: forall x m. Monoid x => [m] -> m at Bug.hs:10:8-39 The type variable ‘x0’ is ambiguous • When checking that instance signature for ‘f’ is more general than its signature in the class Instance sig: forall x m. Monoid x => [m] -> m Class sig: forall x m. Monoid x => [m] -> m In the instance declaration for ‘A []’ | 10 | f :: forall x m. Monoid x => [m] -> m | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} This is all despite the fact that you can redefine `f` as a top-level function, and it works! {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} class A t where f :: forall x m. Monoid x => t m -> m instance A [] where f = undefined f' :: forall x m. Monoid x => [m] -> m f' = df @[] @x @m df :: forall t. A t => forall x m. Monoid x => t m -> m df = undefined }}} It's all quite confusing. I find myself very unclear of when exactly `AllowAmbiguousTypes` is supposed to kick in and save me from ambiguity errors (because in the case of class methods, it's clearly not). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 23:55:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 23:55:28 -0000 Subject: [GHC] #14267: CLong is not what it seems on Windows In-Reply-To: <042.7d897249509b84a5be39b0ee0f6babd8@haskell.org> References: <042.7d897249509b84a5be39b0ee0f6babd8@haskell.org> Message-ID: <057.f633ed87ca49f3bf0fe93316f68eb20d@haskell.org> #14267: CLong is not what it seems on Windows -------------------------------------+------------------------------------- Reporter: nh2 | 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: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #14262 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:5 nh2]: > That sounds like a great idea; improved the documentation for the `Foreign.C.Types` module that makes this obvious would have saved us some worry over in `#ghc` :) It //is// documented. See http://hackage.haskell.org/package/base-4.10.0.0/docs/Foreign-C-Types.html#g:2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 21 23:59:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Sep 2017 23:59:46 -0000 Subject: [GHC] #14267: CLong is not what it seems on Windows In-Reply-To: <042.7d897249509b84a5be39b0ee0f6babd8@haskell.org> References: <042.7d897249509b84a5be39b0ee0f6babd8@haskell.org> Message-ID: <057.b7a4398a385b4b6b9fb649c6bbbdab8b@haskell.org> #14267: CLong is not what it seems on Windows -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: Operating System: Windows | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #14262 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * status: new => closed * resolution: => invalid Comment: Replying to [comment:6 RyanGlScott]: > It //is// documented. See http://hackage.haskell.org/package/base-4.10.0.0/docs/Foreign-C-Types.html#g:2 Oops, nevermind then. My mistake, I didn't spot it. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 00:13:14 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 00:13:14 -0000 Subject: [GHC] #13608: Expose the type of quasiquotes In-Reply-To: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> References: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> Message-ID: <071.cf0a7fbb666bd3395723ba40cefc536d@haskell.org> #13608: Expose the type of quasiquotes -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: QuasiQuotes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12778 | Differential Rev(s): Phab:D3610 Wiki Page: | Phab:D3821 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"175586908963a6d438cf3c28922a38191f4eaa66/ghc" 1755869/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="175586908963a6d438cf3c28922a38191f4eaa66" Implement TH addCorePlugin. This allows template-haskell code to add plugins to the compilation pipeline. Otherwise, the user would have to pass -fplugin=... to ghc. For now, plugin modules in the current package can't be used. This is because when TH runs, it is too late to let GHC know that the plugin modules needed to be compiled first. Test Plan: ./validate Reviewers: simonpj, bgamari, austin, goldfire Reviewed By: bgamari Subscribers: angerman, rwbarton, mboes, thomie GHC Trac Issues: #13608 Differential Revision: https://phabricator.haskell.org/D3821 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 00:49:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 00:49:32 -0000 Subject: [GHC] #14269: ghc: internal error: PAP object entered! Message-ID: <045.0405550bbeb6a412ef80af1bc3992f9e@haskell.org> #14269: ghc: internal error: PAP object entered! -------------------------------------+------------------------------------- Reporter: erisco | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | 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: -------------------------------------+------------------------------------- {{{ > ghc hplay.hs -o hplay.exe [1 of 1] Compiling Main ( hplay.hs, hplay.o ) ghc: internal error: PAP object entered! (GHC version 8.0.2 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} Test file: {{{ {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE QuasiQuotes #-} module Main where import qualified Language.C.Inline as C main :: IO () main = [C.block||] }}} Using inline-c-0.6.0.5 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 00:54:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 00:54:03 -0000 Subject: [GHC] #14269: ghc: internal error: PAP object entered! In-Reply-To: <045.0405550bbeb6a412ef80af1bc3992f9e@haskell.org> References: <045.0405550bbeb6a412ef80af1bc3992f9e@haskell.org> Message-ID: <060.352a195db89dc2bbe2e4cfff14beb2f5@haskell.org> #14269: ghc: internal error: PAP object entered! -------------------------------------+------------------------------------- Reporter: erisco | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: 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 RyanGlScott): How exactly are you using `inline-c-0.6.0.5` with GHC 8.0.2? `inline-c-0.6.0.5` has strict upper bounds on `template-haskell` to only allow version 2.12.0.0 or later, and GHC 8.0.2 is bundled with `template- haskell-2.11.1.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 00:59:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 00:59:23 -0000 Subject: [GHC] #14269: ghc: internal error: PAP object entered! In-Reply-To: <045.0405550bbeb6a412ef80af1bc3992f9e@haskell.org> References: <045.0405550bbeb6a412ef80af1bc3992f9e@haskell.org> Message-ID: <060.ae5b8c8d5e5193f54638b059341c32e5@haskell.org> #14269: ghc: internal error: PAP object entered! -------------------------------------+------------------------------------- Reporter: erisco | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: 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 RyanGlScott): I attempted to build `inline-c-0.6.0.5` with GHC 8.0.2 using `--allow- older`, but was thwarted: {{{ $ cabal install -w /opt/ghc/8.0.2/bin/ghc inline-c --allow-older Resolving dependencies... Configuring inline-c-0.6.0.5... Building inline-c-0.6.0.5... Failed to install inline-c-0.6.0.5 Build log ( /u/rgscott/.cabal/logs/ghc-8.0.2/inline-c-0.6.0.5-6LPf8sxaoRe7ivvVOklwzp.log ): cabal: Entering directory '/tmp/cabal-tmp-15800/inline-c-0.6.0.5' Configuring inline-c-0.6.0.5... Preprocessing library for inline-c-0.6.0.5.. Building library for inline-c-0.6.0.5.. [1 of 9] Compiling Language.C.Types.Parse ( src/Language/C/Types/Parse.hs, dist/build/Language/C/Types/Parse.o ) [2 of 9] Compiling Language.C.Types ( src/Language/C/Types.hs, dist/build/Language/C/Types.o ) [3 of 9] Compiling Language.C.Inline.HaskellIdentifier ( src/Language/C/Inline/HaskellIdentifier.hs, dist/build/Language/C/Inline/HaskellIdentifier.o ) [4 of 9] Compiling Language.C.Inline.FunPtr ( src/Language/C/Inline/FunPtr.hs, dist/build/Language/C/Inline/FunPtr.o ) [5 of 9] Compiling Language.C.Inline.Context ( src/Language/C/Inline/Context.hs, dist/build/Language/C/Inline/Context.o ) src/Language/C/Inline/Context.hs:149:32: error: Not in scope: type constructor or class ‘TH.ForeignSrcLang’ Neither ‘Language.Haskell.TH’ nor ‘Language.Haskell.TH.Syntax’ exports ‘ForeignSrcLang’. cabal: Leaving directory '/tmp/cabal-tmp-15800/inline-c-0.6.0.5' cabal: Error: some packages failed to install: inline-c-0.6.0.5-6LPf8sxaoRe7ivvVOklwzp failed during the building phase. The exception was: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 01:13:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 01:13:03 -0000 Subject: [GHC] #14269: ghc: internal error: PAP object entered! In-Reply-To: <045.0405550bbeb6a412ef80af1bc3992f9e@haskell.org> References: <045.0405550bbeb6a412ef80af1bc3992f9e@haskell.org> Message-ID: <060.7b73613c6e3300f921d61997b99fa552@haskell.org> #14269: ghc: internal error: PAP object entered! -------------------------------------+------------------------------------- Reporter: erisco | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: 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 erisco): I don't know what to tell you… just ran 'cabal install inline-c' and it installed. I didn't ask further questions. I have now updated to GHC 8.2.1 and, after making a correct program with inline-c, it compiled successfully. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 02:36:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 02:36:18 -0000 Subject: [GHC] #13038: implementation of Modus ponens and Modus tollens In-Reply-To: <044.ee87b0a017d5b08f838549b48bb4f0cf@haskell.org> References: <044.ee87b0a017d5b08f838549b48bb4f0cf@haskell.org> Message-ID: <059.97e03a572c85a7e20b2880ccbee3820a@haskell.org> #13038: implementation of Modus ponens and Modus tollens -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:7 vanto]: Let me see if I can work an example. > 1) f is a function that maps arguments of type A to results of type B.\\ > > {{{ > f :: A -> B is identical to v(P -> Q) = 1 > }}} > > 2) e is an expression of type A\\ > > {{{ > e :: A is identical to v(P) = 1 > }}} > > 3) Then the application f e has type B\\ > > {{{ > f e :: B is identical to v(Q) = 1 > }}} > > ..., we must infer the inverse of the algorithm and must use > the Modus Tollens.\\ > OK let's take the function as `length` from the Prelude. {{{ length :: Foldable t => t a -> Int }}} And take the use: `if (length xs) then ...`. That is, the context tells us to expect result `Bool`, which is not `Int`. Does this help infer the type for `xs`? > {{{ > 1) f e :: not B is identical to v(Q) = 0 > }}} > > {{{ > 2) f :: A -> B is identical to v(P -> Q) = 1 > }}} > > {{{ > 3) e :: not A is identical to v(P) = 0 > }}} Firstly if this worked, we'd get `xs :: `**not** `(Foldable t => t a)`. I'm not seeing how knowing this would help improve the type for `xs`. But more importantly this doesn't work. If `length`'s result is required to be `Bool` but declared as `Int`, we have a contradiction. We have both `v(P -> Q) = 1` from the declaration and `v(P -> Q) = 0` from the context. So GHC should not infer anything about the type for `xs`; it should report an error -- which is what it does. > The utility of Modus tollens is complementary for many checks. No, I think it has no utility. > I also propose that an inference algorithm based on Modus Tollens be > coded in GHC. > I propose we close this ticket: invalid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 08:54:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 08:54:21 -0000 Subject: [GHC] #14264: unregisterised GHC fails buid as: ghc-stage1: panic! (the 'impossible' happened): pprCLbl AsmTempLabel In-Reply-To: <045.736322f9e774df505f8958e70b609542@haskell.org> References: <045.736322f9e774df505f8958e70b609542@haskell.org> Message-ID: <060.3cb58728f77a93549b5ae839914ef662@haskell.org> #14264: unregisterised GHC fails buid as: ghc-stage1: panic! (the 'impossible' happened): pprCLbl AsmTempLabel -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): While trying to build the iOS Cross Compiler, I've run into: ``` pprCLbl (AsmTempLabel {}) = panic "pprCLbl AsmTempLabel"` ``` Looks like the minor LLVM fix D4006, is not sufficient to resolve this either. In general it seems that the `AsmTempLabel` is tied rather directly to the NCG. And quite a few functions are partial/panicking for `AsmTempLabel` outside of the NCG :( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 09:10:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 09:10:42 -0000 Subject: [GHC] #13707: xmobar crashes with segmentation faults? In-Reply-To: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> References: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> Message-ID: <061.e821b99ad77ee0eca7cd76e916d1f58d@haskell.org> #13707: xmobar crashes with segmentation faults? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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 Emantor): * status: infoneeded => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 11:12:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 11:12:15 -0000 Subject: [GHC] #14266: AllowAmbiguousTypes doesn't play well with default class methods In-Reply-To: <051.38c1a194c842b23e120b2589c2db8665@haskell.org> References: <051.38c1a194c842b23e120b2589c2db8665@haskell.org> Message-ID: <066.58c073d2531f72cf9446af3bfbeac83e@haskell.org> #14266: AllowAmbiguousTypes doesn't play well with default class methods -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Several things to say here. First, the signature for `f` is deeply suspicious {{{ class A t where f :: forall x m. Monoid x => t m -> m }}} Any call of `f` will require a `Monoid x` constraint, but does not fix `x` in any way. So all calls will be ambiguous unless you use visible type application. Second, Ryan's account of what GHC does with default methods is absolutely right. Third, yes, it is a bit awarkard that there doesn't seem to be a way to make this (very odd) program "work". Ryan tried visible type application: {{{ instance A [] where f :: forall x m. Monoid x => [m] -> m f = df @[] @x @m }}} But when you write a type signature in an instance declaration, you are free to make it more genreal than the one required. For example: {{{ instance Num Wombat where (+) :: forall a b. a -> b -> a (+) x y = x }}} We are obliged to provide a function of type `Wombat -> Wombat -> Wombat`, but we are perfectly free to provide a more polymorphic one. Equivalently you could write {{{ instance Num Wombat where (+) = (\x y -> x) :: forall a b. a -> b -> a }}} So GHC still has to check that the type you have supplied is more polymorphic than the one required and alas in ''that'' test you can't do visible type application. That's why Ryan found that "this just shifts the error around". (And it also explains why the "top-level function" version is ok. It was a surprise to me that I can see no way to allow to write an instance when the method has a a locally-polymorphic but ambiguous method types. If there was a good reason to want them, maybe we should think about it more. If it's just a curiousity, then it's just curious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 12:15:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 12:15:30 -0000 Subject: [GHC] #14262: fdReady cannot wait more than 49 days In-Reply-To: <042.48524b8eed487d5020c916aed0a23739@haskell.org> References: <042.48524b8eed487d5020c916aed0a23739@haskell.org> Message-ID: <057.f539e20d3c449833496980b3b0ac185f@haskell.org> #14262: fdReady cannot wait more than 49 days -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8684, #13497, | Differential Rev(s): #14267 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 14:46:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 14:46:13 -0000 Subject: [GHC] #14268: Implement Explicit Foralls Proposal In-Reply-To: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> References: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> Message-ID: <061.94eb541e736173681f7f3b8f9b48c908@haskell.org> #14268: Implement Explicit Foralls Proposal -------------------------------------+------------------------------------- Reporter: johnleo | Owner: johnleo Type: task | Status: new Priority: normal | Milestone: 8.4.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: #13809 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): For the record, John and I have been collaborating behind the scenes on this one. He's not stealing this from me! :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 14:56:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 14:56:05 -0000 Subject: [GHC] #13608: Expose the type of quasiquotes In-Reply-To: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> References: <056.25d1d92a9495f18e85d0ecacba264382@haskell.org> Message-ID: <071.4244a885028002a33eafe4949dfd362d@haskell.org> #13608: Expose the type of quasiquotes -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: QuasiQuotes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12778 | Differential Rev(s): Phab:D3610 Wiki Page: | Phab:D3821 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 15:04:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 15:04:10 -0000 Subject: [GHC] #13707: xmobar crashes with segmentation faults? In-Reply-To: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> References: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> Message-ID: <061.b59e102a81ec5a1c2203dfda6d91cc7f@haskell.org> #13707: xmobar crashes with segmentation faults? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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): Do you think you could include the executable as well? Unfortunately it's hard to do much with the coredump without at least the symbol table. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 15:42:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 15:42:31 -0000 Subject: [GHC] #14269: ghc: internal error: PAP object entered! In-Reply-To: <045.0405550bbeb6a412ef80af1bc3992f9e@haskell.org> References: <045.0405550bbeb6a412ef80af1bc3992f9e@haskell.org> Message-ID: <060.596beddfe18946ca85548a0c95b6a825@haskell.org> #14269: ghc: internal error: PAP object entered! -------------------------------------+------------------------------------- Reporter: erisco | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: worksforme | Keywords: 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => worksforme Comment: Replying to [comment:3 erisco]: > I don't know what to tell you… just ran 'cabal install inline-c' and it installed. I didn't ask further questions. I may have gleaned the wrong version number perhaps by looking at the Hackage documentation rather than my console. I see. In that event, you most likely installed `inline-c-0.5.6.1` (at least, that's what it defaulted to when I ran `cabal install inline-c` using GHC 8.0.2). However, I wasn't able to reproduce the panic even after doing this. I simply got: {{{ $ C:\Users\RyanGlScott\Software\ghc-8.0.2\bin\ghc hplay.hs -o hplay.exe [1 of 1] Compiling Main ( hplay.hs, hplay.o ) hplay.hs:8:17: error: * "hplay.hs" (line 8, column 17): unexpected end of input expecting white space, "typedef", "extern", "static", "auto", "register", "void", "char", "short", "int", "long", "float", "double", "signed", "unsigned", "struct", "enum", type name, "const", "restrict", "volatile" or "inline" * In the quasi-quotation: [C.block||] }}} I also experienced this same error when compiling the same program with `inline-c-0.5.6.1` and `inline-c-0.6.0.5` on GHC 8.2.1. > I have now updated to GHC 8.2.1 and, after making a correct program with inline-c, it compiled successfully. That's good. If there was an issue in GHC 8.0.2, then it sounds like it's since been resolved. I'll close this ticket as a result. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 16:30:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 16:30:42 -0000 Subject: [GHC] #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal Message-ID: <042.d21b92eb840644cd16549869583bccd0@haskell.org> #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #14236 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When doing a default build of GHC HEAD (i.e. without `mk/build.mk`), GHC panics: {{{ $ make V=0 ===--- 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 HC [stage 1] libraries/base/dist-install/build/Data/Typeable/Internal.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170922 for x86_64-unknown-linux): Template variable unbound in rewrite rule Variable: cobox_a3S9 Rule "SC:mkTrApp0" Rule bndrs: [k1_X4g7, b_X4gb, k1_a3RW, a_a3RX, k1_X426, b_X42a, b_a3RY, sc_s7Yv, sc_s7Yr, sc_s7Ys, sc_s7Yt, cobox_a3S9, cobox_a3RZ, cobox_X42x, cobox_a3S8] LHS args: [TYPE: TYPE (b_a3RY |> Nth:2 (Sym cobox_a3S8)), TYPE: TYPE (b_X42a |> Nth:2 (Sym cobox_X42x)) -> *, TYPE: (->), TYPE: (b_X4gb |> Sym (cobox_a3S9 (Coh (Sym (Coh _N (Nth:2 (Sym cobox_a3S8)))) (Nth:2 (Sym cobox_a3S8)) ; Coh _N (Nth:2 (Sym cobox_a3S8))) ; Sym cobox_a3RZ)), TrTyCon @ (TYPE (b_a3RY |> Nth:2 (Sym cobox_a3S8)) -> TYPE (b_X42a |> Nth:2 (Sym cobox_X42x)) -> *) @ (->) sc_s7Yr sc_s7Ys $tc(->) sc_s7Yt, sc_s7Yv] Actual args: [TYPE: TYPE (b_a3RY |> Nth:2 (Sym cobox_a3S8)), TYPE: TYPE (b_X42a |> Nth:2 (Sym cobox_X42x)) -> *, TYPE: (->), TYPE: (b_X4gb |> Sym (cobox_a3S9 (Coh (Sym (Coh _N (Nth:2 (Sym cobox_a3S8)))) (Nth:2 (Sym cobox_a3S8)) ; Coh _N (Nth:2 (Sym cobox_a3S8))) ; Sym cobox_a3RZ)), TrTyCon @ (TYPE (b_a3RY |> Nth:2 (Sym cobox_a3S8)) -> TYPE (b_X42a |> Nth:2 (Sym cobox_X42x)) -> *) @ (->) dt_a2Vb dt_a2Vc $tc(->) kind_vars_X37r, ... }}} You can see a more complete error in the build log at https://launchpadlibrarian.net/337888338/buildlog_ubuntu-trusty-amd64 .ghc-head_8.3.20170922+git.0.5a8b843-7~14.04_BUILDING.txt.gz This panic seems to be causally connected to cc6be3a2f23c9b2e04f9f491099149e1e1d4d20b (which addressed #14236) because reverting that commit allows me to avoid the panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 17:13:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 17:13:35 -0000 Subject: [GHC] #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal In-Reply-To: <042.d21b92eb840644cd16549869583bccd0@haskell.org> References: <042.d21b92eb840644cd16549869583bccd0@haskell.org> Message-ID: <057.fb38c6723f5289430b1b9905ca0a3021@haskell.org> #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14236 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari Comment: Hmm, alright; I'll try to look into this seeing as I broke it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 17:21:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 17:21:45 -0000 Subject: [GHC] #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers In-Reply-To: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> References: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> Message-ID: <062.25da45f75ee134b0697d967508bdf3cc@haskell.org> #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Prelude | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #12537 | Differential Rev(s): Phab:D4009 Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * status: new => patch * differential: => Phab:D4009 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 17:27:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 17:27:30 -0000 Subject: [GHC] #14266: AllowAmbiguousTypes doesn't play well with default class methods In-Reply-To: <051.38c1a194c842b23e120b2589c2db8665@haskell.org> References: <051.38c1a194c842b23e120b2589c2db8665@haskell.org> Message-ID: <066.adca634482cd92c089899e415f059dbd@haskell.org> #14266: AllowAmbiguousTypes doesn't play well with default class methods -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:3 simonpj]: > If there was a good reason to want them, maybe we should > think about it more. I'm not chris-martin, but I do have an example of actual code he was trying to write that tickled this bug. This is what he wanted to write: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} module MultiInstance where class MultiMonoid x a where multi'append :: a -> a -> a multi'empty :: a data Addition data Multiplication instance MultiMonoid Addition Int where multi'append = (+) multi'empty = 0 instance MultiMonoid Multiplication Int where multi'append = (*) multi'empty = 1 example1, example2 :: Int example1 = multi'append @Addition 2 3 -- 5 example2 = multi'append @Multiplication 2 3 -- 6 class MultiFoldable t where multi'foldMap :: forall x m a. (MultiMonoid x m) => (a -> m) -> t a -> m instance MultiFoldable [] where multi'foldMap :: forall x m a. (MultiMonoid x m) => (a -> m) -> [a] -> m multi'foldMap f = go where go :: [a] -> m go [] = multi'empty @x go (x:xs) = multi'append @x (f x) (go xs) example3, example4 :: Int example3 = multi'foldMap @[] @Addition id [1,2,3,4] -- 10 example4 = multi'foldMap @[] @Multiplication id [1,2,3,4] -- 24 }}} To explain what's going on here: `MultiMonoid` is a class where the first parameter determines what sort of `Monoid` you're working on over the second parameter, so `multi'append @Addition` uses `{(+), 0}` as the `Monoid`, and `multi'append @Multiplication` uses `{(*), 1}` as the `Monoid`. So far, nothing about this requires `AllowAmbiguousTypes`. Now we enter `MultiFoldable`. This class only has one parameter, but its method `multi'foldMap` has a given `MultiMonoid x m` constraint. Here, `x` is ambiguous, so this crucially relies on `AllowAmbiguousTypes` working. Some demonstrations of `multi'foldMap`'s use are found in `example3` and `example4`. This fails to compile: {{{ Bug.hs:32:22: error: • Could not deduce (MultiMonoid x0 m) from the context: MultiMonoid x m bound by the type signature for: multi'foldMap :: forall x m a. MultiMonoid x m => (a -> m) -> [a] -> m at Bug.hs:32:22-76 The type variable ‘x0’ is ambiguous • When checking that instance signature for ‘multi'foldMap’ is more general than its signature in the class Instance sig: forall x m a. MultiMonoid x m => (a -> m) -> [a] -> m Class sig: forall x m a. MultiMonoid x m => (a -> m) -> [a] -> m In the instance declaration for ‘MultiFoldable []’ | 32 | multi'foldMap :: forall x m a. (MultiMonoid x m) => (a -> m) -> [a] -> m | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 18:20:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 18:20:48 -0000 Subject: [GHC] #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal In-Reply-To: <042.d21b92eb840644cd16549869583bccd0@haskell.org> References: <042.d21b92eb840644cd16549869583bccd0@haskell.org> Message-ID: <057.ec851a1457b516f4498c44e2ad94ef2a@haskell.org> #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14236 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The unbound binder in question is a coercion variable of type, {{{ cobox_a3S9 :: (TYPE :: (RuntimeRep -> *)) ~# (a_a3RX :: (k1_a3RW -> *)) }}} This feels a bit like #13410, but there the the binders were of type `t~t`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 18:29:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 18:29:43 -0000 Subject: [GHC] #14266: AllowAmbiguousTypes doesn't play well with default class methods In-Reply-To: <051.38c1a194c842b23e120b2589c2db8665@haskell.org> References: <051.38c1a194c842b23e120b2589c2db8665@haskell.org> Message-ID: <066.1cec3394d7f501bb6d6cfd6e031cc11f@haskell.org> #14266: AllowAmbiguousTypes doesn't play well with default class methods -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chris-martin): Thanks Ryan - yes that's a great description of what I was trying to do. One correction: I'm pretty sure `MultiMonoid` alone ''does'' require `AllowAmbiguousTypes` even before you get to `MultiFoldable`. The "complete" result is now on Hackage https://hackage.haskell.org/package/multi- instance-0.0.0.1/docs/MultiInstance.html although I ended up scrapping the `MultiFoldable` class altogether. It was an extended thought experiment more than anything, probably beyond the bounds of reasonable Haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 18:44:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 18:44:40 -0000 Subject: [GHC] #14266: AllowAmbiguousTypes doesn't play well with default class methods In-Reply-To: <051.38c1a194c842b23e120b2589c2db8665@haskell.org> References: <051.38c1a194c842b23e120b2589c2db8665@haskell.org> Message-ID: <066.936c6a3051ab2d08b8e3cc381f49cad3@haskell.org> #14266: AllowAmbiguousTypes doesn't play well with default class methods -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:5 chris-martin]: > Thanks Ryan - yes that's a great description of what I was trying to do. One correction: I'm pretty sure `MultiMonoid` alone ''does'' require `AllowAmbiguousTypes` even before you get to `MultiFoldable`. Ah, good point. I suppose the distinction I was making in the back of my mind was that in `MultiMonoid`, the ambiguity comes from a type variable from the //class//, whereas in `MultiFoldable`, the ambiguity comes from a type variable from a //method// (`multi'foldMap`). I believe the former can coexist with `DefaultSignatures`, whereas the latter cannot (as this bug demonstrates). > It was an extended thought experiment more than anything, probably beyond the bounds of reasonable Haskell. I think you're selling your idea short! The only reason this code would have been considered unreasonable in the past is due to the lack of `TypeApplications`, but now that it's an established thing, the scope of what's considered "reasonable" code has increased drastically. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 18:57:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 18:57:00 -0000 Subject: [GHC] #14266: AllowAmbiguousTypes doesn't play well with default class methods In-Reply-To: <051.38c1a194c842b23e120b2589c2db8665@haskell.org> References: <051.38c1a194c842b23e120b2589c2db8665@haskell.org> Message-ID: <066.5c34801aa57395855870e316a9bfe134@haskell.org> #14266: AllowAmbiguousTypes doesn't play well with default class methods -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chris-martin): Replying to [comment:6 RyanGlScott]: > but now that it's an established thing, the scope of what's considered "reasonable" code has increased drastically. I suppose that's something I'm not clear on. What is the language designers' attitude toward the `TypeApplications` extension? Is it there to be an imperfect workaround for the occasional odd situation, or is Haskell now intended to be a language where programming with ambiguous types is normal and fully supported? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 19:16:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 19:16:26 -0000 Subject: [GHC] #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal In-Reply-To: <042.d21b92eb840644cd16549869583bccd0@haskell.org> References: <042.d21b92eb840644cd16549869583bccd0@haskell.org> Message-ID: <057.694cfa954bb8a367efadb84949d5de89@haskell.org> #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14236 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ahh, so it seems like the coercion variables in question only occur in types. However, `match_ty` doesn't contribute to the `RuleSubst`'s id substitution. Consequently the variables never make it into the substitution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 19:56:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 19:56:43 -0000 Subject: [GHC] #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal In-Reply-To: <042.d21b92eb840644cd16549869583bccd0@haskell.org> References: <042.d21b92eb840644cd16549869583bccd0@haskell.org> Message-ID: <057.d9a375f13f5dd6eb948681255c78a15a@haskell.org> #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14236 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I tried extending the rule matching substitution with the CvSubst from the unification. Unfortunately, it seems as though the unifier returns an empty CvSubst. Perhaps this is because of the fact that the template variable appears both in the LHS of the rule and the argument being matched. Consequently the unifier may not extend its CvSubst when unifying, since doing so would mean adding a substitution `cobox_a3S9 :-> cobox_a3S9` to the substitution. This would violate the invariant of matching that none of the template variables appear in the range of the resulting substitution (as described in, e.g., `Note [Matching in the presence of casts]`). Also, for future reference: The coercions in question come in to scope as the result of a pattern match on an `HRefl`, {{{#!hs case ds_d4wx of { HRefl cobox_a3S8 cobox_a3S9 -> ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 20:05:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 20:05:36 -0000 Subject: [GHC] #14266: AllowAmbiguousTypes doesn't play well with default class methods In-Reply-To: <051.38c1a194c842b23e120b2589c2db8665@haskell.org> References: <051.38c1a194c842b23e120b2589c2db8665@haskell.org> Message-ID: <066.7195fdb56238a247466e562bc0704905@haskell.org> #14266: AllowAmbiguousTypes doesn't play well with default class methods -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:7 chris-martin]: > I suppose that's something I'm not clear on. What is the language designers' attitude toward the `TypeApplications` extension? Is it there to be an imperfect workaround for the occasional odd situation, or is Haskell now intended to be a language where programming with ambiguous types and explicit type applications is normal and fully supported? It still //feels// a bit like I'm abusing the type system. I can only speak as a single GHC developer, but I would certainly hope that `TypeApplications` is just as "fully supported" as anything else you can do in GHC (and I suspect I'm not alone in this regard). The somewhat unfortunate reality is that this extension is fairly new in the Haskell ecosystem, and as a result, there's been less time to discover odd interactions between it and other language extensions (of which this bug is an example). With the help of intrepid programmers like yourself, I think we'll find a way to stamp out these oddities, and hopefully make `TypeApplications` feel less like "abusing" the type system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 20:18:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 20:18:42 -0000 Subject: [GHC] #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal In-Reply-To: <042.d21b92eb840644cd16549869583bccd0@haskell.org> References: <042.d21b92eb840644cd16549869583bccd0@haskell.org> Message-ID: <057.8227b95e5d4a15e6e1ec5b4eefb9e04d@haskell.org> #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14236 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ahh, I see what is going on here: When `Unify.unify_ty` needs to match a type `CastTy ty co` with something else, it doesn't even attempt to match `co` (on account of `Note [Matching in the presence of casts]`). Instead, it simply matches `ty` (adjusting the kind coercion accordingly). Consequently, template variables that occur only in `co` will never be matched. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 21:25:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 21:25:57 -0000 Subject: [GHC] #14271: ghci hangs with -fexternal-interpreter -prof Message-ID: <047.35b6ee83038ae67884e53737c2b92695@haskell.org> #14271: ghci hangs with -fexternal-interpreter -prof ----------------------------------------+------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- {{{ ghci -fexternal-interpreter -prof GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Access violation in generated code when reading 00000001001e0418 }}} * The address remains the same between reruns (and reinstalls) of ghc. * Closing the hanging process leaves the launched ghc active in the background. * The directory I launch ghci from doesn't seem to matter. * I have only tried it on my desktop so far (Win10/Skylake) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 21:57:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 21:57:43 -0000 Subject: [GHC] #14272: GHC goes out of memory while compiling simple program with optimizations Message-ID: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> #14272: GHC goes out of memory while compiling simple program with optimizations -------------------------------------+------------------------------------- Reporter: 39aldo39 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiling the following program with `ghc -O Main.hs`, GHC goes out of memory. {{{#!hs import Data.Bits (bit) main :: IO () main = putStrLn (show (f undefined)) f :: [Int] -> Int f = sum . zipWith ((+) . bit) [0..] . map undefined . scanl undefined undefined }}} I have 6 GB RAM and 8 GB swap free, so that shouldn't be the problem. It only happens with optimizations on, and it happens during a simplifier. Any simpler expressions do work. It even happens when `[0..]` is replaced by `take 1 [0..]`, but it compiles with `take 0 [0..]`. A straightforward workaround is to replace `zipWith f [0..]` by `\xs -> zipWith f [0..length xs] xs`. I ran into this problem when updating to GHC 8.2.1 from 8.0.2. But the given program doesn't compile on older versions as well. GHC 7.10.3 was the lowest version I could run before running into other problems. All GHC versions I tested come from the Debian repo. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 22 22:02:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Sep 2017 22:02:30 -0000 Subject: [GHC] #14272: GHC goes out of memory while compiling simple program with optimizations In-Reply-To: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> References: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> Message-ID: <062.516bd1d41cf70b06cdc700d1893ac467@haskell.org> #14272: GHC goes out of memory while compiling simple program with optimizations -------------------------------------+------------------------------------- Reporter: 39aldo39 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by 39aldo39): * failure: None/Unknown => Compile-time crash or panic -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 23 07:04:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Sep 2017 07:04:09 -0000 Subject: [GHC] #14272: GHC goes out of memory while compiling simple program with optimizations In-Reply-To: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> References: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> Message-ID: <062.3879bf9d3de91b6f32192caec86a5393@haskell.org> #14272: GHC goes out of memory while compiling simple program with optimizations -------------------------------------+------------------------------------- Reporter: 39aldo39 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): It seems to me that this may not be caused by allocation but maybe some code generation bug. I tried this: {{{ $ ghc-stage2 main.hs -O -fforce-recomp -ddump-ds -ddump-simpl -ddump-stg -ddump-to-file -dsuppress-all +RTS -M10000 ghc-stage2: maximum heap size (-M) is smaller than minimum alloc area size (-A) ghc-stage2: internal error: getTopHandlerThread: neither a WEAK nor a DEAD_WEAK: 0x7f9baeaa7fd8 0x7f9bae621270 -1991765780 (GHC version 8.3.20170914 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [1] 30799 abort ghc-stage2 main.hs -O -fforce-recomp -ddump-ds -ddump-simpl -ddump-stg +RTS $ ghc-stage2 main.hs -O -fforce-recomp -ddump-ds -ddump-simpl -ddump-stg -ddump-to-file -dsuppress-all +RTS -M100000 ghc-stage2: maximum heap size (-M) is smaller than minimum alloc area size (-A) reportHeapOverflow ghc-stage2: Heap exhausted; ghc-stage2: Current maximum heap size is 98304 bytes (0 MB). ghc-stage2: Use `+RTS -M' to increase it. $ ghc-stage2 main.hs -O -fforce-recomp -ddump-ds -ddump-simpl -ddump-stg -ddump-to-file -dsuppress-all +RTS -M1000000 ghc-stage2: maximum heap size (-M) is smaller than minimum alloc area size (-A) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20170914 for x86_64-unknown-linux): heap overflow Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} When I run without any RSTS parameters the error is triggered by `Storage.c:allocate` with these parameters: {{{ RtsFlags.GcFlags.maxHeapSize = 0 req_blocks = 1 LARGE_OBJECT_THRESHOLD: 3276 n: 2 }}} I don't know if `maxHeapSize = 0` is normal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 23 08:04:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Sep 2017 08:04:12 -0000 Subject: [GHC] #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal In-Reply-To: <042.d21b92eb840644cd16549869583bccd0@haskell.org> References: <042.d21b92eb840644cd16549869583bccd0@haskell.org> Message-ID: <057.9ca1178bd3545923f81a0792ac5b63ab@haskell.org> #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14236 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Unfortunately, as long as this bug persists, the nightly-ish GHC HEAD ppa packages can't be built. If the fix takes longer than a few days, can we revert cc6be3a2f23c9b2e04f9f491099149e1e1d4d20b (and reopen #14236) until there's a proper fix? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 23 10:43:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Sep 2017 10:43:31 -0000 Subject: [GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix In-Reply-To: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> References: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> Message-ID: <057.a3df5b7500cffc4277a42b1bfad04557@haskell.org> #8684: hWaitForInput cannot be interrupted by async exceptions on unix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13497, 13525 | Blocking: Related Tickets: #12912, #13525 | Differential Rev(s): Phab:D42 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Hmm, `interruptible yield` would be a workaround, but I think it wouldn't fix the key problem. It would fix only `hWaitForInput`/`ready`. But it looks like other safe foreign calls that are called in a tight loop that does not allocate cannot be `timeout`ed. It seems a proper solution would be to insert a `yield` right after /any/ foreign call returns (at least in the non-threaded RTS). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 23 10:51:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Sep 2017 10:51:27 -0000 Subject: [GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix In-Reply-To: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> References: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> Message-ID: <057.d040415fb364c4ef6686810b6b30488d@haskell.org> #8684: hWaitForInput cannot be interrupted by async exceptions on unix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13497, 13525 | Blocking: Related Tickets: #12912, #13525 | Differential Rev(s): Phab:D42 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): In other words, I believe we have a scheduling unfairness problem in the non-threaded RTS: A thread that loops tightly around a foreign call will never give other threads the chance to run. I ''suspect'' this is because of the run-queue logic mentioned in [https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Scheduler#Therunqueue the Scheduler commentary]: ---- > In more detail, threads are put **in front** (`pushOnRunQueue`) if: > [...] > * In the non-threaded runtime, when a thread waiting on IO unblocks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 23 13:23:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Sep 2017 13:23:11 -0000 Subject: [GHC] #14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: In-Reply-To: <045.3936f21bdd3848870db3bf9280c23e0a@haskell.org> References: <045.3936f21bdd3848870db3bf9280c23e0a@haskell.org> Message-ID: <060.4194168e7f9e54a585a7dc2b71b61e5a@haskell.org> #14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Moritz Angermann ): In [changeset:"c2373b7b09939027742626e4a7bbba05ea1f6850/ghc" c2373b7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c2373b7b09939027742626e4a7bbba05ea1f6850" Additional LLVM_TARGET logic. Summary: This should help resolve the compilcation that came up in Trac #14261 Test Plan: validate on various platforms Reviewers: trofi, bgamari, austin, hvr Reviewed By: trofi Subscribers: rwbarton, thomie, erikd GHC Trac Issues: #14261 Differential Revision: https://phabricator.haskell.org/D4004 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 23 13:26:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Sep 2017 13:26:46 -0000 Subject: [GHC] #14264: unregisterised GHC fails buid as: ghc-stage1: panic! (the 'impossible' happened): pprCLbl AsmTempLabel In-Reply-To: <045.736322f9e774df505f8958e70b609542@haskell.org> References: <045.736322f9e774df505f8958e70b609542@haskell.org> Message-ID: <060.7ae217e713164c6f9f5a78e286d334dc@haskell.org> #14264: unregisterised GHC fails buid as: ghc-stage1: panic! (the 'impossible' happened): pprCLbl AsmTempLabel -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Moritz Angermann ): In [changeset:"d55961262be1b6bbacea0cd6864346f8822ee99b/ghc" d5596126/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d55961262be1b6bbacea0cd6864346f8822ee99b" Fix AsmTempLabel Summary: This is another fallout from 8b007abb should fix Trac #14264. I am not sure if this is complete. It does however allow me to build an iOS LLVM cross compiler. Reviewers: bgamari, trofi, austin, simonmar Reviewed By: trofi Subscribers: rwbarton, thomie GHC Trac Issues: #14264 Differential Revision: https://phabricator.haskell.org/D4014 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 23 13:43:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Sep 2017 13:43:29 -0000 Subject: [GHC] #13945: 'ghc-pkg update' fails due to bad file descriptor error In-Reply-To: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> References: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> Message-ID: <064.a17ea4f6ee799951c5ed1d350462472a@haskell.org> #13945: 'ghc-pkg update' fails due to bad file descriptor error ---------------------------------+---------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3897 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by j.waldmann): Slightly tangential, but - This issue prevents me from installing ghc (8.2.1) on that specific machine (which I need for lab classes) as it appears both after building from source, and when installing a binary distribution. Is there a work-around? Like, configure with the correct prefix, but then fool "make install" to use some other prefix (in the local file system), then "cp -rvp" manually to the correct (NFS-mounted) location? (Well, running "make install" in a chroot could probably help.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 23 16:29:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Sep 2017 16:29:54 -0000 Subject: [GHC] #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal In-Reply-To: <042.d21b92eb840644cd16549869583bccd0@haskell.org> References: <042.d21b92eb840644cd16549869583bccd0@haskell.org> Message-ID: <057.cc14c44aad426f8f09c15277c709dd28@haskell.org> #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14236 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Uck. This is nasty. And I'm sure it's actually my fault, not Ben's. I think we should revert the offending commit while sorting this out, as I'm not convinced that this will have an easy fix. Ben, could you paste here what the offending rule is? I know that GHC already does some faffing about with rules to make sure their LHSs are convenient to match with (see, e.g., `DsBinds.decomposeRuleLhs` and `Desugar.unfold_coerce`); maybe we can extend that algorithm to handle this case. The long-term solution is, I believe comment:9:ticket:14119. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 23 16:47:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Sep 2017 16:47:33 -0000 Subject: [GHC] #14266: AllowAmbiguousTypes doesn't play well with default class methods In-Reply-To: <051.38c1a194c842b23e120b2589c2db8665@haskell.org> References: <051.38c1a194c842b23e120b2589c2db8665@haskell.org> Message-ID: <066.38d08a01c246d14aa386b4902737778a@haskell.org> #14266: AllowAmbiguousTypes doesn't play well with default class methods -------------------------------------+------------------------------------- Reporter: chris-martin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): As the author of `TypeApplications`, I have greatly enjoyed its quick adoption in a variety of places. It's a stable extension based on published theory. I, personally, do not consider it a "workaround" at all and think it's a fine extension to build on. It ''is'' a little sketchy around the corners, however. Ryan has been working on making it work better with GADTs, and we still need support for types in patterns. That said, any place where `TypeApplications` works today will continue to work tomorrow, and I think you can use it without fear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 23 17:08:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Sep 2017 17:08:29 -0000 Subject: [GHC] #14264: unregisterised GHC fails buid as: ghc-stage1: panic! (the 'impossible' happened): pprCLbl AsmTempLabel In-Reply-To: <045.736322f9e774df505f8958e70b609542@haskell.org> References: <045.736322f9e774df505f8958e70b609542@haskell.org> Message-ID: <060.e7529c10a541b54f8cd33a9a1159e9bf@haskell.org> #14264: unregisterised GHC fails buid as: ghc-stage1: panic! (the 'impossible' happened): pprCLbl AsmTempLabel -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): Unfortunately it was not enough for UNREG build. Still fails but now generated code is invalid: {{{ /tmp/ghc31859_0/ghc_4.hc:352:5: error: error: 'c2l_entry' used but never defined [-Werror] IF_(c2l_entry); ^ | }}} Generated code: {{{ FN_(stg_catch_entry) { W_ _c2g; _c2h: _c2g = R1.w; R1.w = *((P_)(_c2g+8)); Sp[-1] = *((P_)(_c2g+16)); Sp=Sp-1; JMP_((W_)&stg_catchzh); } const StgWord stg_catch_info[]__attribute__((aligned(8)))= { (W_)&stg_catch_entry, 0x2UL, 0x8UL }; IF_(c2l_entry); FN_(stg_catchzh) { _c2p: Sp[-1] = R1.w; Sp=Sp-2; JMP_((W_)&c2l_entry); } }}} It should have been '''stg_catch_entry''' instead of '''c2l_entry'''. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 24 07:31:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Sep 2017 07:31:22 -0000 Subject: [GHC] #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal In-Reply-To: <042.d21b92eb840644cd16549869583bccd0@haskell.org> References: <042.d21b92eb840644cd16549869583bccd0@haskell.org> Message-ID: <057.1b48d9342bac996fdc3d01f465882bce@haskell.org> #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14236 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"9c7d0657e2d6c626c6aa7aac061820e8828b857e/ghc" 9c7d065/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9c7d0657e2d6c626c6aa7aac061820e8828b857e" Revert "Typeable: Allow App to match arrow types" This reverts commit cc6be3a2f23c9b2e04f9f491099149e1e1d4d20b. because it caused the regression #14270 which according to Richard probably doesn't have an easy fix. So this one goes back to the drawning board. This reopens #14236 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 24 07:31:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Sep 2017 07:31:22 -0000 Subject: [GHC] #14236: Typeable App pattern doesn't match function types In-Reply-To: <046.ae944f6e95c597c7005a5662aad01714@haskell.org> References: <046.ae944f6e95c597c7005a5662aad01714@haskell.org> Message-ID: <061.d9da517b25c4e63b0a4fffd4afbef71e@haskell.org> #14236: Typeable App pattern doesn't match function types -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.4.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:D3969 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"9c7d0657e2d6c626c6aa7aac061820e8828b857e/ghc" 9c7d065/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9c7d0657e2d6c626c6aa7aac061820e8828b857e" Revert "Typeable: Allow App to match arrow types" This reverts commit cc6be3a2f23c9b2e04f9f491099149e1e1d4d20b. because it caused the regression #14270 which according to Richard probably doesn't have an easy fix. So this one goes back to the drawning board. This reopens #14236 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 24 07:32:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Sep 2017 07:32:37 -0000 Subject: [GHC] #14236: Typeable App pattern doesn't match function types In-Reply-To: <046.ae944f6e95c597c7005a5662aad01714@haskell.org> References: <046.ae944f6e95c597c7005a5662aad01714@haskell.org> Message-ID: <061.d29098a8416c0eb73ba48b1130152566@haskell.org> #14236: Typeable App pattern doesn't match function types -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.4.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: #14270 | Differential Rev(s): Phab:D3969 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: closed => new * resolution: fixed => * related: => #14270 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 24 10:16:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Sep 2017 10:16:30 -0000 Subject: [GHC] #14271: ghci hangs with -fexternal-interpreter -prof In-Reply-To: <047.35b6ee83038ae67884e53737c2b92695@haskell.org> References: <047.35b6ee83038ae67884e53737c2b92695@haskell.org> Message-ID: <062.8f81832f537cc08664ccd9d7977105dd@haskell.org> #14271: ghci hangs with -fexternal-interpreter -prof -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * type: bug => feature request Comment: Turns out it's just not supported on Windows. Since I couldn't find another ticket turning this into a feature request. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 24 12:29:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Sep 2017 12:29:15 -0000 Subject: [GHC] #14264: unregisterised GHC fails buid as: ghc-stage1: panic! (the 'impossible' happened): pprCLbl AsmTempLabel In-Reply-To: <045.736322f9e774df505f8958e70b609542@haskell.org> References: <045.736322f9e774df505f8958e70b609542@haskell.org> Message-ID: <060.a0695e72429ba59f34c0bb822dcd6fef@haskell.org> #14264: unregisterised GHC fails buid as: ghc-stage1: panic! (the 'impossible' happened): pprCLbl AsmTempLabel -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"b3ae47caf2f23cfd2c22c29dbfca646493ffe469/ghc" b3ae47c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b3ae47caf2f23cfd2c22c29dbfca646493ffe469" don't allow AsmTempLabel in UNREG mode (Trac #14264) AsmTempLabel is really a label that describes label in assembly output (or equivalent like LLVM IR). Unregisterised build does not handle it correctly. This change does not fix UNREG build failure in Ticket #14264 but reverts back to panic: pprCLbl AsmTempLabel Signed-off-by: Sergei Trofimovich }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 24 13:04:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Sep 2017 13:04:23 -0000 Subject: [GHC] #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal In-Reply-To: <042.d21b92eb840644cd16549869583bccd0@haskell.org> References: <042.d21b92eb840644cd16549869583bccd0@haskell.org> Message-ID: <057.c8a9b8a298fc966cf452ede2b8fc1729@haskell.org> #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14236 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The rule in question is, {{{ RULES: "SC:mkTrApp0" forall (sc_s7Wy :: TypeRep (b_a44F |> cobox_a3RZ ; Sym cobox_a3S9 (Sym (Coh _N (Nth:2 (Sym cobox_a3S8))) ; Sym (Coh (Sym (Coh _N (Nth:2 (Sym cobox_a3S8)))) (Nth:2 (Sym cobox_a3S8)))))) (sc_s7Wv :: Word#) (sc_s7Ww :: Word#). mkTrApp_XkG @ (TYPE (b_a3RY |> Nth:2 (Sym cobox_a3S8))) @ (TYPE (b_X42a |> Nth:2 (Sym cobox_X42x)) -> *) @ (->) @ (b_a44F |> Sym (cobox_a3S9 (Coh (Sym (Coh _N (Nth:2 (Sym cobox_a3S8)))) (Nth:2 (Sym cobox_a3S8)) ; Coh _N (Nth:2 (Sym cobox_a3S8))) ; Sym cobox_a3RZ)) (Data.Typeable.Internal.TrTyCon @ (TYPE (b_a3RY |> Nth:2 (Sym cobox_a3S8)) -> TYPE (b_X42a |> Nth:2 (Sym cobox_X42x)) -> *) @ (->) sc_s7Wv sc_s7Ww GHC.Types.$tc(->) kind_vars_X37r) sc_s7Wy = $smkTrApp_s7Wz sc_s7Wy sc_s7Wv sc_s7Ww] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 24 15:00:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Sep 2017 15:00:09 -0000 Subject: [GHC] #14098: Incorrect pattern match warning on nested GADTs In-Reply-To: <047.9af3deedeaeda4254147ac374e749c5f@haskell.org> References: <047.9af3deedeaeda4254147ac374e749c5f@haskell.org> Message-ID: <062.b69c7deaa9068bde91d28c66789fc0c0@haskell.org> #14098: Incorrect pattern match warning on nested GADTs -------------------------------------+------------------------------------- Reporter: jmgrosen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: #11984 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I took a look at this recently. To debug this, I took the original program and gave everything some more easily recognizable names: {{{#!hs {-# Language GADTs #-} {-# OPTIONS_GHC -Wall #-} module Bug where data App f_App a_App where MkApp :: f_MkApp a_MkApp -> App f_MkApp (Maybe a_MkApp) data Ty a_Ty where TBool :: Ty Bool TInt :: Ty Int data T f_T a_T where C :: T Ty (Maybe Bool) -- Warning foo :: T f_foo a_foo -> App f_foo a_foo -> () foo C (MkApp TBool) = () -- No warning goo :: T f_goo a_goo -> App f_goo a_goo -> () goo C (MkApp x) = case x of TBool -> () }}} I then traced the results of the `ConVar` case in the patter-match checker to see exactly what sets of constraints were being checked for satisfiability. To my horror, the sets were different in `foo` and `goo`! In particular, when checking if `TInt` is reachable in `foo`, this set of constraints is checked: {{{ ty_state pm_d1Pq_d1Pq :: (a_MkApp_a1NK[sk:2] :: *) ~# (Int :: *) pm_d1Ph_d1Ph :: (a_foo_a1NG[sk:2] :: *) ~# (Maybe a_MkApp_d1Pi[sk:2] :: *) pm_d1Pc_d1Pc :: (f_foo_a1NF[sk:2] :: (* -> *)) ~# (Ty :: (* -> *)) pm_d1Pd_d1Pd :: (a_foo_a1NG[sk:2] :: *) ~# (Maybe Bool :: *) sat_ty True }}} Here, `ty_state` is the set of constraints, and `sat_ty` is whether they are satisfiable. The fact that `sat_ty` is `True` means that the patter- match checker concluded that `TInt` is indeed reachable. Contrast this with checking if `TInt` is reachable in `goo`: {{{ ty_state pm_d1Py_d1Py :: (a_MkApp_a1NW[sk:2] :: *) ~# (Int :: *) cobox_a1NU :: (f_goo_a1NR[sk:2] :: (* -> *)) ~# (Ty :: (* -> *)) cobox_a1NV :: (a_goo_a1NS[sk:2] :: *) ~# (Maybe Bool :: *) cobox_a1NX :: (a_goo_a1NS[sk:2] :: *) ~# (Maybe a_MkApp_a1NW[sk:2] :: *) sat_ty False }}} This time, `sat_ty` is `False`, so `TInt` is deemed as unreachable. However, these two sets of constraints look awfully similar! But compare these two constraints from `foo`'s `ty_state`: {{{ (a_MkApp_a1NK[sk:2] :: *) ~# (Int :: *) (a_foo_a1NG[sk:2] :: *) ~# (Maybe a_MkApp_d1Pi[sk:2] :: *) }}} With the analogous two constraints from `goo`'s `ty_state`: {{{ (a_MkApp_a1NW[sk:2] :: *) ~# (Int :: *) (a_goo_a1NS[sk:2] :: *) ~# (Maybe a_MkApp_a1NW[sk:2] :: *) }}} In `goo`'s `ty_state`, the type variable `a_MkApp_a1NW` is used in both equalities. But in `foo`'s `ty_state`, we have two separate type variables, `a_MkApp_a1NK` and `a_MkApp_d1Pi`! This difference alone is enough to account for the oracle's different answers. The reason this is happening is because `a_MkApp` is being freshened excessively in the [http://git.haskell.org/ghc.git/blob/d55961262be1b6bbacea0cd6864346f8822ee99b:/compiler/deSugar/Check.hs#l1122 mkOneConFull] function. In particular, [http://git.haskell.org/ghc.git/blob/d55961262be1b6bbacea0cd6864346f8822ee99b:/compiler/deSugar/Check.hs#l1148 this line]: {{{#!hs (subst, ex_tvs') <- cloneTyVarBndrs subst1 ex_tvs <$> getUniqueSupplyM }}} That is, `a_MkApp` is an existentially quantified type variable (retrieved from the `MkApp` `DataCon`), so it will be cloned to some other name (in this case, `a_MkApp_d1Pi`). But a later call to `mkOneConFull` assumes that `a_MkApp` was mapped to `a_MkApp_a1NK`, causing the inconsistent `ty_state` (and thus this bug). In order to resolve this, we need to determine an intelligent way to map existentially quantified type variables (retrieved from `DataCon`s) to their counterparts in a `PmCon`. But I have no idea how one would accomplish that... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 24 15:00:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Sep 2017 15:00:38 -0000 Subject: [GHC] #11984: Pattern match incompleteness / inaccessibility discrepancy In-Reply-To: <047.1cf132bd89a1199ee00c683072ed7b2c@haskell.org> References: <047.1cf132bd89a1199ee00c683072ed7b2c@haskell.org> Message-ID: <062.1d8a8499b563bcf61cd67d009b1ab22a@haskell.org> #11984: Pattern match incompleteness / inaccessibility discrepancy -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14098 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): See https://ghc.haskell.org/trac/ghc/ticket/14098#comment:3 for a diagnosis of the issue occurring here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 24 15:17:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Sep 2017 15:17:06 -0000 Subject: [GHC] #11984: Pattern match incompleteness / inaccessibility discrepancy In-Reply-To: <047.1cf132bd89a1199ee00c683072ed7b2c@haskell.org> References: <047.1cf132bd89a1199ee00c683072ed7b2c@haskell.org> Message-ID: <062.c052bce5b7c3de498a16ccb6ade36d28@haskell.org> #11984: Pattern match incompleteness / inaccessibility discrepancy -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14098 | 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 Sun Sep 24 15:17:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Sep 2017 15:17:19 -0000 Subject: [GHC] #14098: Incorrect pattern match warning on nested GADTs In-Reply-To: <047.9af3deedeaeda4254147ac374e749c5f@haskell.org> References: <047.9af3deedeaeda4254147ac374e749c5f@haskell.org> Message-ID: <062.d6334b01d294a062adf36db6f1ab1e48@haskell.org> #14098: Incorrect pattern match warning on nested GADTs -------------------------------------+------------------------------------- Reporter: jmgrosen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: #11984 | 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 Sun Sep 24 17:00:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Sep 2017 17:00:49 -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.d7567284b9c315be07996ff2e491bd70@haskell.org> #13617: GHCi linker does not honor alignment of sections. --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.4.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: | --------------------------------+---------------------------------------- Changes (by Phyx-): * status: new => patch * testcase: => T13617 * differential: => Phab:D3915 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 24 18:09:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Sep 2017 18:09:38 -0000 Subject: [GHC] #12110: Windows exception handler change causes segfault with API Monitor In-Reply-To: <045.d4b936e5e562932ebd0d335c0535752d@haskell.org> References: <045.d4b936e5e562932ebd0d335c0535752d@haskell.org> Message-ID: <060.30065897086db760b2c063b5d3688617@haskell.org> #12110: Windows exception handler change causes segfault with API Monitor -------------------------------------+------------------------------------- Reporter: enolan | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3911 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D3911 * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 24 18:10:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Sep 2017 18:10:02 -0000 Subject: [GHC] #13911: GHC RTS VEH swallowing exceptions In-Reply-To: <046.bb432e5d5c87d29e6119047e833a9165@haskell.org> References: <046.bb432e5d5c87d29e6119047e833a9165@haskell.org> Message-ID: <061.737062ccc2c04b029c94615d1ce47263@haskell.org> #13911: GHC RTS VEH swallowing exceptions -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3911 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D3911 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 24 18:24:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Sep 2017 18:24:05 -0000 Subject: [GHC] #14246: Probably AllowAmbiguousTypes + UndecidableInstances + TypeInType In-Reply-To: <046.8b3b9e984fd26376daba4155f9345b3f@haskell.org> References: <046.8b3b9e984fd26376daba4155f9345b3f@haskell.org> Message-ID: <061.fbf0c00d7ae93db4442b44e1e3f93460@haskell.org> #14246: Probably AllowAmbiguousTypes + UndecidableInstances + TypeInType -------------------------------------+------------------------------------- Reporter: Toricon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13271 | 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 Sun Sep 24 18:24:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Sep 2017 18:24:49 -0000 Subject: [GHC] #14246: Probably AllowAmbiguousTypes + UndecidableInstances + TypeInType In-Reply-To: <046.8b3b9e984fd26376daba4155f9345b3f@haskell.org> References: <046.8b3b9e984fd26376daba4155f9345b3f@haskell.org> Message-ID: <061.bd9c459c9efd615e3f447029e6c47d08@haskell.org> #14246: Probably AllowAmbiguousTypes + UndecidableInstances + TypeInType -------------------------------------+------------------------------------- Reporter: Toricon | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13271 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 24 18:27:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Sep 2017 18:27:34 -0000 Subject: [GHC] #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) In-Reply-To: <050.081284759fbb3264e065177f36714c06@haskell.org> References: <050.081284759fbb3264e065177f36714c06@haskell.org> Message-ID: <065.748575ec93b0513c81a7006f8977c1bd@haskell.org> #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #3081 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Interesting. Do you have a hunch where `FreeConsole()` //should// live in `ghci.c`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 24 18:33:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Sep 2017 18:33:31 -0000 Subject: [GHC] #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) In-Reply-To: <050.081284759fbb3264e065177f36714c06@haskell.org> References: <050.081284759fbb3264e065177f36714c06@haskell.org> Message-ID: <065.f2d7330bb11a80269af0f50f68d4709c@haskell.org> #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #3081 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I think the code has to be slightly refactored. either a Boolean passed to `run` that indicates to call `FreeConsole` after the `CreateProcess` call, or run should return the process to wait on so callers can do custom stuff before blocking. I think `FreeConsole` has to be called after the new process is made so there are more than one process sharing the console, otherwise a call to `FreeConsole` will destroy the console and the new process won't have a console to use. At least I think... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 24 18:34:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Sep 2017 18:34:08 -0000 Subject: [GHC] #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) In-Reply-To: <050.081284759fbb3264e065177f36714c06@haskell.org> References: <050.081284759fbb3264e065177f36714c06@haskell.org> Message-ID: <065.e1ce72310433a85166230eeea2dd8f46@haskell.org> #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #3081 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Or maybe have `run` take a callback of sorts. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 24 18:34:41 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Sep 2017 18:34:41 -0000 Subject: [GHC] #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) In-Reply-To: <050.081284759fbb3264e065177f36714c06@haskell.org> References: <050.081284759fbb3264e065177f36714c06@haskell.org> Message-ID: <065.9db26790d334989c434c2f99ca18c26c@haskell.org> #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #3081 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * milestone: => 8.2.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 24 19:17:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Sep 2017 19:17:38 -0000 Subject: [GHC] #13707: xmobar crashes with segmentation faults? In-Reply-To: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> References: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> Message-ID: <061.99483e4cb5d313901829f390034aac95@haskell.org> #13707: xmobar crashes with segmentation faults? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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 Emantor): Sure, here is a new dump from a newly compiled executable which shows the same error. [https://magratgarlick.emantor.de/xmobar_bin_with_dump.tar.xz Download link] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 24 20:20:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Sep 2017 20:20:01 -0000 Subject: [GHC] #14188: On windows, trace prints out lines without proper line endings In-Reply-To: <046.a18d0ba283f4fb4d2734156aadd78dc2@haskell.org> References: <046.a18d0ba283f4fb4d2734156aadd78dc2@haskell.org> Message-ID: <061.7bab133c46cd2ed567d1b7a1c2973b57@haskell.org> #14188: On windows, trace prints out lines without proper line endings ---------------------------------+---------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4018 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D4018 * milestone: => 8.4.1 Comment: Something seems to be setting `stderr` in binary mode when `traceIO` is called. stuff written via the Haskell I/O manager seems to correct the mode before printing. So I'm doing the same in the C code now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Sep 24 22:27:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Sep 2017 22:27:35 -0000 Subject: [GHC] #14246: Probably AllowAmbiguousTypes + UndecidableInstances + TypeInType In-Reply-To: <046.8b3b9e984fd26376daba4155f9345b3f@haskell.org> References: <046.8b3b9e984fd26376daba4155f9345b3f@haskell.org> Message-ID: <061.9c64839dc7866ffdb3ace5fc42679d15@haskell.org> #14246: Probably AllowAmbiguousTypes + UndecidableInstances + TypeInType -------------------------------------+------------------------------------- Reporter: Toricon | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13271 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 07:59:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 07:59:53 -0000 Subject: [GHC] #12437: 20% regression in max_bytes_used for T1969 In-Reply-To: <047.090b2624111211cac9a272929b897b02@haskell.org> References: <047.090b2624111211cac9a272929b897b02@haskell.org> Message-ID: <062.20f98cc4ccbc9fb3779cc778b896bb7c@haskell.org> #12437: 20% regression in max_bytes_used for T1969 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: dfeuer Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): It really does look like the peak is higher in the after profile, but to find out what's causing that you'd need to compile GHC with profiling and do a real heap profile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 10:24:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 10:24:21 -0000 Subject: [GHC] #14272: GHC goes out of memory while compiling simple program with optimizations In-Reply-To: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> References: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> Message-ID: <062.bacc8e8495547bea7679f898d49cfd60@haskell.org> #14272: GHC goes out of memory while compiling simple program with optimizations -------------------------------------+------------------------------------- Reporter: 39aldo39 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Can anyone else reproduce this? I can't. Works fine for me with 7.10, 8.0, 8.2, and HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 12:27:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 12:27:54 -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.7c7e41c39410a607465c53bb20031688@haskell.org> #14231: Core lint error "in result of Static argument" -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think this is happening because of `Note [Shadow binder]` which sounds quite dubious. {{{ Note [Shadow binding] ~~~~~~~~~~~~~~~~~~~~~ The calls to the inner map inside body[map] should get inlined by the local re-binding of 'map'. We call this the "shadow binding". But we can't use the original binder 'map' unchanged, because it might be exported, in which case the shadow binding won't be discarded as dead code after it is inlined. So we use a hack: we make a new SysLocal binder with the *same* unique as binder. (Another alternative would be to reset the export flag.) }}} Then the shadowed binder is constructed from the unique of the old binder and the type of the shadowed_rhs. {{{ shadow_bndr = mkSysLocal (occNameFS (getOccName binder)) (idUnique binder) (exprType shadow_rhs) }}} It seems that the idea here is that we want to replace the self-recursive call with a call to the sat_worker. The mechanism for this is to create a local binding which shadows the top-level id which will be inlined in a later pass. In other parts of the compiler the way this would be achieved is to create a new top-level definition for the satted version of the function and then a `RULE` which rewrites the old version to the new version. Would that be preferable here as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 12:51:18 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 12:51:18 -0000 Subject: [GHC] #14272: GHC goes out of memory while compiling simple program with optimizations In-Reply-To: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> References: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> Message-ID: <062.b8eba970ca3c8081737fa31d5cf23f63@haskell.org> #14272: GHC goes out of memory while compiling simple program with optimizations -------------------------------------+------------------------------------- Reporter: 39aldo39 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Wow, indeed I can reproduce, {{{ $ ghc hi.hs -O [1 of 1] Compiling Main ( hi.hs, hi.o ) ghc: Out of memory $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.2.1 }}} Fascinating. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 12:53:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 12:53:16 -0000 Subject: [GHC] #14272: GHC goes out of memory while compiling simple program with optimizations In-Reply-To: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> References: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> Message-ID: <062.0a513c9290e595cc2cddb7cbd77ba3e9@haskell.org> #14272: GHC goes out of memory while compiling simple program with optimizations -------------------------------------+------------------------------------- Reporter: 39aldo39 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It seems like things go off the rails during the core-to-core phase, {{{ $ ghc hi.hs -O -v3 ... *** Worker Wrapper binds [Main]: Result size of Worker Wrapper binds = {terms: 221, types: 143, coercions: 17, joins: 0/7} !!! Worker Wrapper binds [Main]: finished in 0.25 milliseconds, allocated 0.166 megabytes *** Simplifier [Main]: Result size of Simplifier iteration=1 = {terms: 227, types: 138, coercions: 17, joins: 1/3} ghc: Out of memory }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 13:01:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 13:01:49 -0000 Subject: [GHC] #14265: kinded holes In-Reply-To: <048.88de9bb3140b448f46cfc61f85a9bdb3@haskell.org> References: <048.88de9bb3140b448f46cfc61f85a9bdb3@haskell.org> Message-ID: <063.5cd791556c1531c3767c68243f40cc82@haskell.org> #14265: kinded holes -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1b476ab55be6c2c553988cc63d8e0c5473136275/ghc" 1b476ab5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1b476ab55be6c2c553988cc63d8e0c5473136275" Improve type-error reporting This patch does two things: * When reporting a hole, we now include its kind if the kind is not just '*'. This addresses Trac #14265 * When reporting things like "'a' is a rigid type varaible bound by ...", this patch arranges to group the type variables together, so we don't repeat the "bound by..." stuff endlessly }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 13:01:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 13:01:49 -0000 Subject: [GHC] #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms In-Reply-To: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> References: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> Message-ID: <058.142c64b6c071641d3888794a4c86f3e6@haskell.org> #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms -------------------------------------+------------------------------------- Reporter: ntc2 | 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 Simon Peyton Jones ): In [changeset:"abed9bf5008baf6b3e84251fe4d07de80c532ead/ghc" abed9bf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="abed9bf5008baf6b3e84251fe4d07de80c532ead" Fix solving of implicit parameter constraints Trac #14218 showed that we were not solving implicit-parameter constraints correctly. In particular, - A tuple constraint could "hide" an implicit-parameter wanted constraint, and that in turn could that we solved it from the wrong implicit-parameter binding. - As a special case the HasCallStack constraint (which is just short for (IP "callStack" CallStack), was getting mis-solved. The big change is to arrange that, in TcSMonad.findDict when looking for a dictionary, either when looking for a matching inert or solved dictionary, we fail for - Tuples that are hiding implicit parameters See Note [Tuples hiding implicit parameters] - HasCallStack constraints where we have not yet pushed on the call-site info See Note [Solving CallStack constraints] I also did a little refactoring * Move naturallyCoherentClass from Class to TcInteract, its sole use site. Class.hs seems like the wrong place. (And I also do not understand the reason that we need the eq/Coercible/ Typable stuff in this predicate, but I'll tackle that separately.) * Move the code that pushes call-site info onto a call stack from the "interact" part to the "canonicalise" part of the solver. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 13:11:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 13:11:10 -0000 Subject: [GHC] #14265: kinded holes In-Reply-To: <048.88de9bb3140b448f46cfc61f85a9bdb3@haskell.org> References: <048.88de9bb3140b448f46cfc61f85a9bdb3@haskell.org> Message-ID: <063.994bdd63045024bcd08ac1223dfa4bff@haskell.org> #14265: kinded holes -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: fixed | 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 bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 13:14:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 13:14:05 -0000 Subject: [GHC] #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs In-Reply-To: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> References: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> Message-ID: <057.233f1d3f3b314cf86a3c71c904270357@haskell.org> #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: gdb, | debugging Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): So Phab:D3929 doesn't currently address the issue. I've found that `strace` produces some suspicious looking output when run on a program compiled with that patch, {{{ $ cat >hi.hs < GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 13:23:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 13:23:57 -0000 Subject: [GHC] #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs In-Reply-To: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> References: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> Message-ID: <057.2abff4fe24b7c3da4e9d47f10156d7f6@haskell.org> #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: gdb, | debugging Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ahh, I see, `advise` isn't a bitmap; I've confirmed that this, {{{#!c #include #include #include #include #include int main() { const int len = 1024*1024*1024; void *p = mmap(NULL, len, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0); if (p == MAP_FAILED) { printf("uh oh: mmap failed: %s\n", strerror(errno)); } int res = madvise(p, len, MADV_DONTDUMP); if (res != 0) { printf("uh oh: madvise failed: %s\n", strerror(errno)); } assert(0); // use generate-core-file in gdb when this is hit return 0; } }}} produces a small (510kB) core dump in `gdb`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 13:26:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 13:26:39 -0000 Subject: [GHC] #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs In-Reply-To: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> References: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> Message-ID: <057.bd6901cb59a3935cc78e8e9c87ac16fa@haskell.org> #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: gdb, | debugging Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): With Phab:D3929 appropriately updated the test from comment:5 produces a 7MByte core dump from `gdb`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 13:35:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 13:35:34 -0000 Subject: [GHC] #14272: GHC goes out of memory while compiling simple program with optimizations In-Reply-To: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> References: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> Message-ID: <062.b052a9cfbe30fbde80846883d699dfe5@haskell.org> #14272: GHC goes out of memory while compiling simple program with optimizations -------------------------------------+------------------------------------- Reporter: 39aldo39 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.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 bgamari): * priority: normal => high * milestone: => 8.4.1 Comment: This is still reproducible with `master`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 13:39:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 13:39:27 -0000 Subject: [GHC] #14272: GHC goes out of memory while compiling simple program with optimizations In-Reply-To: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> References: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> Message-ID: <062.faf4b01ef55369d1c84d2d737c3ccd47@haskell.org> #14272: GHC goes out of memory while compiling simple program with optimizations -------------------------------------+------------------------------------- Reporter: 39aldo39 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.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 bgamari): * cc: hvr (added) Comment: Hmm, so this is quite a hint, {{{ Thread 1 "ghc" hit Breakpoint 1, OutOfHeapHook (request_size=0, heap_size=0) at rts/hooks/OutOfHeap.c:17 17 rts/hooks/OutOfHeap.c: No such file or directory. (gdb) bt #0 OutOfHeapHook (request_size=0, heap_size=0) at rts/hooks/OutOfHeap.c:17 #1 0x00007f59ecb71d37 in allocate (cap=0x7f59ecba2080 , n=144115188075855874) at rts/sm/Storage.c:848 #2 0x00007f59ecb7c65e in stg_newByteArrayzh () from /opt/exp/ghc/roots/8.2.1-dwarf/lib/ghc-8.2.1/bin/../rts/libHSrts_thr- ghc8.2.1.so #3 0x0000000000000000 in ?? () (gdb) x/24a $rbp 0x42001edf88: 0x7f59ed060148 0x1ffffffffffffff 0x42001edf98: 0x3f 0x7f59ed0602a0 0x42001edfa8: 0x7f59ed05c240 0x7f59f165cf60 0x42001edfb8: 0x7f59ecb78f48 0x42008ebc60 0x42001edfc8: 0x7f59ed068fa0 0x7f59f2eaaeb1 0x42001edfd8: 0x7f59f165e9f0 0x42008ec930 0x42001edfe8: 0x42008ebc89 0x42008ec8ca 0x42001edff8: 0x7f59f2eaaed9 0x42008ec788 0x42001ee008: 0x7f59f165e290 0x7f59ed043c29 0x42001ee018: 0x42008ec788 0x42008ec7c8 0x42001ee028: 0x42008ec810 0x7f59f1a87b60 0x42001ee038: 0x42008ea4a8 0x4200e4ed5a }}} It looks like this may be an underflow in `integer-gmp`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 14:22:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 14:22:43 -0000 Subject: [GHC] #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL In-Reply-To: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> References: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> Message-ID: <061.a0061e12495f059c3fab55c2ed923a44@haskell.org> #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13304 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: Phyx- (added) Comment: Tamar, you may be interested in this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 14:23:15 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 14:23:15 -0000 Subject: [GHC] #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) In-Reply-To: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> References: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> Message-ID: <064.13804d58dcd19e70bac4757182c979c5@haskell.org> #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) -------------------------------------+------------------------------------- Reporter: carlostome | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14006 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari * priority: normal => high * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 14:42:29 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 14:42:29 -0000 Subject: [GHC] #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) In-Reply-To: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> References: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> Message-ID: <064.d6432125b5a0901b4780592826531e13@haskell.org> #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) -------------------------------------+------------------------------------- Reporter: carlostome | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14006 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mnislaih): * cc: mnislaih (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 15:04:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 15:04:54 -0000 Subject: [GHC] #14273: Typed holes are oblivious to type class constraints Message-ID: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> #14273: Typed holes are oblivious to type class constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This example is taken from Chris Allen's blog post [http://bitemyapp.com//posts/2017-09-23-please-stop-using-typed-holes.html here]: {{{#!hs pleaseShow :: Show a => Bool -> a -> Maybe String pleaseShow False _ = Nothing pleaseShow True a = Just (show _a) }}} On a recent GHC HEAD build, compiling this outputs: {{{ Bug.hs:3:32: error: • Found hole: _a :: a0 Where: ‘a0’ is an ambiguous type variable Or perhaps ‘_a’ is mis-spelled, or not in scope • In the first argument of ‘show’, namely ‘_a’ In the first argument of ‘Just’, namely ‘(show _a)’ In the expression: Just (show _a) • Relevant bindings include a :: a (bound at Bug.hs:3:17) pleaseShow :: Bool -> a -> Maybe String (bound at Bug.hs:2:1) Valid substitutions include (++) :: forall a. [a] -> [a] -> [a] (imported from ‘Prelude’ at Bug.hs:1:1 (and originally defined in ‘GHC.Base’)) fail :: forall (m :: * -> *). Monad m => forall a. String -> m a (imported from ‘Prelude’ at Bug.hs:1:1 (and originally defined in ‘GHC.Base’)) return :: forall (m :: * -> *). Monad m => forall a. a -> m a (imported from ‘Prelude’ at Bug.hs:1:1 (and originally defined in ‘GHC.Base’)) errorWithoutStackTrace :: forall (a :: TYPE r). [Char] -> a (imported from ‘Prelude’ at Bug.hs:1:1 (and originally defined in ‘GHC.Err’)) seq :: forall a b. a -> b -> b (imported from ‘Prelude’ at Bug.hs:1:1 (and originally defined in ‘GHC.Prim’)) (<>) :: forall a. Semigroup a => a -> a -> a (imported from ‘Prelude’ at Bug.hs:1:1 (and originally defined in ‘GHC.Base’)) (Some substitutions suppressed; use -fmax-valid-substitutions=N or -fno-max-valid-substitutions) | 3 | pleaseShow True a = Just (show _a) | ^^ }}} There are a couple very unsavory things about this error: 1. GHC makes no attempt to inform me that `a0` is a `Show` instance! This is the primary gripe in the blog post, and it's worth emphasizing, since without the `Show` constraint, `a0` just looks like any other random type variable. Speaking of which... 2. The list of valid substitutions is incorrect! It suggests several things which have function types, such as `(++)` and `fail`, but `(->)` does not have a `Show` instance! This list ought to be pruned based on the current type class constraints in scope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 15:09:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 15:09:37 -0000 Subject: [GHC] #14273: Typed holes are oblivious to type class constraints In-Reply-To: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> References: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> Message-ID: <065.f6ef196bb6f1a34b753ccc217f64804b@haskell.org> #14273: Typed holes are oblivious to type class constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Perhaps also the type of `pleaseShow` in the relevant bindings lacks the constraint on `a`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 15:11:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 15:11:38 -0000 Subject: [GHC] #14273: Typed holes are oblivious to type class constraints In-Reply-To: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> References: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> Message-ID: <065.2dfcb980411c0d4c6497b738d6e35dd5@haskell.org> #14273: Typed holes are oblivious to type class constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:1 mpickering]: > Perhaps also the type of `pleaseShow` in the relevant bindings lacks the constraint on `a`? Ah, right you are. The error states: {{{ • Relevant bindings include a :: a (bound at Bug.hs:3:17) pleaseShow :: Bool -> a -> Maybe String (bound at Bug.hs:2:1) }}} But that second binding really ought to be `pleaseShow :: Show a => Bool -> a -> Maybe String`, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 15:12:15 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 15:12:15 -0000 Subject: [GHC] #14265: kinded holes In-Reply-To: <048.88de9bb3140b448f46cfc61f85a9bdb3@haskell.org> References: <048.88de9bb3140b448f46cfc61f85a9bdb3@haskell.org> Message-ID: <063.5c3045107fa11e4f87f9a7f5007b9622@haskell.org> #14265: kinded holes -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: fixed | 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: | -------------------------------------+------------------------------------- Comment (by lspitzner): thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 15:38:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 15:38:56 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.261f5fdfe082618e003cb9d95fdf6e9b@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 mpickering): I looked at all the examples where allocations changed a significant amount. Essentially it seems to me the transformation is bad for allocations if it doesn't lead to more simplification but potentially very good if it does. There were particular situations where overloaded functions were satted as they had a normal static argument and a known dictionary argument. Normally the specialiser would be expected to deal with these but self- recursive functions are only specialised across modules if `-fspecialise- aggresively` is turned on or they are marked with an `INLINABLE` pragma. (For example `CSD`, `gg`). In situations where the definition was not further simplified, allocations tended to increase by a few %. So I'm not convinced that the example in comment:13 would be a win. There were also some situations where the unfolding for the satted definition was not exported as it was too big so there was never any potential for improvement. To sum up, there were some wins where SAT acted across modules where normal specialisation failed. Satting static function arguments could also be very good but only if there are actually some cases where the function is called with a static function argument. (For example #14211) In general though there was very little benefit satting as it seems that static values are not usually consumed by functions (and so no further simplification takes place after the sat). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 15:51:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 15:51:32 -0000 Subject: [GHC] #14144: Standardize binary distribution doc files In-Reply-To: <049.d1ba1a61ec88a72418a407b8a6104720@haskell.org> References: <049.d1ba1a61ec88a72418a407b8a6104720@haskell.org> Message-ID: <064.ec1bfdb42631fdb25368f3e86492394c@haskell.org> #14144: Standardize binary distribution doc files -------------------------------------+------------------------------------- Reporter: patrickdoc | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by patrickdoc): It appears that building all the docs on a single platform is not possible, unfortunately. Haddock cannot process `.hsc` files, but we cannot generate the associated `.hs` files because we do not have the headers. For example, `Win32/System/Types.hsc` includes `windows.h` and so cannot be preprocessed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 17:59:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 17:59:10 -0000 Subject: [GHC] #14274: Host normalization causes problem with configure. Message-ID: <044.31771bc37bd721949be567f01f57e551@haskell.org> #14274: Host normalization causes problem with configure. ----------------------------------------+---------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------- The host normalization we do causes problems with configure, because we change the triple autoconf seems to think we're always cross compiling on Windows. So `AC_CHECK_TARGET_TOOL` always fails and ends up looking for `-`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 18:28:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 18:28:47 -0000 Subject: [GHC] #14273: Typed holes are oblivious to type class constraints In-Reply-To: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> References: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> Message-ID: <065.b42c518894512ba3b0dda38095c7e0ea@haskell.org> #14273: Typed holes are oblivious to type class constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kosmikus): What about #9091? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 18:36:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 18:36:48 -0000 Subject: [GHC] #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints (was: Typed holes are oblivious to type class constraints) In-Reply-To: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> References: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> Message-ID: <065.c62ae61de013ce132d70eec9f87e16e5@haskell.org> #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #9091 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: Tritlo (added) * related: => #9091 Comment: Ah, I was not aware of that ticket! Thanks, kosmikus. As noted in the original comment, there are really two bugs here: 1. The lack of reporting about type class constraints in typed hole error messages. This, as it turns out, is essentially a duplicate of #9091. 2. The incorrect "valid substitution" suggestions. I move to make this ticket about that portion specifically. To this end, I've cc'd Tritlo, the author of these valid substitution suggestions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 18:37:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 18:37:45 -0000 Subject: [GHC] #9091: print and/or apply constraints when showing info for typed holes In-Reply-To: <047.d95c0766523b082befd3b58cd013d678@haskell.org> References: <047.d95c0766523b082befd3b58cd013d678@haskell.org> Message-ID: <062.758aeea8a35d398f15376ce3d008bc87@haskell.org> #9091: print and/or apply constraints when showing info for typed holes -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9479, #14273 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #9479 => #9479, #14273 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 19:14:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 19:14:39 -0000 Subject: [GHC] #14217: Interface-file decls for large tuples In-Reply-To: <047.bf95f3f7deae12cdefb07151e87149c3@haskell.org> References: <047.bf95f3f7deae12cdefb07151e87149c3@haskell.org> Message-ID: <062.41df5c170595a8a66899e632b1247cb2@haskell.org> #14217: Interface-file decls for large tuples -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Simon, you appear to have fixed (?) this bug in commit 3c74a51232813eb733b27c43c94ce005112a0ddb (`Deal with large extra- contraints wildcards`). Does that mean that this issue is resolved, and that we should merge 3c74a51232813eb733b27c43c94ce005112a0ddb to GHC 8.2.2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 19:15:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 19:15:55 -0000 Subject: [GHC] #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable In-Reply-To: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> References: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> Message-ID: <061.0f08f1cbc5ff1dbc19939ec3c76b96cc@haskell.org> #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11984, #14098 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"0e60cc1825aace414597b644731c30269994f7fb/ghc" 0e60cc1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0e60cc1825aace414597b644731c30269994f7fb" Document how GHC disambiguates between multiple COMPLETE sets Summary: Up until now, the knowledge of how GHC chooses which `COMPLETE` set to use in the presence of multiple applicable `COMPLETE` sets for a single data type constructor was only documented in the GHC wiki. But this really should be advertised to anyone who uses `COMPLETE` pragmas heavily, so per SPJ's advice in https://ghc.haskell.org/trac/ghc/ticket/14253#comment:10, this adds this wisdom to the GHC users' guide. Test Plan: Read it Reviewers: austin, bgamari Subscribers: mpickering, rwbarton, thomie GHC Trac Issues: #14253 Differential Revision: https://phabricator.haskell.org/D4005 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 19:22:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 19:22:08 -0000 Subject: [GHC] #14188: On windows, trace prints out lines without proper line endings In-Reply-To: <046.a18d0ba283f4fb4d2734156aadd78dc2@haskell.org> References: <046.a18d0ba283f4fb4d2734156aadd78dc2@haskell.org> Message-ID: <061.5d7abf8cdad0bd2b30780195293caa50@haskell.org> #14188: On windows, trace prints out lines without proper line endings ---------------------------------+---------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4018 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Tamar Christina ): In [changeset:"2b2595e03d328f8c49afe55f765635c03dc81865/ghc" 2b2595e0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2b2595e03d328f8c49afe55f765635c03dc81865" Ensure text mode when calling debug functions Summary: Something seems to be changing stderr into binary mode, so when the `traceIO` is called, the C code that ultimately calls `vfprintf` is using a binary mode handle. This causes newlines not to be encoded properly. The patch ensures we're in text mode when writing the debug messages (% interleaving as it's not thread safe at all) and restores the previous mode when done. I'm slightly concerned about the performance implications of writing large dumps out in text mode, but I think the current behavior is not intended as I cannot see any of the printing code setting the mode of the std handles. Test Plan: ./validate Reviewers: austin, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14188 Differential Revision: https://phabricator.haskell.org/D4018 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 19:23:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 19:23:48 -0000 Subject: [GHC] #14188: On windows, trace prints out lines without proper line endings In-Reply-To: <046.a18d0ba283f4fb4d2734156aadd78dc2@haskell.org> References: <046.a18d0ba283f4fb4d2734156aadd78dc2@haskell.org> Message-ID: <061.1b1309f911292c8e7dd1dfadeac66a3e@haskell.org> #14188: On windows, trace prints out lines without proper line endings ---------------------------------+---------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4018 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 19:31:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 19:31:19 -0000 Subject: [GHC] #14272: GHC goes out of memory while compiling simple program with optimizations In-Reply-To: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> References: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> Message-ID: <062.e488443c5f2f83552539b7b16f1e5dbf@haskell.org> #14272: GHC goes out of memory while compiling simple program with optimizations -------------------------------------+------------------------------------- Reporter: 39aldo39 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.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): Phab:D4021 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D4021 Comment: Hmm, so the `i#` argument of `bitBigNat` is `0x7fffffffffffffff` in the failing call. The crash can be easily reproduced with simply `Data.Bits.bit 0x7fffffffffffffff`. Phab:D4021 should make the heap overflow a proper exception instead of bringing down the entire process (making debugging much easier). I still have yet to figure out exactly how the simplifier is producing this huge literal but regardless GHC should clearly behave a bit better here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 19:49:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 19:49:07 -0000 Subject: [GHC] #14272: GHC goes out of memory while compiling simple program with optimizations In-Reply-To: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> References: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> Message-ID: <062.aa6fa07be8d095332323d587c3412ba3@haskell.org> #14272: GHC goes out of memory while compiling simple program with optimizations -------------------------------------+------------------------------------- Reporter: 39aldo39 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.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): Phab:D4021 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, here is the full backtrace, {{{ *** Exception (reporting due to +RTS -xc): (base:GHC.Exception.SomeException), stack trace: GhcMonad.gcatch, called from HscTypes.handleSourceError, called from GHC.Integer.Type.newBigNat#, called from GHC.Integer.Type.runS, called from GHC.Integer.Type.bitBigNat, called from GHC.Integer.Type.bitInteger, called from GHC.Integer.Type.shiftLInteger, called from PrelRules.intOp2', called from PrelRules.intOp2, called from PrelRules.primOpRules, called from MkId.mkPrimOpId, called from PrelInfo.primOpIds, called from Rules.matchRule, called from Rules.lookupRule, called from Simplify.tryRules, called from Simplify.rebuildCall, called from Simplify.rebuild, called from Simplify.simplExprF1, called from Simplify.simplExprF, called from Simplify.simplLazyBind, called from Outputable.pprDebugAndThen, called from Outputable.pprTrace, called from Simplify.simplRecOrTopPair, called from Simplify.simplRecBind, called from Simplify.simplTopBinds, called from SimplCore.SimplTopBinds, called from SimplMonad.initSmpl, called from SimplCore.simplifyPgmIO, called from CoreMonad.liftIO, called from CoreMonad.liftIOWithCount, called from SimplCore.simplifyPgm, called from SimplCore.Simplify, called from SimplCore.doCorePass, called from CoreLint.lintAnnots, called from SimplCore.runCorePasses, called from IOEnv.thenM, called from CoreMonad.>>=, called from IOEnv.runIOEnv, called from CoreMonad.runCoreM, called from SimplCore.core2core, called from HscTypes.liftIO, called from HscMain.Core2Core, called from HscTypes.>>=, called from HscTypes.runHsc, called from HscMain.hscIncrementalCompile, called from DriverPipeline.compileOne', called from GhcMake.upsweep_mod.compile_it, called from GhcMake.upsweep_mod, called from GhcMake.upsweep.upsweep', called from GhcMake.upsweep, called from GhcMake.load, called from GhcMonad.>>=, }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 19:58:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 19:58:59 -0000 Subject: [GHC] #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints In-Reply-To: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> References: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> Message-ID: <065.7587e8a3f07eb55ef09792be6dc7748e@haskell.org> #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #9091 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): I'll have a look at the incorrect suggestions! About the missing constraint: if you add the -fshow-hole-constraints flag, you'll get a "Constraints include" part in the hole's type error message. Maybe it should be on by default? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 20:17:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 20:17:59 -0000 Subject: [GHC] #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal In-Reply-To: <042.d21b92eb840644cd16549869583bccd0@haskell.org> References: <042.d21b92eb840644cd16549869583bccd0@haskell.org> Message-ID: <057.3b3ac1496259629513a77056f1b5f9cf@haskell.org> #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14236 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Wow. That looks fun to munch on later. But in the meantime, where is this RULE in the source? I sadly can't find it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 20:21:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 20:21:05 -0000 Subject: [GHC] #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints In-Reply-To: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> References: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> Message-ID: <065.f7cac1d908e900b9f1ea1189c3f450cb@haskell.org> #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #9091 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:5 Tritlo]: > About the missing constraint: if you add the -fshow-hole-constraints flag, you'll get a "Constraints include" part in the hole's type error message. Maybe it should be on by default? It seems that this blog post highlights that users would like to know that about the hole. Yes please! I didn't even know this option existed. If it's not on by default (which I imagine it should be), GHC should at least suggest it every time it encounters a typed hole that has constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 20:21:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 20:21:08 -0000 Subject: [GHC] #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints In-Reply-To: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> References: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> Message-ID: <065.a2c7490495a5cbca69a0c95aec19316d@haskell.org> #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #9091 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): Ah, I see where the problem lies. It wraps the hole with the constraints from the implications from the context, but in this case, it is the `show` function which imposes new constraints on the hole, but as you say, this is not reflected in the type of the hole (i.e. the subtype checker is checking whether `forall a. Num a => a -> a -> a` fits the hole of type `Show a => a0_a1m3[tau:2]`, where (as we can see), the mentioned `a` is not `a0_a1m3[tau:2]`, which is the ambiguous type variable in question. I'll get to work on fixing that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 20:24:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 20:24:57 -0000 Subject: [GHC] #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints In-Reply-To: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> References: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> Message-ID: <065.fb658ae3963ab7479c1a627d618c87cf@haskell.org> #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #9091 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Tritlo): * owner: (none) => Tritlo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 20:39:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 20:39:06 -0000 Subject: [GHC] #14275: Large Haskell value unexpectedly gets an unfolding Message-ID: <046.a11f64e5c2dcd96ac5a687edb56de84b@haskell.org> #14275: Large Haskell value unexpectedly gets an unfolding -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While working on #14272 I was surprised to find that modifying `PrelRules` resulted in a great deal of recompilation. Afterall, it has only three exports: * `primOpRules`: A function headed by a rather large case analysis totaling a few hundred lines of code * `builtinRules`: A large `[CoreRule]` (consisting of a literal list with six entries concatenated with the much-larger `builtInIntegerRules`) * `caseRules`: A function of moderate size Intuitively, none of these things seemed particularly beneficial to inline. This is why I was slightly surprised to find that `builtinRules` (and all of its floated entries) had an unfolding, {{{ builtinRules :: [CoreRule] {- Strictness: m2, Unfolding: (: @ CoreRule builtinRules255 builtinRules1) -} }}} Of course, determining whether unfoldings are helpful is in general quite difficult. However, I can't help but wonder whether our heuristic isn't quite right. Afterall, the Haskell for `builtinRules` is quite large and consequently most users would be surprised to see GHC try to inline it. The only reason it looks so small is that GHC broke up the structure via float-out. I don't have any concrete ideas for addressing this at the moment but felt like I should write down the concern so it isn't lost. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 20:43:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 20:43:53 -0000 Subject: [GHC] #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable In-Reply-To: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> References: <046.9aa81a6fda67d27ca0e29667b6cd0aa9@haskell.org> Message-ID: <061.fbb3b689def67928f450cb91a5c3f03c@haskell.org> #14253: Pattern match checker mistakenly concludes pattern match on pattern synonym is unreachable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11984, #14098 | Differential Rev(s): Phab:D4005 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * differential: => Phab:D4005 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 20:46:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 20:46:09 -0000 Subject: [GHC] #14272: GHC goes out of memory while compiling simple program with optimizations In-Reply-To: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> References: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> Message-ID: <062.eeedbfcfe8b10eb7a7d01da9afe74fa0@haskell.org> #14272: GHC goes out of memory while compiling simple program with optimizations -------------------------------------+------------------------------------- Reporter: 39aldo39 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.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): Phab:D4021, Wiki Page: | Phab:D4025 -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D4021 => Phab:D4021, Phab:D4025 Comment: Alright, so the problem is fairly obvious: after some amount of simplification we end up with `... (GHC.Prim.uncheckedIShiftL# 1# x_a3q9) ...`. After a bit more simplification we learn (due to case analysis) that `x_a3q9 = 9223372036854775807#`. This allows the `uncheckedIShiftL#` constant folding rule to fire, which then blows up as the result is absurdly large. This is fixed by adding another constant folding rule to catch this case (which should result in `0#`). This is done in Phab:D4025. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 21:04:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 21:04:11 -0000 Subject: [GHC] #14275: Large Haskell value unexpectedly gets an unfolding In-Reply-To: <046.a11f64e5c2dcd96ac5a687edb56de84b@haskell.org> References: <046.a11f64e5c2dcd96ac5a687edb56de84b@haskell.org> Message-ID: <061.5e03daa36fe76da697f1d9762b15f3f0@haskell.org> #14275: Large Haskell value unexpectedly gets an unfolding -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 21:20:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 21:20:11 -0000 Subject: [GHC] #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) In-Reply-To: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> References: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> Message-ID: <064.725e8aaf7bbea70f61ffb02cbf2e1b29@haskell.org> #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) -------------------------------------+------------------------------------- Reporter: carlostome | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14006 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alexandersgreen): * cc: alexandersgreen (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 21:29:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 21:29:27 -0000 Subject: [GHC] #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints In-Reply-To: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> References: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> Message-ID: <065.7c7d8704a028a74e54d36917c5c33ffc@haskell.org> #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #9091 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): And the plot thickens: if I add a module declaration, I get an additional error message, i.e., when the code is the following: {{{ module TestShow where pleaseShow :: Show a => Bool -> a -> Maybe String pleaseShow False _ = Nothing pleaseShow True a = Just (show _a) }}} I get the same error as before, but now with an additional message before the typed hole error message: {{{ t4.hs:5:28: error: • Could not deduce (Show a0) arising from a use of ‘show’ from the context: Show a bound by the type signature for: pleaseShow :: forall a. Show a => Bool -> a -> Maybe String at t4.hs:3:1-49 The type variable ‘a0’ is ambiguous These potential instances exist: instance (Show b, Show a) => Show (Either a b) -- Defined in ‘Data.Either’ instance Show Ordering -- Defined in ‘GHC.Show’ instance Show Integer -- Defined in ‘GHC.Show’ ...plus 23 others ...plus 54 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the first argument of ‘Just’, namely ‘(show _a)’ In the expression: Just (show _a) In an equation for ‘pleaseShow’: pleaseShow True a = Just (show _a) | 5 | pleaseShow True a = Just (show _a) | ^^^^^^^ }}} Which does tell you the constraint on the hole (if you connect the ambiguous type variable names yourself). I suspect I'll have to invoke the same mechanism, and then add the constraints derived with that mechanism and wrap the type with that as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 23:07:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 23:07:36 -0000 Subject: [GHC] #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) In-Reply-To: <050.081284759fbb3264e065177f36714c06@haskell.org> References: <050.081284759fbb3264e065177f36714c06@haskell.org> Message-ID: <065.0ec3a246b2e54322588e7c5148ad92bb@haskell.org> #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #3081 | Differential Rev(s): Phab:D4028 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D4028 * milestone: 8.2.2 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 23:19:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 23:19:08 -0000 Subject: [GHC] #14274: Host normalization causes problem with configure. In-Reply-To: <044.31771bc37bd721949be567f01f57e551@haskell.org> References: <044.31771bc37bd721949be567f01f57e551@haskell.org> Message-ID: <059.3d9e77980ab5843c13c230eaf933a8fe@haskell.org> #14274: Host normalization causes problem with configure. ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Tamar Christina ): In [changeset:"c839c57ed372203b05407b2042d00c188af75310/ghc" c839c57e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c839c57ed372203b05407b2042d00c188af75310" Fix the searching of target AR tool Summary: Ar was being checked twice prior to D3883 where I removed one of the checks because the converted path was being overridden after the check because of the second check for Ar. However the one in configure.ac was a target check so I'm changing the path check to a target check now. Test Plan: ./configure Reviewers: angerman, austin, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, erikd GHC Trac Issues: #14274 Differential Revision: https://phabricator.haskell.org/D4020 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Sep 25 23:21:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Sep 2017 23:21:17 -0000 Subject: [GHC] #420: O'Haskell In-Reply-To: <043.85eea6d2fdc5ea4d79df32edc41b4340@haskell.org> References: <043.85eea6d2fdc5ea4d79df32edc41b4340@haskell.org> Message-ID: <058.00ad0fefefec7d61573ff422d9645098@haskell.org> #420: O'Haskell -------------------------------------+--------------------------------- Reporter: mlbm | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: ⊥ Component: None | Version: None Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A -------------------------------------+--------------------------------- Comment (by Tamar Christina ): In [changeset:"abca29f3f3e19c4af452c1714be1bf33f4ac9180/ghc" abca29f3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="abca29f3f3e19c4af452c1714be1bf33f4ac9180" Adds mingw64 to the valid GHC OSs. Summary: This fixes hadrian#420 (https://github.com/snowleopard/hadrian/issues/420) specifically the "Unknown OS mingw64". Reviewers: austin, hvr, bgamari, Phyx Reviewed By: Phyx Subscribers: rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D4016 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 00:38:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 00:38:04 -0000 Subject: [GHC] #14276: T13168 is broken on Windows Message-ID: <046.a7e429e12bace0617ee481a085e70b93@haskell.org> #14276: T13168 is broken on Windows ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Due to the lack of shared library support. {{{ Actual stderr output differs from expected: diff -uw "./typecheck/T13168/T13168.run/T13168.stderr.normalised" "./typecheck/T13168/T13168.run/T13168.run.stderr.normalised" --- ./typecheck/T13168/T13168.run/T13168.stderr.normalised 2017-09-26 00:20:55.835321400 -0400 +++ ./typecheck/T13168/T13168.run/T13168.run.stderr.normalised 2017-09-26 00:20:55.836298600 -0400 @@ -1,4 +0,0 @@ -Warning: -rtsopts and -with-rtsopts have no effect with -shared. - Call hs_init_ghc() from your main() function to set these options. -Warning: -rtsopts and -with-rtsopts have no effect with -shared. - Call hs_init_ghc() from your main() function to set these options. *** unexpected failure for T13168(normal) }}} Really this output is spurious anyways and in principle shouldn't affect the test passage. That being said, I don't see an easy way to filter it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 02:44:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 02:44:22 -0000 Subject: [GHC] #14199: Document Type.Reflection better (Fun and Con') In-Reply-To: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> References: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> Message-ID: <060.87654e7ee63e4b1d213ad45bd836505f@haskell.org> #14199: Document Type.Reflection better (Fun and Con') -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3943, Wiki Page: | Phab:D3991 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6de1a5a96cdaba080570e9f47ff8711796e2e83b/ghc" 6de1a5a9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6de1a5a96cdaba080570e9f47ff8711796e2e83b" Document Typeable's treatment of kind polymorphic tycons Test Plan: Read it Reviewers: dfeuer, goldfire, austin, hvr Reviewed By: dfeuer Subscribers: rwbarton, thomie GHC Trac Issues: #14199 Differential Revision: https://phabricator.haskell.org/D3991 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 02:44:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 02:44:22 -0000 Subject: [GHC] #14275: Large Haskell value unexpectedly gets an unfolding In-Reply-To: <046.a11f64e5c2dcd96ac5a687edb56de84b@haskell.org> References: <046.a11f64e5c2dcd96ac5a687edb56de84b@haskell.org> Message-ID: <061.a507a00c8ec1a971d55c68ae543869ae@haskell.org> #14275: Large Haskell value unexpectedly gets an unfolding -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Inlining Operating System: 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:"d11611f5739284cc6aab9b2636ac6485352107ea/ghc" d11611f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d11611f5739284cc6aab9b2636ac6485352107ea" Add NOINLINE pragma to builtinRules As mentioned in #14275, GHC will otherwise decide to produce unfoldings for this rather large binding, making recompilation more expensive than necessary. Since inlining is almost certainly not fruitful mark it as NOINLINE. [skip ci] Test Plan: Validate Reviewers: austin Subscribers: rwbarton, thomie GHC Trac Issues: #14275 Differential Revision: https://phabricator.haskell.org/D4023 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 02:44:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 02:44:22 -0000 Subject: [GHC] #14153: Change worker thread name to something mentioning original process name In-Reply-To: <045.51d1772d93ea20bf954892cfb97d76de@haskell.org> References: <045.51d1772d93ea20bf954892cfb97d76de@haskell.org> Message-ID: <060.45306704b8de3e9206d009aa4f6de8ee@haskell.org> #14153: Change worker thread name to something mentioning original process name -------------------------------------+------------------------------------- Reporter: enolan | Owner: enolan Type: feature request | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D4001 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d07b8c7ae8bc22a7c36c96cb3fd800aecdde6eac/ghc" d07b8c7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d07b8c7ae8bc22a7c36c96cb3fd800aecdde6eac" Include original process name in worker thread name (#14153) Prior to this commit, worker OS thread were renamed to "ghc_worker" when spawned. This was annoying when reading debugging messages that print the process name because it doesn't tell you *which* Haskell program is generating the message. This commit changes it to "original_process_name:w", truncating the original name to fit in the kernel buffer if neccesary. Test Plan: ./validate Reviewers: austin, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: Phyx, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4001 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 02:44:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 02:44:22 -0000 Subject: [GHC] #14276: T13168 is broken on Windows In-Reply-To: <046.a7e429e12bace0617ee481a085e70b93@haskell.org> References: <046.a7e429e12bace0617ee481a085e70b93@haskell.org> Message-ID: <061.28f2e36bb46700b9d8beb43fa8591e5a@haskell.org> #14276: T13168 is broken on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 Ben Gamari ): In [changeset:"2f8e6e7f8696213b95e3461224909c3b2ec4f7aa/ghc" 2f8e6e7f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2f8e6e7f8696213b95e3461224909c3b2ec4f7aa" testsuite: Expect T13168 to be broken on Windows Spurious output pertaining to dynamic linking causes it to fail. See #14276. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 02:45:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 02:45:17 -0000 Subject: [GHC] #14199: Document Type.Reflection better (Fun and Con') In-Reply-To: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> References: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> Message-ID: <060.2020150d959672abc5c07bd77acf8d6c@haskell.org> #14199: Document Type.Reflection better (Fun and Con') -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.2.2 Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3943, Wiki Page: | Phab:D3991 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 02:45:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 02:45:52 -0000 Subject: [GHC] #14153: Change worker thread name to something mentioning original process name In-Reply-To: <045.51d1772d93ea20bf954892cfb97d76de@haskell.org> References: <045.51d1772d93ea20bf954892cfb97d76de@haskell.org> Message-ID: <060.96e0df16b9459ba7077c975e5090779c@haskell.org> #14153: Change worker thread name to something mentioning original process name -------------------------------------+------------------------------------- Reporter: enolan | Owner: enolan Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D4001 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 03:54:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 03:54:08 -0000 Subject: [GHC] #13707: xmobar crashes with segmentation faults? In-Reply-To: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> References: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> Message-ID: <061.11564538e3b8f0d2be16b2fa26ca97ed@haskell.org> #13707: xmobar crashes with segmentation faults? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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 Rufflewind): The crash is quite rare and sporadic. I've had it run for 1-3 days without crashing. GDB: {{{ 0x7ffff55ffcdd or rdx,rcx > 0x7ffff55ffce0 movzx ecx,WORD PTR [rdx+0x2e] 0x7ffff55ffce4 test cx,0x20b > print/x $rdx # variable "bd" 0x6300000000 > backtrace #0 evacuate (p=p at entry=0x4200266b98) at rts/sm/Evac.c:583 #1 0x00007ffff55ff155 in scavenge_block (bd=0x4200201980) at rts/sm/Scav.c:548 #2 0x00007ffff561495e in scavenge_find_work () at rts/sm/Scav.c:2132 #3 scavenge_loop () at rts/sm/Scav.c:2195 #4 0x00007ffff561b08f in scavenge_until_all_done () at rts/sm/GC.c:1020 #5 GarbageCollect (collect_gen=collect_gen at entry=1, do_heap_census=do_heap_census at entry=false, gc_type=gc_type at entry=0, cap=cap at entry=0x7ffff5648a00 , idle_cap=idle_cap at entry=0x0) at rts/sm/GC.c:406 #6 0x00007ffff560da3d in scheduleDoGC (pcap=pcap at entry=0x7fffffffdba8, task=task at entry=0x5c28d0, force_major=force_major at entry=false) at rts/Schedule.c:1822 #7 0x00007ffff560e6fb in schedule (task=0x5c28d0, initialCapability=) at rts/Schedule.c:558 #8 scheduleWaitThread (tso=, ret=ret at entry=0x0, pcap=pcap at entry=0x7fffffffdc08) at rts/Schedule.c:2551 #9 0x00007ffff560fed8 in rts_evalLazyIO (cap=cap at entry=0x7fffffffdc08, p=p at entry=0x5ad4a0, ret=ret at entry=0x0) at rts/RtsAPI.c:530 #10 0x00007ffff561086e in hs_main (argc=1, argv=0x7fffffffddd8, main_closure=0x5ad4a0, rts_config=...) at rts/RtsMain.c:64 #11 0x0000000000578fe1 in main () }}} Built using GHC from https://downloads.haskell.org/~ghc/8.2.1/ghc-8.2.1-x86_64-deb8-linux.tar.xz installed on Arch Linux with ncurses5-compat-libs. xmobar was built with: {{{ cabal install --disable-executable-stripping --with- ghc=/opt/ghc-8.2.1/bin/ghc \ -f 'with_utf8 with_xft with_iwlib with_xpm with_inotify' constraints: HTTP ==4000.3.7, X11 ==1.8, array ==0.5.2.0, base ==4.10.0.0, binary ==0.8.5.1, bytestring ==0.10.8.2, containers ==0.5.10.2, data-default ==0.7.1.1, data-default-class ==0.1.2.0, data-default-instances-containers ==0.0.1, data-default-instances-dlist ==0.0.1, data-default-instances-old-locale ==0.0.1, deepseq ==1.4.3.0, directory ==1.3.0.2, dlist ==0.8.0.3, filepath ==1.4.1.2, ghc-prim ==0.5.1.0, integer-gmp ==1.0.1.0, mtl ==2.2.1, network ==2.6.3.2, network-uri ==2.6.1.0, old-locale ==1.0.0.7, parsec ==3.1.11, process ==1.6.1.0, regex-base ==0.93.2, regex-compat ==0.95.1, regex-posix ==0.95.2, rts ==1.0, stm ==2.4.4.1, text ==1.2.2.2, time ==1.8.0.2, transformers ==0.5.2.0, unix ==2.7.2.2, utf8-string ==1.0.1.1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 04:17:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 04:17:31 -0000 Subject: [GHC] #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints In-Reply-To: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> References: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> Message-ID: <065.efc7da61e8bcdcaf806c078af4a641bd@haskell.org> #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #9091, #9479 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) * related: #9091 => #9091, #9479 * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 07:50:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 07:50:58 -0000 Subject: [GHC] #13707: xmobar crashes with segmentation faults? In-Reply-To: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> References: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> Message-ID: <061.845cca473fb23df9f6e34406b3509ef8@haskell.org> #13707: xmobar crashes with segmentation faults? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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 Emantor): I can make it crash on demand by switching workspaces/windows using the XmonadLog Plugin, i'd say its one out of three times. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 09:03:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 09:03:24 -0000 Subject: [GHC] #14265: kinded holes In-Reply-To: <048.88de9bb3140b448f46cfc61f85a9bdb3@haskell.org> References: <048.88de9bb3140b448f46cfc61f85a9bdb3@haskell.org> Message-ID: <063.b60992a82a39977131f6015a8df7930f@haskell.org> #14265: kinded holes -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: fixed | PartialTypeSignatures Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T14265 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => polykinds/T14265 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 09:05:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 09:05:03 -0000 Subject: [GHC] #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms In-Reply-To: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> References: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> Message-ID: <058.37c0b58e784fba7f35295730065cf18f@haskell.org> #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_run/T14218 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_run/T14218 * status: new => merge * milestone: => 8.2.2 Comment: Thanks for reporting this bug. It is a rather insidious and long-standing one. The test I added has two cases, one for vanilla implicit parameters and one for call-stacks. Could consider merging this to 8.2, but I doubt it'll affect many people. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 10:07:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 10:07:29 -0000 Subject: [GHC] #14277: Missing release version number in in the HTML User's Guide Message-ID: <045.66f6bb2c0ee6c79826c97c95ed6fa441@haskell.org> #14277: Missing release version number in <title> in the HTML User's Guide -------------------------------------+------------------------------------- Reporter: refold | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See, for example, here: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flags.html The `<title>` of that page is `6.6. Flag reference — Glasgow Haskell Compiler <release> User's Guide`. It should be the actual version number (in this case, 8.2.1) instead of the `<release>` placeholder. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14277> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 10:08:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 10:08:06 -0000 Subject: [GHC] #14277: Missing release version number in <title> in the HTML User's Guide In-Reply-To: <045.66f6bb2c0ee6c79826c97c95ed6fa441@haskell.org> References: <045.66f6bb2c0ee6c79826c97c95ed6fa441@haskell.org> Message-ID: <060.d3fea0b3fee8286172a4e5162c88390f@haskell.org> #14277: Missing release version number in <title> in the HTML User's Guide -------------------------------------+------------------------------------- Reporter: refold | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by refold: Old description: > See, for example, here: > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flags.html > > The `<title>` of that page is `6.6. Flag reference — Glasgow > Haskell Compiler <release> User's Guide`. > > It should be the actual version number (in this case, 8.2.1) instead of > the `<release>` placeholder. New description: See, for example, here: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flags.html The `<title>` of that page is `6.6. Flag reference — Glasgow Haskell Compiler <release> User's Guide`. It should use the actual version number (in this case, 8.2.1) instead of the `<release>` placeholder. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14277#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 10:40:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 10:40:15 -0000 Subject: [GHC] #14275: Large Haskell value unexpectedly gets an unfolding In-Reply-To: <046.a11f64e5c2dcd96ac5a687edb56de84b@haskell.org> References: <046.a11f64e5c2dcd96ac5a687edb56de84b@haskell.org> Message-ID: <061.6f32112b9fca709d54ba5aa0345496af@haskell.org> #14275: Large Haskell value unexpectedly gets an unfolding -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Inlining Operating System: 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): Fine. It's exposed because we might see `case builtinRules of ...` somewhere. But we never do.. we just fold or map over it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14275#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 12:45:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 12:45:09 -0000 Subject: [GHC] #14278: undefined symbol: gsl_multiroot_fsolver_broyden Message-ID: <044.9c13fc4e0594c7ae7edf5adaaceb2889@haskell.org> #14278: undefined symbol: gsl_multiroot_fsolver_broyden ----------------------------------------+------------------------------- Reporter: smyds | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- Hi, I am trying to compile the package [https://hackage.haskell.org/package/hmatrix hmatrix]. After cloning the [https://github.com/albertoruiz/hmatrix git repository], I ran {{{$ stack setup}}} and {{{$ stack build}}} successfully but then I ran into this : {{{ $ stack repl Configuring GHCi with the following packages: hmatrix, hmatrix-glpk, hmatrix-gsl, hmatrix-special, hmatrix-tests GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for i386-unknown-linux): Loading temp shared object failed: /tmp/ghc25335_0/libghc_7.so: undefined symbol: gsl_multiroot_fsolver_broyden Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I am running this on a devuan x86 machine, but I have tried the same procedure on a debian x86_64 with a similar result. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14278> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 13:22:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 13:22:04 -0000 Subject: [GHC] #14278: undefined symbol: gsl_multiroot_fsolver_broyden In-Reply-To: <044.9c13fc4e0594c7ae7edf5adaaceb2889@haskell.org> References: <044.9c13fc4e0594c7ae7edf5adaaceb2889@haskell.org> Message-ID: <059.e86eb1cbaf7caad4fe05cc2994ba1f1d@haskell.org> #14278: undefined symbol: gsl_multiroot_fsolver_broyden -------------------------------+---------------------------------------- Reporter: smyds | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+---------------------------------------- Changes (by smyds): * version: 8.2.1 => 8.0.2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14278#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 13:27:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 13:27:59 -0000 Subject: [GHC] #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal In-Reply-To: <042.d21b92eb840644cd16549869583bccd0@haskell.org> References: <042.d21b92eb840644cd16549869583bccd0@haskell.org> Message-ID: <057.8ae0d87de85bf47d0b6cfd409c35e9aa@haskell.org> #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14236 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I have not reproduced this, but the RULE comes from `SpecConstr`. Presumably it sees a call to {{{ mkTrApp @(b_a3RY |> blah) ... (TrTyCon @(b_a3RY |> blah) e1 ...) }}} and creates a specialised copy of `mkTrApp`, something like {{{ $smkTrApp sc1 sc2 sc3 = <body of mkTrApp applied to suitable args> }}} along with a RULE to convert calls to `mkTrApp` into calls to `$smkTrApp`, something like {{{ RULE "SC:mkTrApp0" forall sc1 sc2 sc3. mkTrApp @(b_a3RY |> blah) ... = $smkTrApp sc1 sc2 sc3 }}} So that's how those casts end up on the LHS of a RULE. I have not yet figured out why we put a coercion variable in the template variables. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14270#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 13:39:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 13:39:35 -0000 Subject: [GHC] #14144: Standardize binary distribution doc files In-Reply-To: <049.d1ba1a61ec88a72418a407b8a6104720@haskell.org> References: <049.d1ba1a61ec88a72418a407b8a6104720@haskell.org> Message-ID: <064.a9e7b45d890376e6ca4a929f9ca64dfb@haskell.org> #14144: Standardize binary distribution doc files -------------------------------------+------------------------------------- Reporter: patrickdoc | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ahh yes, that is unfortunate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14144#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 13:45:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 13:45:34 -0000 Subject: [GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" In-Reply-To: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> References: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> Message-ID: <062.d2ff8c59bcc2f9af17869198448e0d70@haskell.org> #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): Replying to [comment:9 simonpj]: > Sounds complicated enough to be worth a Haskell Symposium paper! Seriously, writing a paper is often a good way to refine an idea. Having that opportunity would be wonderful. I have to write it up with rigor for my undergrad thesis anyway. For a update on the progress: * I've put instrumentation code into GHC to extract patterns. * I've coded up a simplified version of the current algorithm outside of GHC. Simplifications are: * It only covers Constructor/Wildcard/Variable patterns. * It only selects a rhs but does no binding/the associated bookkeeping. * Record patterns with a different order then their definition are treated like a different constructor. * It treats all patterns as non-exhaustive. * I fully formulated my approach for matching the strictness of the current algorithm. The next steps are: * Implement my approach. * Get some statistics of their differences. * If it seems worthwhile try to measure the impact of the simplifier. (As the output of the desugar stage can be a lot worse and yet still result in perfect code). * Document the results in a presentable form. * Depending on how promising the results are hopefully implement the new approach in GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14201#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 13:57:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 13:57:17 -0000 Subject: [GHC] #14278: undefined symbol: gsl_multiroot_fsolver_broyden In-Reply-To: <044.9c13fc4e0594c7ae7edf5adaaceb2889@haskell.org> References: <044.9c13fc4e0594c7ae7edf5adaaceb2889@haskell.org> Message-ID: <059.ff1fae35511eba800360fe5388f85053@haskell.org> #14278: undefined symbol: gsl_multiroot_fsolver_broyden -------------------------------+---------------------------------------- Reporter: smyds | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+---------------------------------------- Comment (by bgamari): What `libgsl2` version do you have installed? e.g., what does, {{{ dpkg -l libgsl2 }}} say? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14278#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 14:00:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 14:00:27 -0000 Subject: [GHC] #14275: Large Haskell value unexpectedly gets an unfolding In-Reply-To: <046.a11f64e5c2dcd96ac5a687edb56de84b@haskell.org> References: <046.a11f64e5c2dcd96ac5a687edb56de84b@haskell.org> Message-ID: <061.059abb8085f931102b111ba4a9872721@haskell.org> #14275: Large Haskell value unexpectedly gets an unfolding -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Inlining Operating System: 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): > Fine. It's exposed because we might see `case builtinRules of ...` somewhere. But we never do.. we just fold or map over it. Of course, I just wonder how often this sort of unfolding will really be useful in practice. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14275#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 14:05:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 14:05:14 -0000 Subject: [GHC] #14277: Missing release version number in <title> in the HTML User's Guide In-Reply-To: <045.66f6bb2c0ee6c79826c97c95ed6fa441@haskell.org> References: <045.66f6bb2c0ee6c79826c97c95ed6fa441@haskell.org> Message-ID: <060.ebb6adab7fcf456dc7a5b312d45d9f31@haskell.org> #14277: Missing release version number in <title> in the HTML User's Guide -------------------------------------+------------------------------------- Reporter: refold | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.2.2 Component: Documentation | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4033 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4033 * milestone: => 8.2.2 Comment: Thanks for mentioning this! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14277#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 14:06:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 14:06:25 -0000 Subject: [GHC] #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms In-Reply-To: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> References: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> Message-ID: <058.b0f98017ccbffe59d2a8003c859ab83a@haskell.org> #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_run/T14218 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"c41ccbfa8aaeb99dd9a36cb3d99993f0fa039cdc/ghc" c41ccbfa/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c41ccbfa8aaeb99dd9a36cb3d99993f0fa039cdc" Omit Typeable from the "naturally coherent" list In doing something else (Trac #14218) I tripped over the definition of "naturally coherent" classes. This patch - Cocuments properly what that means - Removes Typeable from the list, because now we know what it meams, Typeable clearly doesn't belong. No regressions. (Actually the term "naturally coherent" seems a bit off. More like "invertible" or something. But I left it.) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14218#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 14:07:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 14:07:42 -0000 Subject: [GHC] #14278: undefined symbol: gsl_multiroot_fsolver_broyden In-Reply-To: <044.9c13fc4e0594c7ae7edf5adaaceb2889@haskell.org> References: <044.9c13fc4e0594c7ae7edf5adaaceb2889@haskell.org> Message-ID: <059.493c1586840312308ea83afa39df4dc6@haskell.org> #14278: undefined symbol: gsl_multiroot_fsolver_broyden -------------------------------+---------------------------------------- Reporter: smyds | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+---------------------------------------- Comment (by smyds): 2.3 and 2.4 on the 2 machines {{{ $ dpkg -l libgsl2 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig- pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=========================-=================-=================-======================================================= ii libgsl2:i386 2.3+dfsg-1 i386 GNU Scientific Library (GSL) -- library package }}} {{{ $ dpkg -l libgsl2 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig- pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=========================-=================-=================-======================================================= ii libgsl2:amd64 2.4+dfsg-2 amd64 GNU Scientific Library (GSL) -- library package }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14278#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 14:07:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 14:07:50 -0000 Subject: [GHC] #14217: Interface-file decls for large tuples In-Reply-To: <047.bf95f3f7deae12cdefb07151e87149c3@haskell.org> References: <047.bf95f3f7deae12cdefb07151e87149c3@haskell.org> Message-ID: <062.cb5c98c042629be2475acc485d9236be@haskell.org> #14217: Interface-file decls for large tuples -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: Ah yes. I failed to mention the ticket, sorry. The commit is {{{ commit 3c74a51232813eb733b27c43c94ce005112a0ddb Author: Simon Peyton Jones <simonpj at microsoft.com> Date: Thu Sep 21 17:35:11 2017 +0100 Deal with large extra-contraints wildcards For reasons explained in TcHsType Note [Extra-constraint holes in partial type signatures], if we had f :: (_) => blahs and the '_' was filled in by more than a 62-tuple of contraints, GHC crashed. The same Note explains the hacky solution I have adopted to evade this. Maybe there is some better way, but I couldn't see one that didn't involve a great deal of work. And the problem is a very narrow one! If the hack bites us we'll need to think again. compiler/prelude/TysWiredIn.hs | 7 +- compiler/typecheck/TcBinds.hs | 18 ++-- compiler/typecheck/TcHsType.hs | 52 +++++++++++- compiler/typecheck/TcMType.hs | 7 +- .../tests/partial-sigs/should_compile/T14217.hs | 41 +++++++++ .../partial-sigs/should_compile/T14217.stderr | 99 ++++++++++++++++++++++ testsuite/tests/partial-sigs/should_compile/all.T | 1 + 7 files changed, 210 insertions(+), 15 deletions(-) }}} And yes we could merge it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14217#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 14:12:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 14:12:56 -0000 Subject: [GHC] #14162: Core Lint error In-Reply-To: <051.8e77500e96b9b78e4c6419516988ffa1@haskell.org> References: <051.8e77500e96b9b78e4c6419516988ffa1@haskell.org> Message-ID: <066.ddd890842cf2bc11bc894ca44aec75f0@haskell.org> #14162: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T14162 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as 8fda8aded0d2194bddbaaed43256d0e3d0632fe2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14162#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 14:14:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 14:14:07 -0000 Subject: [GHC] #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms In-Reply-To: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> References: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> Message-ID: <058.e67770fd8b9fee3801ba529860769aa2@haskell.org> #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_run/T14218 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * version: 8.2.1 => 8.0.1 * resolution: => fixed * milestone: 8.2.2 => 8.4.1 Comment: Given that this isn't really a regression I'm going to punt on this until 8.4. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14218#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 14:24:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 14:24:19 -0000 Subject: [GHC] #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal In-Reply-To: <042.d21b92eb840644cd16549869583bccd0@haskell.org> References: <042.d21b92eb840644cd16549869583bccd0@haskell.org> Message-ID: <057.a19706376c85c29650f01e0671a83200@haskell.org> #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14236 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > I have not yet figured out why we put a coercion variable in the template variables. Is "a coercion variable shall not appear as a template variable" an invariant of `Rule`? This wasn't clear to me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14270#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 14:27:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 14:27:52 -0000 Subject: [GHC] #12717: Permit data types in signatures to be implemented with equivalent pattern synonyms (and vice versa) In-Reply-To: <045.4ee09af1e0d9c93ce8dbfd1c44d905af@haskell.org> References: <045.4ee09af1e0d9c93ce8dbfd1c44d905af@haskell.org> Message-ID: <060.e73b39496684656a386c678d08e56238@haskell.org> #12717: Permit data types in signatures to be implemented with equivalent pattern synonyms (and vice versa) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 8.1 checker) | 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 ocharles): * cc: ocharles (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12717#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 14:34:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 14:34:06 -0000 Subject: [GHC] #14278: undefined symbol: gsl_multiroot_fsolver_broyden In-Reply-To: <044.9c13fc4e0594c7ae7edf5adaaceb2889@haskell.org> References: <044.9c13fc4e0594c7ae7edf5adaaceb2889@haskell.org> Message-ID: <059.468af2ce9795e752ff54ac15c5c15924@haskell.org> #14278: undefined symbol: gsl_multiroot_fsolver_broyden -------------------------------+---------------------------------------- Reporter: smyds | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+---------------------------------------- Comment (by bgamari): Hmm, odd. What does, {{{ objdump -T /usr/lib/x86_64-linux-gnu/libgsl.so | grep broyden }}} say? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14278#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 14:41:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 14:41:16 -0000 Subject: [GHC] #14278: undefined symbol: gsl_multiroot_fsolver_broyden In-Reply-To: <044.9c13fc4e0594c7ae7edf5adaaceb2889@haskell.org> References: <044.9c13fc4e0594c7ae7edf5adaaceb2889@haskell.org> Message-ID: <059.a6650144fa5640449fcca89a3ce5c050@haskell.org> #14278: undefined symbol: gsl_multiroot_fsolver_broyden -------------------------------+---------------------------------------- Reporter: smyds | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+---------------------------------------- Comment (by smyds): machine 1 (x86) : {{{ $ objdump -T /usr/lib/i386-linux-gnu/libgsl.so | grep broyden 00281738 g DO .data 00000004 Base gsl_multiroot_fsolver_broyden }}} machine 2 (x86_64) (libgsl.so doesn't exists here, only libgsl.so.19) : {{{ $ objdump -T /usr/lib/x86_64-linux-gnu/libgsl.so.19 | grep broyden 00000000004670e0 g DO .data 0000000000000008 Base gsl_multiroot_fsolver_broyden }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14278#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 14:45:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 14:45:38 -0000 Subject: [GHC] #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints In-Reply-To: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> References: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> Message-ID: <065.6df42a831d68520c7dbc48baf2ecb5a4@haskell.org> #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #9091, #9479 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It's easy to get confused here. First consider {{{ foo :: [a] -> String foo xs = show (_h ++ []) }}} We end up with this residual constraint {{{ forall a. [W] Show alpha [Hole] _h :: [alpha] }}} where `alpha` is a unification variable, standing for an as-yet-unknown type. The two unsolved constraints are * The `[Hole]` constraint feeds the error-report mechanism, reporting that `_h` must be filled vith a value of type `[alpha]`. * The `Show alpha` constraint arises from the call of `show`. Initially we'd get a `Show [alpha]` constraint, but we use the instance declaration `instance Show x => Show [x]` to reduce it to `Show alpha`. Now, what can we fill the hole with? Clearly something of form `[ty]`. But once we know what we fill it with, we can set `alpha := ty`, and then we want for the rest of the constraints to be soluble, in this case `Show alpha`. So filling with `[Int]` would be fine, but filling with `[Int -> Int]` would not. Filling with `[a]` would not work either, since we have no way to solve `Show a`. However, if the original definition had been {{{ foo :: Show a => [a] -> String foo xs = show (_h ++ []) }}} we'd end up with the residual constraint {{{ forall a. Show a => [W] Show alpha [Hole] _h :: [alpha] }}} then we ''could'' fill `_h` with `xs :: [a]`, because we now do have a `Show a` in scope from the type signature. TL;DR: the real question is this: * After filling the hole, can we solve the '''rest of the constraint'''? Sadly, that's not a very easy question to answer. * The current architecture focuses on the `[Hole]` constraint all by itself, but this example shows that it's really all about that constraint's peers. * There may be many unsolved constraints; filling one hole will not nail all of them, so we might erroneously reject a filler. For example {{{ [W] C alpha beta [Hole] _h1 :: alpha [Hole] _h2 :: beta }}} Here we'll never succeed in solving `C alpha beta` until we have simultaneously filled both holes with compatible types. * Operationally, constraint solving may perform unification. And unification is (currently) done by side-effect, and not easily undone. So trying successive candidates for hole-filling risks prematurely fixing the unification variables. In full generality this looks too hard. But I think you might be able to do a reasonable job for common cases. For example * Given a contraint {{{ forall as1. G1 => ... (forall as2. G2 => [Hole] _h :: ty C1, ..., Cn )... }}} pick the subset of Ci whose free unification variables are all mentioned in `ty`, say D1..Dm * Pick a candidate `cand :: cand_ty` to fill `_h`. * Clone any free unification variables * Try to solve the constraint {{{ forall as1. G1 => (forall as2. G2 => cand_ty <= ty -- subsumes D1, ..., Dm ) }}} This isn't perfect, but it'd work in common cases I think. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14273#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 14:47:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 14:47:48 -0000 Subject: [GHC] #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal In-Reply-To: <042.d21b92eb840644cd16549869583bccd0@haskell.org> References: <042.d21b92eb840644cd16549869583bccd0@haskell.org> Message-ID: <057.bc6558578bac33a30fc44bdd7feba064@haskell.org> #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14236 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Is "a coercion variable shall not appear as a template variable" an invariant of Rule? This wasn't clear to me. In effect, yes. Matching the LHS will never bind coercion variables (certainly not ones used in types), so they'd better not appear on the RHS. Boiling out a small test case would be jolly useful. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14270#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 15:51:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 15:51:04 -0000 Subject: [GHC] #13945: 'ghc-pkg update' fails due to bad file descriptor error In-Reply-To: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> References: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> Message-ID: <064.ad23b29dd734e492a8063626d9434ff7@haskell.org> #13945: 'ghc-pkg update' fails due to bad file descriptor error ---------------------------------+---------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3897 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): Thanks for the data point, j.waldmann. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13945#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 16:00:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 16:00:06 -0000 Subject: [GHC] #14123: Figure out invariants surrounding ticks in Core In-Reply-To: <046.0308c769b363c5285c5969fe8d556b65@haskell.org> References: <046.0308c769b363c5285c5969fe8d556b65@haskell.org> Message-ID: <061.7cfe5d4e10eaaf6733998de869b089dc@haskell.org> #14123: Figure out invariants surrounding ticks in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"6e7c09d083358b07401cbecc36043be5dfe15f84/ghc" 6e7c09d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6e7c09d083358b07401cbecc36043be5dfe15f84" StgCmmMonad: Remove unnecessary use of unboxed tuples The simplifier can simplify this without any trouble. Moreover, the unboxed tuples cause bootstrapping issues due #14123. I also went ahead and inlined a few definitions into the Monad instance. Test Plan: Validate Reviewers: austin, simonmar Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4026 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14123#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 16:00:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 16:00:06 -0000 Subject: [GHC] #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs In-Reply-To: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> References: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> Message-ID: <057.0b528b7e62aaae3d0b3fa7a146b9bd4e@haskell.org> #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: gdb, | debugging Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"1d1b991ee15e0428be16d1bfad7087051e000bdc/ghc" 1d1b991/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1d1b991ee15e0428be16d1bfad7087051e000bdc" rts: Inform kernel that we won't need reserved address space Trac #14192 points out that currently GHC's two-step allocator results in extremely large coredumps. It seems like WebKit may have encountered similar issues and their apparent solution uses madvise(MADV_DONTNEED) while reserving address space to inform the kernel that the address space we just requested needs no backing. Perhaps this is used by the core dump logic to trim out uncommitted pages. Test Plan: Validate, try core-dumping a compiled executable Reviewers: austin, erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #14192, #14193 Differential Revision: https://phabricator.haskell.org/D3929 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14192#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 16:00:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 16:00:06 -0000 Subject: [GHC] #14193: Add RTS flag to disable 1TB address space allocation In-Reply-To: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> References: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> Message-ID: <057.ad98eac7a11b577dd8b537d67eaaf953@haskell.org> #14193: Add RTS flag to disable 1TB address space allocation -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: feature request | 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: #9706, #14192 | Differential Rev(s): Phab:D3929 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"1d1b991ee15e0428be16d1bfad7087051e000bdc/ghc" 1d1b991/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1d1b991ee15e0428be16d1bfad7087051e000bdc" rts: Inform kernel that we won't need reserved address space Trac #14192 points out that currently GHC's two-step allocator results in extremely large coredumps. It seems like WebKit may have encountered similar issues and their apparent solution uses madvise(MADV_DONTNEED) while reserving address space to inform the kernel that the address space we just requested needs no backing. Perhaps this is used by the core dump logic to trim out uncommitted pages. Test Plan: Validate, try core-dumping a compiled executable Reviewers: austin, erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #14192, #14193 Differential Revision: https://phabricator.haskell.org/D3929 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14193#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 16:00:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 16:00:06 -0000 Subject: [GHC] #14272: GHC goes out of memory while compiling simple program with optimizations In-Reply-To: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> References: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> Message-ID: <062.e197a621b16de835225f841d4cd87838@haskell.org> #14272: GHC goes out of memory while compiling simple program with optimizations -------------------------------------+------------------------------------- Reporter: 39aldo39 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.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): Phab:D4021, Wiki Page: | Phab:D4025 -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"57372a7cc958ebfa4ac64fc800e00baacfc3cf5c/ghc" 57372a7c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="57372a7cc958ebfa4ac64fc800e00baacfc3cf5c" PrelRules: Handle Int left shifts of more than word-size bits This should result in zero. Failing to realize this caused us to try to constant-fold via the normal path, resulting in #14272. Test Plan: Validate with coming tests Reviewers: austin, simonpj Subscribers: simonpj, rwbarton, thomie, hvr GHC Trac Issues: #14272 Differential Revision: https://phabricator.haskell.org/D4025 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14272#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 16:01:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 16:01:02 -0000 Subject: [GHC] #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs In-Reply-To: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> References: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> Message-ID: <057.a2991f5907266099c8ba339d0ab0e477@haskell.org> #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: gdb, | debugging Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.4.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14192#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 16:01:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 16:01:51 -0000 Subject: [GHC] #14193: Add RTS flag to disable 1TB address space allocation In-Reply-To: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> References: <042.0f701b1bd80e0039a3bf2dfc7d251ace@haskell.org> Message-ID: <057.e13a27e5431c87d0c52be828c681ee53@haskell.org> #14193: Add RTS flag to disable 1TB address space allocation -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9706, #14192 | Differential Rev(s): Phab:D3929 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => wontfix Comment: I believe that comment:9 should remove the need for such a flag. Feel free to reopen if you disagree. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14193#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 16:02:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 16:02:53 -0000 Subject: [GHC] #14272: GHC goes out of memory while compiling simple program with optimizations In-Reply-To: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> References: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> Message-ID: <062.49c3d83e154262a312c1813b048b2204@haskell.org> #14272: GHC goes out of memory while compiling simple program with optimizations -------------------------------------+------------------------------------- Reporter: 39aldo39 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.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): Phab:D4021, Wiki Page: | Phab:D4025 -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"0ffa396d5421bc127759a62c2612920005423b15/ghc" 0ffa396d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0ffa396d5421bc127759a62c2612920005423b15" testsuite: Add test for #14272 Reviewers: austin Subscribers: rwbarton, thomie GHC Trac Issues: #14272 Differential Revision: https://phabricator.haskell.org/D4027 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14272#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 16:18:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 16:18:09 -0000 Subject: [GHC] #14277: Missing release version number in <title> in the HTML User's Guide In-Reply-To: <045.66f6bb2c0ee6c79826c97c95ed6fa441@haskell.org> References: <045.66f6bb2c0ee6c79826c97c95ed6fa441@haskell.org> Message-ID: <060.84bbb2a73fbd40c088fca3bc5d511a4f@haskell.org> #14277: Missing release version number in <title> in the HTML User's Guide -------------------------------------+------------------------------------- Reporter: refold | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Documentation | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4033 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: It turns out this was fixed by f58176fe731e0412a04239be620443d63f067adf. I'll cherry-pick to `ghc-8.2`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14277#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 16:31:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 16:31:34 -0000 Subject: [GHC] #14272: GHC goes out of memory while compiling simple program with optimizations In-Reply-To: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> References: <047.c7fa5589363d8d2fcc1e72894706e2a8@haskell.org> Message-ID: <062.db56357f8eba3141e8f39f4b8bfeb650@haskell.org> #14272: GHC goes out of memory while compiling simple program with optimizations -------------------------------------+------------------------------------- Reporter: 39aldo39 | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4021, Wiki Page: | Phab:D4025 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14272#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 16:32:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 16:32:03 -0000 Subject: [GHC] #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs In-Reply-To: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> References: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> Message-ID: <057.975f762c4319e56d8cceea9bf6ffb61a@haskell.org> #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.2 Resolution: fixed | Keywords: gdb, | debugging Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14192#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 16:53:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 16:53:06 -0000 Subject: [GHC] #13707: xmobar crashes with segmentation faults? In-Reply-To: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> References: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> Message-ID: <061.27cfe64b9a3129677e85cc305ee624dc@haskell.org> #13707: xmobar crashes with segmentation faults? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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): Sadly I can't get a backtrace out of the coredump even with the executable. However, the dump in comment:17 is quite interesting as it implicates the `Eq Module` instance in `GHC.Classes`. Unfortunately this is much different from the crash seen in comment:18. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13707#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 17:38:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 17:38:40 -0000 Subject: [GHC] #14237: -Wredundant-constraints incorrectly treats all type equality constraints as redundant In-Reply-To: <050.e3dc094564bbfbd54906e6f9a94f2531@haskell.org> References: <050.e3dc094564bbfbd54906e6f9a94f2531@haskell.org> Message-ID: <065.ddfc7ab2a65736cc133bef471d5813fa@haskell.org> #14237: -Wredundant-constraints incorrectly treats all type equality constraints as redundant -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #12700 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as 776a660a66404408a36b92cb84397815d283b6a5. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14237#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 17:39:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 17:39:07 -0000 Subject: [GHC] #14199: Document Type.Reflection better (Fun and Con') In-Reply-To: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> References: <045.f3425cc8ac570463ba966aec38f95556@haskell.org> Message-ID: <060.a02bc4ecdbeb701c0f9fa1beaf6a41e6@haskell.org> #14199: Document Type.Reflection better (Fun and Con') -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.2 Component: Core Libraries | Version: 8.2.1 Resolution: fixed | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3943, Wiki Page: | Phab:D3991 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` in 98f3bdd6af349bc020013335a1a9b17612d23115. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14199#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 17:39:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 17:39:34 -0000 Subject: [GHC] #14215: Coordinate re Cabal-2.0.0.3 or Cabal-2.0.1 release In-Reply-To: <042.f2da5496c03c753cd8a87d1fc1022cfc@haskell.org> References: <042.f2da5496c03c753cd8a87d1fc1022cfc@haskell.org> Message-ID: <057.7a3fac5d63cddc8ccfa72481fec1fab1@haskell.org> #14215: Coordinate re Cabal-2.0.0.3 or Cabal-2.0.1 release -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: task | Status: closed Priority: high | Milestone: 8.2.2 Component: libraries | Version: 8.2.1 (other) | 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: upstream => closed * resolution: => fixed Comment: Bumped `Cabal` submodule in `ghc-8.2` to c84a3c7219. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14215#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 17:40:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 17:40:12 -0000 Subject: [GHC] #14217: Interface-file decls for large tuples In-Reply-To: <047.bf95f3f7deae12cdefb07151e87149c3@haskell.org> References: <047.bf95f3f7deae12cdefb07151e87149c3@haskell.org> Message-ID: <062.248d0d26918851b377218e8410c57f5f@haskell.org> #14217: Interface-file decls for large tuples -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as 2e17259c57ff598ec87db545fb33702d86859462. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14217#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 17:55:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 17:55:34 -0000 Subject: [GHC] #14170: 8.2.1 regression: GHC fails to simplify `natVal` In-Reply-To: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> References: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> Message-ID: <063.408f63248c0657bd812bbd731038f104@haskell.org> #14170: 8.2.1 regression: GHC fails to simplify `natVal` -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm not really sure representing `Integer` and `Natural` is a great idea. Afterall, we then need to painstakingly evaluate all of the constant folding rules to ensure we don't, for instance, rewrite `(5 - 9) :: Natural` to `-4`. Moreover, distinguishing `Integer` `LitIntegers` from `Natural` `LitIntegers` on the basis of type alone would mean that `CorePrep` will need to do a type comparison in `cpeRhsE` instead of just deciding on the basis of which `Literal` constructor was used. In sum, I suspect `Integer` and `Natural` are just different enough to warrant separate constructors. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14170#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 18:13:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 18:13:35 -0000 Subject: [GHC] #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) In-Reply-To: <050.081284759fbb3264e065177f36714c06@haskell.org> References: <050.081284759fbb3264e065177f36714c06@haskell.org> Message-ID: <065.05cf00baf57eac62a9a14ac2522b6cfb@haskell.org> #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #3081 | Differential Rev(s): Phab:D4028 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thanks, Phyx-! If it's not too unreasonable, could we consider merging this into 8.2.2? It is a regression from 8.0.2, and moreover, it's one that bites fairly commonly (at least for me, anyways). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14150#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 18:24:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 18:24:20 -0000 Subject: [GHC] #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) In-Reply-To: <050.081284759fbb3264e065177f36714c06@haskell.org> References: <050.081284759fbb3264e065177f36714c06@haskell.org> Message-ID: <065.d7cc33cf6a9b11fe16500e0ce42b82b1@haskell.org> #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #3081 | Differential Rev(s): Phab:D4028 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I don't think it's very risky, so I don't see why not. But as always the last word is on @bgamari :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14150#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 18:42:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 18:42:47 -0000 Subject: [GHC] #14170: 8.2.1 regression: GHC fails to simplify `natVal` In-Reply-To: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> References: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> Message-ID: <063.11319aef0251067368f5c83acc33b163@haskell.org> #14170: 8.2.1 regression: GHC fails to simplify `natVal` -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.2 => 8.2.3 Comment: Regardless, it doesn't look like this is going to happen for 8.2.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14170#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 18:43:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 18:43:36 -0000 Subject: [GHC] #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) In-Reply-To: <050.081284759fbb3264e065177f36714c06@haskell.org> References: <050.081284759fbb3264e065177f36714c06@haskell.org> Message-ID: <065.c37ecd0f8be89cbd6dd8d3377e63da21@haskell.org> #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #3081 | Differential Rev(s): Phab:D4028 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina <tamar@…>): In [changeset:"3ec579d5d13dd00af58380a34daa2d57f0b9aa9e/ghc" 3ec579d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3ec579d5d13dd00af58380a34daa2d57f0b9aa9e" Release console for ghci wrapper Summary: It seems the call that caused issues with the gcc wrapper before was needed for the ghci wrapper in order for the child process to be the one handling console events. This code slightly refactors the wrappers to make sure only ghci calls FreeConsole and nothing else. Test Plan: ./validate , open ghci.exe press ctrl+c Reviewers: RyanGlScott, austin, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, erikd GHC Trac Issues: #14150 Differential Revision: https://phabricator.haskell.org/D4028 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14150#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 18:43:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 18:43:41 -0000 Subject: [GHC] #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 In-Reply-To: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> References: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> Message-ID: <061.bd7f24e54f468c85e637d2f873e47b77@haskell.org> #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.2 => 8.2.3 Comment: It doesn't look like this is going to happen for 8.2.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13745#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 18:44:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 18:44:19 -0000 Subject: [GHC] #14057: Upstream Alpine Linux distribution patches In-Reply-To: <046.942a17c3b70d9863c708d25f4b0f2dde@haskell.org> References: <046.942a17c3b70d9863c708d25f4b0f2dde@haskell.org> Message-ID: <061.f53bec8e3472f5100fabf5de460a374f@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: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * milestone: 8.2.2 => 8.2.3 Comment: It doesn't look like this is going to happen for 8.2.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14057#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 18:44:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 18:44:42 -0000 Subject: [GHC] #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL In-Reply-To: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> References: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> Message-ID: <061.822dd52c1ff667a322ef50a10c372d0e@haskell.org> #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13304 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.2 => 8.2.3 Comment: It doesn't look like this is going to happen for 8.2.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14021#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 18:44:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 18:44:58 -0000 Subject: [GHC] #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) In-Reply-To: <050.081284759fbb3264e065177f36714c06@haskell.org> References: <050.081284759fbb3264e065177f36714c06@haskell.org> Message-ID: <065.6e4efd1e14b3aa1c313529de122fb05d@haskell.org> #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #3081 | Differential Rev(s): Phab:D4028 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => merge Comment: how do you feel about merging this one back @bgamari? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14150#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 18:45:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 18:45:52 -0000 Subject: [GHC] #13604: ghci no longer loads dynamic .o files by default if they were built with -O In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.8af9147970e9c1ec62fb0809eda59cdd@haskell.org> #13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3514 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => dfeuer Comment: David is taking care of this one. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13604#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 18:46:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 18:46:31 -0000 Subject: [GHC] #13943: Compiler infinite loop with GHC-8.2 In-Reply-To: <048.054af5c39346b78fae836436fb73b68c@haskell.org> References: <048.054af5c39346b78fae836436fb73b68c@haskell.org> Message-ID: <063.d1b8af71fae4887a165ad54410ee9b7d@haskell.org> #13943: Compiler infinite loop with GHC-8.2 -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12791 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => dfeuer * milestone: 8.2.2 => 8.2.3 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13943#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 18:48:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 18:48:47 -0000 Subject: [GHC] #14278: undefined symbol: gsl_multiroot_fsolver_broyden In-Reply-To: <044.9c13fc4e0594c7ae7edf5adaaceb2889@haskell.org> References: <044.9c13fc4e0594c7ae7edf5adaaceb2889@haskell.org> Message-ID: <059.6e8a4561d530c8a30138ccfcc8bca2a9@haskell.org> #14278: undefined symbol: gsl_multiroot_fsolver_broyden -------------------------------+---------------------------------------- Reporter: smyds | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+---------------------------------------- Comment (by bgamari): Hmm, unfortunately I can't reproduce this locally. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14278#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 18:57:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 18:57:15 -0000 Subject: [GHC] #13873: Adding a SPECIALIZE at a callsite in Main.hs is causing a regression In-Reply-To: <048.468ab4797659afca428d5d90c27d98b1@haskell.org> References: <048.468ab4797659afca428d5d90c27d98b1@haskell.org> Message-ID: <063.141f55cfb3d0ed5444dcf91676559242@haskell.org> #13873: Adding a SPECIALIZE at a callsite in Main.hs is causing a regression -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Specialise Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.2 => 8.2.3 Comment: > If you have conflicting specialisations then the choice about which one applies is left up to the rule selection mechanism which I am not as familiar with. Unfortunately this pretty much means that the choice comes down to chance (e.g. which rule happens to fire first). Regardless, this won't be fixed for 8.2.2. Bumping to 8.2.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13873#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 18:58:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 18:58:56 -0000 Subject: [GHC] #14003: Allow more worker arguments in SpecConstr In-Reply-To: <048.309346fc5a64debb96097824f9daa7e2@haskell.org> References: <048.309346fc5a64debb96097824f9daa7e2@haskell.org> Message-ID: <063.63b539c79eeafd453a5c62deca0929e0@haskell.org> #14003: Allow more worker arguments in SpecConstr -------------------------------------+------------------------------------- Reporter: choenerzs | Owner: choenerzs Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints, | Fusion Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11565 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => choenerzs * milestone: 8.2.2 => 8.4.1 Comment: Any progress on this, choenerzs? Bumping off to 8.4.1 as there is a workaround for the regression (e.g. increase `-fmax-worker-args`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14003#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 18:59:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 18:59:30 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism In-Reply-To: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> References: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> Message-ID: <063.f827e8c4838b6a6e69f55a90255b01bc@haskell.org> #13929: GHC panic with levity polymorphism -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari Comment: I'll take care of the remaining case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13929#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 19:01:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 19:01:19 -0000 Subject: [GHC] #14054: Cabal generates ill-typed Paths module when relocatable In-Reply-To: <045.4319866d264e103497bc03abff674a19@haskell.org> References: <045.4319866d264e103497bc03abff674a19@haskell.org> Message-ID: <060.95011993352e88d711ed56d5df21da12@haskell.org> #14054: Cabal generates ill-typed Paths module when relocatable -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: upstream Priority: highest | Milestone: 8.2.2 Component: libraries | Version: 8.2.1 (other) | Resolution: | Keywords: Cabal Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => upstream * priority: high => highest Comment: Hmm, it's not clear what the status of this is upstream. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14054#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 19:02:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 19:02:22 -0000 Subject: [GHC] #13379: Space leak / quadratic behavior when inlining In-Reply-To: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> References: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> Message-ID: <063.d8e576db4e85d3bda12d69b6c8cedfdc@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compile/T13379 Blocked By: | Blocking: Related Tickets: #13586 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => dfeuer -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13379#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 19:03:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 19:03:00 -0000 Subject: [GHC] #11198: TypeInType error message regressions In-Reply-To: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> References: <047.10bc7f90bc6ecc2eebe9257004fabdc3@haskell.org> Message-ID: <062.968e71cdfab80e9c3bbd5d8d6699b8e9@haskell.org> #11198: TypeInType error message regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: TypeInType, Resolution: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/{T8262,T8603,tcfail122} Blocked By: | Blocking: Related Tickets: #11672 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.2 => 8.4.1 Comment: At this point I don't think this will make it for 8.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11198#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 19:05:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 19:05:08 -0000 Subject: [GHC] #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) In-Reply-To: <050.081284759fbb3264e065177f36714c06@haskell.org> References: <050.081284759fbb3264e065177f36714c06@haskell.org> Message-ID: <065.2a3f37a596a267fbf6329b7b73309c66@haskell.org> #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.2 Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #3081 | Differential Rev(s): Phab:D4028 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.2.2 Comment: Alright, we can do that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14150#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 19:19:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 19:19:55 -0000 Subject: [GHC] #13943: Compiler infinite loop with GHC-8.2 In-Reply-To: <048.054af5c39346b78fae836436fb73b68c@haskell.org> References: <048.054af5c39346b78fae836436fb73b68c@haskell.org> Message-ID: <063.4b744fbdf1455300e4ef42eac34fb87a@haskell.org> #13943: Compiler infinite loop with GHC-8.2 -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12791 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Simon PJ, do you think you should comment on where you want to go with this? I've suggested a short-term sort-of-fix above; is that what you want? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13943#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 19:39:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 19:39:42 -0000 Subject: [GHC] #12110: Windows exception handler change causes segfault with API Monitor In-Reply-To: <045.d4b936e5e562932ebd0d335c0535752d@haskell.org> References: <045.d4b936e5e562932ebd0d335c0535752d@haskell.org> Message-ID: <060.9584cfdada742353051ad1870a4ad76a@haskell.org> #12110: Windows exception handler change causes segfault with API Monitor -------------------------------------+------------------------------------- Reporter: enolan | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3911 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"1825cbdbdf08ed4bd6fd6794852596078953298a/ghc" 1825cbdb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1825cbdbdf08ed4bd6fd6794852596078953298a" Switch VEH to VCH and allow disabling of SEH completely. Exception handling on Windows is unfortunately a bit complicated. But essentially the VEH Handlers we currently have are running too early. This was a problem as it ran so early it also swallowed C++ exceptions and other software exceptions which the system could have very well recovered from. So instead we use a sequence of chains to for the exception handlers to run as late as possible. You really can't get any later than this. Please read the comment in the patch for more details. I'm also providing a switch to allow people to turn off the exception handling entirely. In case it does present a problem with their code. Test Plan: ./validate Reviewers: austin, hvr, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13911, #12110 Differential Revision: https://phabricator.haskell.org/D3911 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12110#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 19:39:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 19:39:42 -0000 Subject: [GHC] #13911: GHC RTS VEH swallowing exceptions In-Reply-To: <046.bb432e5d5c87d29e6119047e833a9165@haskell.org> References: <046.bb432e5d5c87d29e6119047e833a9165@haskell.org> Message-ID: <061.301e7529b75b48153c88abb8d0215398@haskell.org> #13911: GHC RTS VEH swallowing exceptions -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3911 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"1825cbdbdf08ed4bd6fd6794852596078953298a/ghc" 1825cbdb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1825cbdbdf08ed4bd6fd6794852596078953298a" Switch VEH to VCH and allow disabling of SEH completely. Exception handling on Windows is unfortunately a bit complicated. But essentially the VEH Handlers we currently have are running too early. This was a problem as it ran so early it also swallowed C++ exceptions and other software exceptions which the system could have very well recovered from. So instead we use a sequence of chains to for the exception handlers to run as late as possible. You really can't get any later than this. Please read the comment in the patch for more details. I'm also providing a switch to allow people to turn off the exception handling entirely. In case it does present a problem with their code. Test Plan: ./validate Reviewers: austin, hvr, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13911, #12110 Differential Revision: https://phabricator.haskell.org/D3911 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13911#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 20:00:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 20:00:26 -0000 Subject: [GHC] #14279: Type families interfere with specialisation rewrite rules Message-ID: <051.c770f0db94d1fbd7b1e66a5d39f244a4@haskell.org> #14279: Type families interfere with specialisation rewrite rules -------------------------------------+------------------------------------- Reporter: IvanTimokhin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the attached file, in particular the function {{{#!hs vinr :: Length as -> VSum bs -> VSum (as ++ bs) }}} its specialised version {{{#!hs vinr0 :: Length '[] -> VSum as -> VSum as }}} and the rewrite rule {{{#!hs {-# RULES "vinr/0" vinr = vinr0 #-} }}} According to [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#specialisation the relevant section of GHC user guide], `vinr` should be replaced with `vinr0` whenever the types match. However, the resulting Core for `test` contains the following (compiled with `ghc -O2`): {{{#!hs Test.test1 = case extractIdx @ 'Z @ '[Int] @ Int (Test.$WIZ @ Int @ '[]) Test.test2 of { Left other_aZf -> Test.$wvinl @ Length @ '[Int] @ (Remove 'Z '[Int]) other_aZf; Right x_aZg -> vinr @ (Remove 'Z '[Int]) @ '[Int] (Test.$WLZ `cast` ((Length (Sym (Test.D:R:Remove[0] <Int>_N <'[]>_N)))_R :: (Length '[] :: *) ~R# (Length (Remove 'Z '[Int]) :: *))) (Test.VInL @ '[Int] @ Int @ '[] @~ (<'[Int]>_N :: ('[Int] :: [*]) GHC.Prim.~# ('[Int] :: [*])) x_aZg) } }}} So the rule never fires, and `vinr` is still there, even though it is directly applied to `LZ :: Length '[]`. My dilettante analysis is that, for some reason, GHC keeps the `Remove 'Z '[Int]` as-is, not evaluating it to `'[]`, and, since the types don't match //syntactically//, doesn't apply the rule. In particular, if I replace type families with classes with functional dependencies, the rule fires as expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14279> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 20:01:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 20:01:55 -0000 Subject: [GHC] #14279: Type families interfere with specialisation rewrite rules In-Reply-To: <051.c770f0db94d1fbd7b1e66a5d39f244a4@haskell.org> References: <051.c770f0db94d1fbd7b1e66a5d39f244a4@haskell.org> Message-ID: <066.12d18c8aac54c365c4fafb789164a6ba@haskell.org> #14279: Type families interfere with specialisation rewrite rules -------------------------------------+------------------------------------- Reporter: IvanTimokhin | 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by IvanTimokhin): * Attachment "test.hs" added. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14279> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 21:44:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 21:44:03 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism In-Reply-To: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> References: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> Message-ID: <063.587296e76b5314ccb9a0d2004062d6d6@haskell.org> #13929: GHC panic with levity polymorphism -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"018c40fb1bb27853d0cefa5b90a44ce13e91a856/ghc" 018c40fb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="018c40fb1bb27853d0cefa5b90a44ce13e91a856" desugar: Catch levity polymorphism in unboxed sum expressions Fixes #13929. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13929#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 21:44:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 21:44:03 -0000 Subject: [GHC] #13911: GHC RTS VEH swallowing exceptions In-Reply-To: <046.bb432e5d5c87d29e6119047e833a9165@haskell.org> References: <046.bb432e5d5c87d29e6119047e833a9165@haskell.org> Message-ID: <061.d3da0620003d5189daf873d6d2711954@haskell.org> #13911: GHC RTS VEH swallowing exceptions -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3911 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"1421d87c8aabd7b1934f60bef688939882c8251c/ghc" 1421d87/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1421d87c8aabd7b1934f60bef688939882c8251c" Switch VEH to VCH and allow disabling of SEH completely. Exception handling on Windows is unfortunately a bit complicated. But essentially the VEH Handlers we currently have are running too early. This was a problem as it ran so early it also swallowed C++ exceptions and other software exceptions which the system could have very well recovered from. So instead we use a sequence of chains to for the exception handlers to run as late as possible. You really can't get any later than this. Please read the comment in the patch for more details. I'm also providing a switch to allow people to turn off the exception handling entirely. In case it does present a problem with their code. (Reverted and recommitted to fix authorship information) Test Plan: ./validate Reviewers: austin, hvr, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13911, #12110 Differential Revision: https://phabricator.haskell.org/D3911 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13911#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 21:44:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 21:44:03 -0000 Subject: [GHC] #12110: Windows exception handler change causes segfault with API Monitor In-Reply-To: <045.d4b936e5e562932ebd0d335c0535752d@haskell.org> References: <045.d4b936e5e562932ebd0d335c0535752d@haskell.org> Message-ID: <060.b00a5160e06cc167464ef25b52eb1898@haskell.org> #12110: Windows exception handler change causes segfault with API Monitor -------------------------------------+------------------------------------- Reporter: enolan | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3911 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"1421d87c8aabd7b1934f60bef688939882c8251c/ghc" 1421d87/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1421d87c8aabd7b1934f60bef688939882c8251c" Switch VEH to VCH and allow disabling of SEH completely. Exception handling on Windows is unfortunately a bit complicated. But essentially the VEH Handlers we currently have are running too early. This was a problem as it ran so early it also swallowed C++ exceptions and other software exceptions which the system could have very well recovered from. So instead we use a sequence of chains to for the exception handlers to run as late as possible. You really can't get any later than this. Please read the comment in the patch for more details. I'm also providing a switch to allow people to turn off the exception handling entirely. In case it does present a problem with their code. (Reverted and recommitted to fix authorship information) Test Plan: ./validate Reviewers: austin, hvr, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13911, #12110 Differential Revision: https://phabricator.haskell.org/D3911 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12110#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 21:44:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 21:44:21 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism In-Reply-To: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> References: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> Message-ID: <063.f49a4437709fe9478f35ba4adf47da4e@haskell.org> #13929: GHC panic with levity polymorphism -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: bgamari Type: bug | Status: merge Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13929#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 21:44:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 21:44:34 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism In-Reply-To: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> References: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> Message-ID: <063.e863472bcd571d0294dc3f02fbb6a988@haskell.org> #13929: GHC panic with levity polymorphism -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: bgamari Type: bug | Status: merge Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ypecheck/should_fail/T13929 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => ypecheck/should_fail/T13929 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13929#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 21:45:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 21:45:50 -0000 Subject: [GHC] #12110: Windows exception handler change causes segfault with API Monitor In-Reply-To: <045.d4b936e5e562932ebd0d335c0535752d@haskell.org> References: <045.d4b936e5e562932ebd0d335c0535752d@haskell.org> Message-ID: <060.bdc76c2ea1079e5d1c362614c5dc87ca@haskell.org> #12110: Windows exception handler change causes segfault with API Monitor -------------------------------------+------------------------------------- Reporter: enolan | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3911 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: The double-commit was to fix erroneous authorship information. Sorry for the noise. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12110#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 21:46:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 21:46:08 -0000 Subject: [GHC] #13911: GHC RTS VEH swallowing exceptions In-Reply-To: <046.bb432e5d5c87d29e6119047e833a9165@haskell.org> References: <046.bb432e5d5c87d29e6119047e833a9165@haskell.org> Message-ID: <061.e3d7848bd6121195cb3d8a6d54c5a8cb@haskell.org> #13911: GHC RTS VEH swallowing exceptions -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3911 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: The double-commit was to fix erroneous authorship information. Sorry for the noise. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13911#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 22:30:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 22:30:09 -0000 Subject: [GHC] #14280: Aarch64 build is broken Message-ID: <046.08b94a5c2943170ec3f3a9caa0180ab0@haskell.org> #14280: Aarch64 build is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: aarch64 | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Trying to bootstrap 7446c7f68bd5addd2f2db0d8d5910fb963869c47 on an aarch64 (Debian 8, LLVM 5) box results in a reproducibly segfaulting `ghc-stage2`, {{{ (gdb) run Starting program: /mnt/ext/arm/ghc/inplace/lib/bin/ghc-stage2 -B/mnt/ext/arm/ghc/inplace/lib -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packages -i -iutils/check-ppr/. -iutils/check-ppr/dist-install/build -Iutils/check-ppr/dist-install/build -iutils/check-ppr/dist-install/build/check-ppr/autogen -Iutils/check-ppr /dist-install/build/check-ppr/autogen -optP-include -optPutils/check-ppr /dist-install/build/check-ppr/autogen/cabal_macros.h -package-id base-4.11.0.0 -package-id bytestring-0.10.8.2 -package-id containers-0.5.10.2 -package-id Cabal-2.0.0.2 -package-id directory-1.3.1.2 -package-id filepath-1.4.1.2 -package-id ghc-8.3 -Wall -XHaskell2010 -no-user-package- db -rtsopts -Wnoncanonical-monad-instances -odir utils/check-ppr/dist- install/build -hidir utils/check-ppr/dist-install/build -stubdir utils /check-ppr/dist-install/build -c utils/check-ppr/./Main.hs -o utils/check- ppr/dist-install/build/Main.dyn_o [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/aarch64-linux- gnu/libthread_db.so.1". [New Thread 0x3fafaff200 (LWP 29429)] Thread 1 "ghc-stage2" received signal SIGSEGV, Segmentation fault. 0x00000000005aa360 in stg_IND_STATIC_info () (gdb) bt #0 0x00000000005aa360 in stg_IND_STATIC_info () #1 0x0000007fb11b3450 in ccib_info$def () from /mnt/ext/arm/ghc/libraries/base/dist- install/build/libHSbase-4.11.0.0-ghc8.3.20170926.so Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14280> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 22:36:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 22:36:21 -0000 Subject: [GHC] #14280: Aarch64 build is broken In-Reply-To: <046.08b94a5c2943170ec3f3a9caa0180ab0@haskell.org> References: <046.08b94a5c2943170ec3f3a9caa0180ab0@haskell.org> Message-ID: <061.b8d45caad3988a2d42596c467acbc0cf@haskell.org> #14280: Aarch64 build is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | 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 suspect this is due to a linker bug since I noticed that for some reason `configure` didn't find `ld.gold` (and therefore I'm using `ld.bfd`, which I generally assume to be broken). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14280#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 22:37:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 22:37:37 -0000 Subject: [GHC] #14280: Aarch64 build is broken In-Reply-To: <046.08b94a5c2943170ec3f3a9caa0180ab0@haskell.org> References: <046.08b94a5c2943170ec3f3a9caa0180ab0@haskell.org> Message-ID: <061.f43b7dee00f8204e63a923716f93893a@haskell.org> #14280: Aarch64 build is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | 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): Indeed modifying `settings` and `make -Cghc re2`ing seems to fix the issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14280#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Sep 26 22:40:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Sep 2017 22:40:00 -0000 Subject: [GHC] #14280: Aarch64 build is broken In-Reply-To: <046.08b94a5c2943170ec3f3a9caa0180ab0@haskell.org> References: <046.08b94a5c2943170ec3f3a9caa0180ab0@haskell.org> Message-ID: <061.8cb4a1fb7176c5890031d94c5aec4363@haskell.org> #14280: Aarch64 build is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | 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): Ahh, I see what happened. I had `ld.lld` installed but `gcc` doesn't support `-fuse-ld=lld`, consequently it never tried `ld.gold.` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14280#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 00:11:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 00:11:26 -0000 Subject: [GHC] #12502: Reject wrong find utility In-Reply-To: <044.bf466ae198a25fe9a5df2ca0f70bd734@haskell.org> References: <044.bf466ae198a25fe9a5df2ca0f70bd734@haskell.org> Message-ID: <059.d5d74d0082f3488fb89e295c188effd5@haskell.org> #12502: Reject wrong find utility -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3907 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12502#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 02:40:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 02:40:22 -0000 Subject: [GHC] #13897: Ship check-ppr in bindist and compile during testsuite run In-Reply-To: <046.c1d9498de95e82cc15e6c9fd657e4d84@haskell.org> References: <046.c1d9498de95e82cc15e6c9fd657e4d84@haskell.org> Message-ID: <061.44529ea0a5c7c2b4ab235e8233cafcc3@haskell.org> #13897: Ship check-ppr in bindist and compile during testsuite run -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alanz Type: task | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Phab:D4039 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4039 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13897#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 02:59:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 02:59:19 -0000 Subject: [GHC] #10803: New SignatureSections extension In-Reply-To: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> References: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> Message-ID: <057.0740d397a3262ab2d299132ebbb5e9fb@haskell.org> #10803: New SignatureSections extension -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1185 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 Comment: It seems pretty unlikely that this will happen for 8.6 and `TypeApplications` removes some of the need. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10803#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 02:59:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 02:59:50 -0000 Subject: [GHC] #10915: Statistical profiling support in the RTS In-Reply-To: <046.7220ccda33e87c4faaaf43cf13abd1b6@haskell.org> References: <046.7220ccda33e87c4faaaf43cf13abd1b6@haskell.org> Message-ID: <061.e4aa77cb0d1510a9c9c2877b4659ef54@haskell.org> #10915: Statistical profiling support in the RTS -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1215, Wiki Page: | Phab:D1214 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 Comment: This won't happen for 8.4.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10915#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 03:39:06 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 03:39:06 -0000 Subject: [GHC] #13929: GHC panic with levity polymorphism In-Reply-To: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> References: <048.5c2ae38f85d6f5524dac111d353c893e@haskell.org> Message-ID: <063.0e11a66b3842e5b5e8640a5f21c48008@haskell.org> #13929: GHC panic with levity polymorphism -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc2 Resolution: fixed | Keywords: TypeInType, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13929 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * testcase: ypecheck/should_fail/T13929 => typecheck/should_fail/T13929 * resolution: => fixed Comment: All patches listed above merged to `ghc-8.2` as of 78e673910f8759f643b263c70ad5c8fffd11a55d. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13929#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 03:39:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 03:39:43 -0000 Subject: [GHC] #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) In-Reply-To: <050.081284759fbb3264e065177f36714c06@haskell.org> References: <050.081284759fbb3264e065177f36714c06@haskell.org> Message-ID: <065.99ca7382fa89d565a54807bd54fef193@haskell.org> #14150: Ctrl+C causes GHCi 8.2.1 to "exit" in Windows (which didn't happen in 8.0.2) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: GHCi | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #3081 | Differential Rev(s): Phab:D4028 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.2` in f837db7e1cb23efca86f9804b5aa9503ae765c57. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14150#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 04:05:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 04:05:31 -0000 Subject: [GHC] #14281: Minor regressions from removal of non-linear behavior from simplifier Message-ID: <045.d32d282d1f3f5fafee99c0bd5e54dfb6@haskell.org> #14281: Minor regressions from removal of non-linear behavior from simplifier -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #13397 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- #13379 exposed non-linear behavior simplifying certain nested function applications. Simon PJ fixed that in a1b753e8b1475659440f524b3e66dfbea31c5787, and then made an adjustment in 29d88ee173bc9b04245a33d5268dda032f5dc331. Gipeda revealed a couple of small regressions from this combination (I'm not sure which did what, but IIRC the second patch mostly fixed regressions in the first). {{{ nofib/time/cryptarithm1 time increases 4.87% from 0.513s to 0.538s nofib/size/scs code size increases 5.28% from 1224890 bytes to 1289570 bytes }}} Note that there are a few comments on #13397 relating to these regressions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14281> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 04:06:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 04:06:35 -0000 Subject: [GHC] #13379: Space leak / quadratic behavior when inlining In-Reply-To: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> References: <048.3a3cc2c8142cd380727a72eb402237bb@haskell.org> Message-ID: <063.49eed59cb05a255b5b8d53f66409c442@haskell.org> #13379: Space leak / quadratic behavior when inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: dfeuer Type: bug | Status: closed Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compile/T13379 Blocked By: | Blocking: Related Tickets: #13586, #14281 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => fixed * related: #13586 => #13586, #14281 Comment: As requested, I've opened #14281 for the regressions and am closing this ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13379#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 04:54:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 04:54:25 -0000 Subject: [GHC] #14282: tagToEnum# . dataToTag# not optimized away Message-ID: <045.5438ce0b3dc299cc3f08e924d6abe37c@haskell.org> #14282: tagToEnum# . dataToTag# not optimized away -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: datacon-tags | 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 {{{#!hs foo :: Int# -> Int# foo x = dataToTag# (tagToEnum# x :: Bool) bar :: Bool -> Bool bar x = tagToEnum# (dataToTag# x) }}} These are both effectively identity functions. But while `foo` simplifies to one, `bar` does not! We might want to fix that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14282> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 05:22:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 05:22:32 -0000 Subject: [GHC] #14283: Remove the special case for tagToEnum# in the code generator? Message-ID: <045.8ba2def23565b96372814e1341ba709b@haskell.org> #14283: Remove the special case for tagToEnum# in the code generator? -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The only remaining primop (aside from `unsafeCoerce#` and `seq`) that produces an enumeration type is `tagToEnum#`. There is some magic in the code generator to make garbage collection relating to this work as it has historically. We want to get rid of the special case. Simply removing it altogether actually does seem to work, but the code we generate likely isn't quite the same. The challenge here is that (despite what I thought earlier) we definitely ''can'' end up in code generation, under certain circumstances, with {{{#!hs case tagToEnum# @t x of ... }}} How does this happen? After all, in `caseRules` we carefully remove every case on `tagToEnum#` and `dataToTag#` applications! The trouble comes when CorePrep puts everything in A-normal form. Strict function applications are transformed into `case` forms, so {{{#!hs f (tagToEnum# x) }}} will become {{{#!hs case tagToEnum# x of y DEFAULT -> f y }}} Suddenly we have that ugly case! Hmph. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14283> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 05:37:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 05:37:51 -0000 Subject: [GHC] #14283: Remove the special case for tagToEnum# in the code generator? In-Reply-To: <045.8ba2def23565b96372814e1341ba709b@haskell.org> References: <045.8ba2def23565b96372814e1341ba709b@haskell.org> Message-ID: <060.506d20d3dfedc533c02557057e9085b1@haskell.org> #14283: Remove the special case for tagToEnum# in the code generator? -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.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: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > The only remaining primop (aside from `unsafeCoerce#` and `seq`) that > produces an enumeration type is `tagToEnum#`. There is some magic in the > code generator to make garbage collection relating to this work as it has > historically. We want to get rid of the special case. Simply removing it > altogether actually does seem to work, but the code we generate likely > isn't quite the same. The challenge here is that (despite what I thought > earlier) we definitely ''can'' end up in code generation, under certain > circumstances, with > > {{{#!hs > case tagToEnum# @t x of > ... > }}} > > How does this happen? After all, in `caseRules` we carefully remove every > case on `tagToEnum#` and `dataToTag#` applications! The trouble comes > when CorePrep puts everything in A-normal form. Strict function > applications are transformed into `case` forms, so > > {{{#!hs > f (tagToEnum# x) > }}} > > will become > > {{{#!hs > case tagToEnum# x of y > DEFAULT -> f y > }}} > > Suddenly we have that ugly case! Hmph. New description: The only remaining primop (aside from `unsafeCoerce#` and `seq`) that produces an enumeration type is `tagToEnum#`. There is some magic in the code generator to make garbage collection relating to this work as it has historically. We want to get rid of the special case. Simply removing it altogether actually does seem to work (in that CI doesn't complain, see Phab:D3980, although I don't yet know why), but the code we generate likely isn't quite the same. The challenge here is that (despite what I thought earlier) we definitely ''can'' end up in code generation, under certain circumstances, with {{{#!hs case tagToEnum# @t x of ... }}} How does this happen? After all, in `caseRules` we carefully remove every case on `tagToEnum#` and `dataToTag#` applications! The trouble comes when CorePrep puts everything in A-normal form. Strict function applications are transformed into `case` forms, so {{{#!hs f (tagToEnum# x) }}} will become {{{#!hs case tagToEnum# x of y DEFAULT -> f y }}} Suddenly we have that ugly case! Hmph. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14283#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 07:33:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 07:33:23 -0000 Subject: [GHC] #7169: Warning for incomplete record field label used as function In-Reply-To: <047.31629c8fe32b813e38c132e8d4305995@haskell.org> References: <047.31629c8fe32b813e38c132e8d4305995@haskell.org> Message-ID: <062.eae5006f4db4c9117480da21f50ca05d@haskell.org> #7169: Warning for incomplete record field label used as function -------------------------------------+------------------------------------- Reporter: goldfire | Owner: nakaji_dayo Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Warnings, | newcomer 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 mgsloan): I think addressing this is important, otherwise it can be easy for people to write code that throws exceptions, without realizing it. I don't like the name `-Wpartial-records`, the name could be construed to refer to things like `-Wmissing-fields` and `-Wincomplete-record-updates`, other examples of partiality in records. Perhaps call it `-Wpartial- fields`? I think it also makes sense to have an option to emit warnings for partial record fields. Perhaps call it `-Wpartial-field-usages`? The reason this is helpful is that some libraries may export partial fields. It's still helpful as a sanity check for users of a library to have this as an optional warning. From what I can tell, modern Haskell best practice is to eschew partial field declarations, so I think it makes sense to include `-Wpartial- fields` in `-Wall`, but not `-Wpartial-field-usages`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7169#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 07:49:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 07:49:14 -0000 Subject: [GHC] #14284: -Weverything is undocumented Message-ID: <045.9f4cfb2606fbf67e7f4d80b618b36bf9@haskell.org> #14284: -Weverything is undocumented -------------------------------------+------------------------------------- Reporter: refold | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since version 8.0.1, GHC apparently has a `-Weverything` flag (see https://phabricator.haskell.org/D1850), but it doesn't seem to be documented either on the flag reference page or anywhere in the manual: * https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flags.html * https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using- warnings.html#options-sanity -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14284> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 09:00:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 09:00:53 -0000 Subject: [GHC] #14285: Entered absent arg - triggered by INLINEABLE, regression from 8.0.2 Message-ID: <049.09fbd6d1ad4f0a97bcd76579dd68ae8a@haskell.org> #14285: Entered absent arg - triggered by INLINEABLE, regression from 8.0.2 --------------------------------------+--------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: --------------------------------------+--------------------------------- Steps to reproduce: {{{ git clone https://gitlab.imn.htwk-leipzig.de/waldmann/pure-matchbox git checkout a2005d246cb7bd77a33bf4c09419534bc7ecd435 stack build .stack-work/install/x86_64-linux/nightly-2017-09-26/8.2.1/bin/pure- matchbox -i -w Count data/z001.srs }}} Output: {{{ pure-matchbox: Oops! Entered absent arg ww Map k (Set k1) }}} Error goes away when compiling with -O0, or when removing this pragma in src/Matchbox/Pairs.hs {{{ 52 {-# INLINEABLE pre_images #-} 53 pre_images x rel = images x $ mirrorRel rel }}} (normal output starts with YES on a single line) Error also goes away when building with 8.0.2 {{{ PATH=/where/you/have/installed/ghc-8.0.2/bin:$PATH stack build --resolver=lts-9.6 }}} I tried to isolate a shorter test case but gave up after some hours. Is there some automation for this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14285> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 09:17:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 09:17:36 -0000 Subject: [GHC] #14285: Entered absent arg - triggered by INLINEABLE, regression from 8.0.2 In-Reply-To: <049.09fbd6d1ad4f0a97bcd76579dd68ae8a@haskell.org> References: <049.09fbd6d1ad4f0a97bcd76579dd68ae8a@haskell.org> Message-ID: <064.d63fc5c7038c8cd74445008d5f057dbd@haskell.org> #14285: Entered absent arg - triggered by INLINEABLE, regression from 8.0.2 ---------------------------------+-------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by mpickering): Does `-dcore-lint` report an error? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14285#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 09:50:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 09:50:22 -0000 Subject: [GHC] #14285: Entered absent arg - triggered by INLINEABLE, regression from 8.0.2 In-Reply-To: <049.09fbd6d1ad4f0a97bcd76579dd68ae8a@haskell.org> References: <049.09fbd6d1ad4f0a97bcd76579dd68ae8a@haskell.org> Message-ID: <064.94e5d78ee4ecca29665c108ea0e3f2a2@haskell.org> #14285: Entered absent arg - triggered by INLINEABLE, regression from 8.0.2 ---------------------------------+-------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by j.waldmann): No. - After a clean checkout, I did {{{ stack build --dependencies-only stack exec -- ghc -isrc -fforce-recomp -O1 -dcore-lint pure-matchbox.hs ./pure-matchbox -i -w Count data/z001.srs pure-matchbox: Oops! Entered absent arg ww Map k (Set k1) }}} If I leave out the "-O1", or if I put "-O0", the error does not happen. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14285#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 10:44:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 10:44:18 -0000 Subject: [GHC] #14286: Different behavior between type application and type annotation. Message-ID: <048.9aa6f7e8cc1451e9e689f1b745a22fdb@haskell.org> #14286: Different behavior between type application and type annotation. -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this code: {{{#!hs {-# LANGUAGE FlexibleInstances, TypeApplications #-} module Bug where class Foo t where foo_ :: (IO () -> IO ()) -> t instance (Show a, Foo t) => Foo (a -> t) where foo_ k a = foo_ (\continue -> k (print a >> continue)) instance Foo (IO ()) where foo_ k = k (return ()) foo :: Foo t => t foo = foo_ id bar = foo () (Just "bar") [()] :: IO () baz = foo @(IO ()) () (Just "baz") [()] }}} `bar` is accepted by GHC while `baz` is rejected: {{{ * Couldn't match expected type `() -> Maybe [Char] -> [()] -> t' with actual type `IO ()' * The function `foo' is applied to four arguments, but its type `IO ()' has none In the expression: foo @(IO ()) () (Just "baz") [()] In an equation for `baz': baz = foo @(IO ()) () (Just "baz") [()] * Relevant bindings include baz :: t (bound at bug.hs:19:1) | 19 | baz = foo @(IO ()) () (Just "baz") [()] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Why so? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14286> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 10:59:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 10:59:43 -0000 Subject: [GHC] #14284: -Weverything is undocumented In-Reply-To: <045.9f4cfb2606fbf67e7f4d80b618b36bf9@haskell.org> References: <045.9f4cfb2606fbf67e7f4d80b618b36bf9@haskell.org> Message-ID: <060.b5a93c5918d8223f9a495ff4a1291071@haskell.org> #14284: -Weverything is undocumented -------------------------------------+------------------------------------- Reporter: refold | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: hvr (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14284#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 11:17:38 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 11:17:38 -0000 Subject: [GHC] #14286: Different behavior between type application and type annotation. In-Reply-To: <048.9aa6f7e8cc1451e9e689f1b745a22fdb@haskell.org> References: <048.9aa6f7e8cc1451e9e689f1b745a22fdb@haskell.org> Message-ID: <063.cf283036dfa212a67f6fc4b28314a9f7@haskell.org> #14286: Different behavior between type application and type annotation. -------------------------------------+------------------------------------- Reporter: vagarenko | 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 goldfire): The type you're passing to `foo` instantiates `t`. I think you want {{{#!hs baz = foo @(() -> Maybe String -> [()] -> IO ()) () (Just "baz") [()] }}} which works for me. Please close if you agree. Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14286#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 11:28:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 11:28:30 -0000 Subject: [GHC] #14286: Different behavior between type application and type annotation. In-Reply-To: <048.9aa6f7e8cc1451e9e689f1b745a22fdb@haskell.org> References: <048.9aa6f7e8cc1451e9e689f1b745a22fdb@haskell.org> Message-ID: <063.8b6feb427da391b1e813ecb24fcce72b@haskell.org> #14286: Different behavior between type application and type annotation. -------------------------------------+------------------------------------- Reporter: vagarenko | 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 vagarenko): Silly me. Of course `foo () (Just "bar") [()] :: IO ()` means type of `foo` applied to 3 arguments is `IO ()` while `foo @(IO ())` means `foo` has no arguments. Sorry for the noise. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14286#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 11:28:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 11:28:41 -0000 Subject: [GHC] #14286: Different behavior between type application and type annotation. In-Reply-To: <048.9aa6f7e8cc1451e9e689f1b745a22fdb@haskell.org> References: <048.9aa6f7e8cc1451e9e689f1b745a22fdb@haskell.org> Message-ID: <063.c9d3bc61c7ecfdf3747ec9501e3116b5@haskell.org> #14286: Different behavior between type application and type annotation. -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 vagarenko): * status: new => closed * resolution: => invalid -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14286#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 12:03:09 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 12:03:09 -0000 Subject: [GHC] #14287: Early inlining causes potential join points to be missed Message-ID: <044.afeda1d17d7fca2451446457f502779c@haskell.org> #14287: Early inlining causes potential join points to be missed -------------------------------------+------------------------------------- Reporter: jheek | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While trying to make stream fusion work with recursive step functions I noticed that the following filter implementation did not fuse nicely. {{{#!haskell data Stream s a = Stream (s -> Step s a) s data Step s a = Done | Yield a s sfilter :: (a -> Bool) -> Stream s a -> Stream s a sfilter pred (Stream step s0) = Stream filterStep s0 where filterStep s = case step s of Done -> Done Yield x ns | pred x -> Yield x ns | otherwise -> filterStep ns fromTo :: Int -> Int -> Stream Int Int {-# INLINE fromTo #-} fromTo from to = Stream step from where step i | i > to = Done | otherwise = Yield i (i + 1) sfoldl :: (b -> a -> b) -> b -> Stream s a -> b {-# INLINE sfoldl #-} sfoldl acc z (Stream !step s0) = oneShot go z s0 where go !y s = case step s of Done -> y Yield x ns -> go (acc y x) ns ssum :: (Num a) => Stream s a -> a ssum = sfoldl (+) 0 filterTest :: Int filterTest = ssum $ sfilter even (fromTo 1 101) }}} For this code to work nicely, GHC should detect that filterStep is a join point. However, in the definition of sfilter it is not because not all references are tail-called & saturated. After inlining of sfilter and some trivial case-of-case transformations filterStep should become a join point. But it seems like the simplifier never gets the change to do this because float-out optimization makes filterStep a top level binding. With -fno-full-laziness filterStep does become a join point at the call site, but of course this is not really a solution. Then I found that the following also works: {{{#!haskell sfilter :: (a -> Bool) -> Stream s a -> Stream s a sfilter pred (Stream step s0) = Stream filterStep s0 where {-# INLINE [2] filterStep #-} filterStep s = case step s of Done -> Done Yield x ns | pred x -> Yield x ns | otherwise -> filterStep ns }}} Simply adding an INLINE [2] pragma disables the inlining in the early run of the simplifier. Therefore, the float out pass does not get the change to float-out before the filterStep is recognized as a joint point. Or at least that is my interpretation of what is going on. What surprises me about this issue is that the gentle run seems to perform inlining while the wiki mentions that inlining is not performed in this stage: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Core2CorePipeline Intuitively, I would think that floating-out is sub-optimal when the simplifier did not use all its tricks yet, because inlining typically opens up possibilities for simplification while floating-out typically reducing these possibilities. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14287> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 12:06:07 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 12:06:07 -0000 Subject: [GHC] #14288: ScopedTypeVariables with nexted foralls broken since 8.0.2 Message-ID: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> #14288: ScopedTypeVariables with nexted foralls broken since 8.0.2 -------------------------------------+------------------------------------- Reporter: | Owner: (none) MikolajKonarski | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following example fails in 8.2.1 and 8.0.2. Works fine in 7.10.3. If that's intended (that only the first forall has extended scope), I didn't find any mention of that in GHC manual. The two commented out variants work fine in all. {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} main :: IO () main = do -- let f :: forall a ref. ref () -> () -- let f :: forall ref. forall a. ref () -> () let f :: forall a. forall ref. ref () -> () f x = let r :: ref () r = x in () return $ f (Just ()) }}} The error (the same in 8.2.1 and 8.0.2) is: {{{#!hs $ ghc --make forall.hs [1 of 1] Compiling Main ( forall.hs, forall.o ) forall.hs:8:21: error: • Couldn't match type ‘ref’ with ‘ref1’ ‘ref’ is a rigid type variable bound by the type signature for: f :: forall a (ref :: * -> *). ref () -> () at forall.hs:6:29 ‘ref1’ is a rigid type variable bound by the type signature for: r :: forall (ref1 :: * -> *). ref1 () at forall.hs:7:22 Expected type: ref1 () Actual type: ref () • In the expression: x In an equation for ‘r’: r = x In the expression: let r :: ref () r = x in () • Relevant bindings include r :: ref1 () (bound at forall.hs:8:17) x :: ref () (bound at forall.hs:7:9) f :: ref () -> () (bound at forall.hs:7:7) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14288> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 12:08:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 12:08:51 -0000 Subject: [GHC] #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 (was: ScopedTypeVariables with nexted foralls broken since 8.0.2) In-Reply-To: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> References: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> Message-ID: <069.f3f2aaa8a069e09b71a04c65c3ec6809@haskell.org> #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14288#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 12:25:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 12:25:48 -0000 Subject: [GHC] #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints In-Reply-To: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> References: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> Message-ID: <065.be19d531bc7da0d0a3b60d1ab64c64a5@haskell.org> #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #9091, #9479 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): I said in old tickets that Typed Holes should not be enabled by default in the compiler. It does not make sense to activate it by default. At most it will only be an additional help but not a wonder and has shown so far that Typed Holes gives us more worry than clarity because of the errors (or warning) returned by the compiler. In this attitude the author is not wrong. I agree with him, because in some circumstances Typed Holes does not make sense. As for the usefulness of Typed Holes, his help is not miraculous. in all cases, Typed Holes should not be enabled by default. Take a look in Miranda, there is no Typed Holes and everything goes very well. Sometimes when one wants to do too well one does too badly. So Typed Holes in Haskell, why not? Provided you do not activate it by default! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14273#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 12:55:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 12:55:24 -0000 Subject: [GHC] #14289: Pretty-printing of derived multi-parameter classes omits necessary parentheses Message-ID: <050.12237887bf2722a5c0ca5d51c4478a96@haskell.org> #14289: Pretty-printing of derived multi-parameter classes omits necessary parentheses -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Take this file: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS -ddump-splices #-} import Language.Haskell.TH class C a b main :: IO () main = putStrLn $([d| data Foo a = Foo a deriving (C a) |] >>= stringE . show) }}} When this is compiled, `-ddump-splices` does not faithfully print back what was written by the user: {{{ [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:10:19-77: Splicing expression [d| data Foo_a4l1 a_a4l3 = Foo_a4l2 a_a4l3 deriving C a_a4l3 |] >>= stringE . show ======> "[DataD [] Foo_6989586621679026555 [PlainTV a_6989586621679026557] Nothing [NormalC Foo_6989586621679026556 [(Bang NoSourceUnpackedness NoSourceStrictness,VarT a_6989586621679026557)]] [DerivClause Nothing [AppT (ConT Main.C) (VarT a_6989586621679026557)]]]" }}} In particular, this pretty-prints `deriving C a_a4l3`, which doesn't even parse correctly. It should print `deriving (C a_a4l3)`. Ultimately, there is an off-by-one error in the number of parentheses being printed, since if you tweak the original example by adding another set of parentheses: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS -ddump-splices #-} import Language.Haskell.TH class C a b main :: IO () main = putStrLn $([d| data Foo a = Foo a deriving ((C a)) |] >>= stringE . show) }}} Then it pretty-prints exactly one set of parentheses (as opposed to two): {{{ [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:10:19-79: Splicing expression [d| data Foo_a1zI a_a1zK = Foo_a1zJ a_a1zK deriving (C a_a1zK) |] >>= stringE . show ======> "[DataD [] Foo_6989586621679026522 [PlainTV a_6989586621679026524] Nothing [NormalC Foo_6989586621679026523 [(Bang NoSourceUnpackedness NoSourceStrictness,VarT a_6989586621679026524)]] [DerivClause Nothing [AppT (ConT Main.C) (VarT a_6989586621679026524)]]]" }}} There are two suspicious parts of the GHC codebase that contribute to this bug: * This parser production: http://git.haskell.org/ghc.git/blob/4364f1e7543b6803cfaef321105d253e0bdf08a4:/compiler/parser/Parser.y#l2162 This recognizes singleton derived classes that are surrounded by a set of parentheses, and "strips off" the parentheses. * This `Outputable` instance: http://git.haskell.org/ghc.git/blob/4364f1e7543b6803cfaef321105d253e0bdf08a4:/compiler/hsSyn/HsDecls.hs#l1102 This code detects lists of two or more derived classes and surrounds them with extra parentheses to make up for the set that was removed during parsing. But this fails to detect the case of `deriving (C a)`, since this only contains a single class. Indeed, trying to distinguish between, say, `deriving T` and `deriving (T)` at this level would be quite tricky. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14289> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 12:57:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 12:57:29 -0000 Subject: [GHC] #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints In-Reply-To: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> References: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> Message-ID: <065.afd99cf57cc4fa0f9dbb11aa303bf8f5@haskell.org> #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #9091, #9479 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): Replying to [comment:11 simonpj]: Thanks for the clarifications. I'll aim for making it work for the common cases then. Replying to [comment:12 vanto]: Well, they're (kind of) not on by default, you have to have a typed hole in your code for it to trigger. What other behaviour do you want when `_` is encountered in expressions? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14273#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 13:03:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 13:03:29 -0000 Subject: [GHC] #9898: Wanted: higher-order type-level programming In-Reply-To: <045.8f7b834957773169b7810af17c757a81@haskell.org> References: <045.8f7b834957773169b7810af17c757a81@haskell.org> Message-ID: <060.a3fcca653ccb6ad534b77a880cd4ee84@haskell.org> #9898: Wanted: higher-order type-level programming -------------------------------------+------------------------------------- Reporter: erisco | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): See also [https://github.com/ghc-proposals/ghc-proposals/pull/52 this GHC proposal] on partially applied type families, which is quite relevant here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9898#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 13:03:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 13:03:50 -0000 Subject: [GHC] #9898: Wanted: higher-order type-level programming In-Reply-To: <045.8f7b834957773169b7810af17c757a81@haskell.org> References: <045.8f7b834957773169b7810af17c757a81@haskell.org> Message-ID: <060.1a08876d822bf83d97867e067a9e467a@haskell.org> #9898: Wanted: higher-order type-level programming -------------------------------------+------------------------------------- Reporter: erisco | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => TypeFamilies -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9898#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 13:05:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 13:05:46 -0000 Subject: [GHC] #14285: Entered absent arg - triggered by INLINEABLE, regression from 8.0.2 In-Reply-To: <049.09fbd6d1ad4f0a97bcd76579dd68ae8a@haskell.org> References: <049.09fbd6d1ad4f0a97bcd76579dd68ae8a@haskell.org> Message-ID: <064.44265850c248fbd506ad04420d634cda@haskell.org> #14285: Entered absent arg - triggered by INLINEABLE, regression from 8.0.2 ---------------------------------+-------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): This may or may not be the same root cause as #11126. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14285#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 13:24:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 13:24:36 -0000 Subject: [GHC] #13966: Skip-less stream fusion: a missed opportunity In-Reply-To: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> References: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> Message-ID: <063.5d869dc5a84c61f2b09998a54e4df60d@haskell.org> #13966: Skip-less stream fusion: a missed opportunity -------------------------------------+------------------------------------- Reporter: jmspiewak | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints, | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14067 #14068 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Implementing this leads to: {{{ benchmarking Skip-less time 632.2 ms (532.7 ms .. 835.8 ms) 0.988 R² (0.976 R² .. 1.000 R²) mean 1.187 s (1.044 s .. 1.308 s) std dev 191.0 ms (0.0 s .. 207.9 ms) variance introduced by outliers: 46% (moderately inflated) benchmarking Skip time 904.3 ms (904.1 ms .. 904.8 ms) 1.000 R² (1.000 R² .. 1.000 R²) mean 1.230 s (1.130 s .. 1.306 s) std dev 114.9 ms (0.0 s .. 130.3 ms) variance introduced by outliers: 22% (moderately inflated) }}} And the core looks quite similar: {{{ chain1 = \ (w_s9yo :: Int) -> case w_s9yo of { GHC.Types.I# ww1_s9yr -> joinrec { $wsat_worker2_s9yn [InlPrag=NOUSERINLINE[0], Occ=LoopBreaker] :: Int# -> Int# -> Int [LclId[JoinId(2)], Arity=2, Str=<S,U><S,U>m, Unf=OtherCon []] $wsat_worker2_s9yn (ww2_s9yh :: Int#) (ww3_s9yl :: Int#) = join { lvl_s9BD [Dmd=<L,U(U)>] :: Int [LclId[JoinId(0)], Str=m, Unf=OtherCon []] lvl_s9BD = GHC.Types.I# ww2_s9yh } in joinrec { $wsat_worker3_s9yc [InlPrag=NOUSERINLINE[0], Occ=LoopBreaker] :: Int# -> Int [LclId[JoinId(1)], Arity=1, Str=<S,U>m, Unf=OtherCon []] $wsat_worker3_s9yc (ww4_s9ya :: Int#) = case ># ww4_s9ya ww1_s9yr of { __DEFAULT -> case remInt# ww4_s9ya 2# of { __DEFAULT -> jump $wsat_worker3_s9yc (+# ww4_s9ya 1#); 0# -> jump $wsat_worker2_s9yn (+# ww2_s9yh ww4_s9ya) (+# ww4_s9ya 1#) }; 1# -> jump lvl_s9BD }; } in jump $wsat_worker3_s9yc ww3_s9yl; } in jump $wsat_worker2_s9yn 0# 1# } }}} {{{ chain2 = \ (w_s9xY :: Int) -> case w_s9xY of { GHC.Types.I# ww1_s9y1 -> joinrec { $wsat_worker2_s9xX [InlPrag=NOUSERINLINE[0], Occ=LoopBreaker] :: Int# -> Int# -> Int [LclId[JoinId(2)], Arity=2, Str=<S,U><S,U>m, Unf=OtherCon []] $wsat_worker2_s9xX (ww2_s9xR :: Int#) (ww3_s9xV :: Int#) = case ># ww3_s9xV ww1_s9y1 of { __DEFAULT -> case remInt# ww3_s9xV 2# of { __DEFAULT -> jump $wsat_worker2_s9xX ww2_s9xR (+# ww3_s9xV 1#); 0# -> jump $wsat_worker2_s9xX (+# ww2_s9xR ww3_s9xV) (+# ww3_s9xV 1#) }; 1# -> GHC.Types.I# ww2_s9xR }; } in jump $wsat_worker2_s9xX 0# 1# } }}} Still need to investigate the general impact more. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13966#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 14:02:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 14:02:48 -0000 Subject: [GHC] #14279: Type families interfere with specialisation rewrite rules In-Reply-To: <051.c770f0db94d1fbd7b1e66a5d39f244a4@haskell.org> References: <051.c770f0db94d1fbd7b1e66a5d39f244a4@haskell.org> Message-ID: <066.453cebea46d99a49113a2ef437797f48@haskell.org> #14279: Type families interfere with specialisation rewrite rules -------------------------------------+------------------------------------- Reporter: IvanTimokhin | 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => TypeFamilies -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14279#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 14:23:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 14:23:28 -0000 Subject: [GHC] #14285: Entered absent arg - triggered by INLINEABLE, regression from 8.0.2 In-Reply-To: <049.09fbd6d1ad4f0a97bcd76579dd68ae8a@haskell.org> References: <049.09fbd6d1ad4f0a97bcd76579dd68ae8a@haskell.org> Message-ID: <064.eef015b319053191134d58bd41b6f73d@haskell.org> #14285: Entered absent arg - triggered by INLINEABLE, regression from 8.0.2 ---------------------------------+-------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by RyanGlScott): By sheer dumb luck, I managed to reduce this down to the following two files: {{{#!hs module Foo where import qualified Data.Foldable as F import qualified Data.IntMap as IM import qualified Data.IntSet as IS import Prelude hiding (null) import System.Environment data Set k = Set IS.IntSet null (Set a) = IS.null a empty = Set IS.empty sfromList :: (Enum a, Foldable c) => c a -> Set a sfromList xs = Set $ IS.fromList $ Prelude.map fromEnum $ F.toList xs newtype Map k v = Map { unMap :: (IM.IntMap v) } deriving (Eq, Ord) {-# inlineable fromList #-} fromList :: Enum k => [(k,v)] -> Map k v fromList kvs = Map $ IM.fromList $ Prelude.map (\(k,v) -> (fromEnum k, v)) kvs {-# inlineable findWithDefault #-} findWithDefault d k (Map m) = IM.findWithDefault d (fromEnum k) m data Rel a b = Rel !(Map a (Set b)) !(Map b (Set a)) {-# INLINEABLE images #-} images x (Rel f b) = findWithDefault empty x f {-# INLINEABLE pre_images #-} pre_images x rel = images x $ mirrorRel rel {-# INLINEABLE mirrorRel #-} mirrorRel :: Rel a b -> Rel b a mirrorRel (Rel f g) = Rel g f }}} {{{#!hs module Main where import Foo import Prelude hiding (null) main :: IO () main = do let args = "hw" print $ null $ pre_images 'a' (Rel (fromList [('a',sfromList args)]) (fromList [('b',sfromList ar gs)])) }}} This works on GHC 8.0.2: {{{ $ /opt/ghc/8.0.2/bin/ghc -O2 -fforce-recomp Main.hs [1 of 2] Compiling Foo ( Foo.hs, Foo.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ ./Main True }}} But not on GHC 8.2.1: {{{ $ /opt/ghc/8.0.2/bin/ghc -O2 -fforce-recomp Main.hs [1 of 2] Compiling Foo ( Foo.hs, Foo.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ ./Main True }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14285#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 14:24:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 14:24:49 -0000 Subject: [GHC] #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints In-Reply-To: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> References: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> Message-ID: <065.2e3533deed90fe6b2f0a7b4f3f78c0ce@haskell.org> #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #9091, #9479 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): Replying to [[span(style=color: #FF0000, Tritlo )]]:\\ In GHC 5.0.3 or GHC 6.0, for instance:\\ {{{ Prelude> (\x -> x + _) 3 <interactive>:1: Pattern syntax in expression context: _ }}} This response from the compiler is clear and sufficient.\\ For those who want to go further and find an answer, then they activate Typed Holes in the compiler and start again. {{{ Prelude> f = (\x -> x + _) 2 <interactive>:1:16: error: * Found hole: _ :: a Where: `a' is a rigid type variable bound by the inferred type of f :: Num a => a at <interactive>:1:1-19 * In the second argument of `(+)', namely `_' In the expression: x + _ In the expression: \ x -> x + _ * Relevant bindings include x :: a (bound at <interactive>:1:7) f :: a (bound at <interactive>:1:1) }}} It is better to do as before rather than to do the reverse, ie write {{{-fdefer-type-errors}}} or {{{ -fdefer-typed-holes}}} Being brief, use Typed Holes if needed. I have no retrograde ideas when I say that. I'm thinking of a better use of the compiler. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14273#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 14:27:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 14:27:25 -0000 Subject: [GHC] #14287: Early inlining causes potential join points to be missed In-Reply-To: <044.afeda1d17d7fca2451446457f502779c@haskell.org> References: <044.afeda1d17d7fca2451446457f502779c@haskell.org> Message-ID: <059.5bb995de5e0aa1476d0f906e4e8f09cc@haskell.org> #14287: Early inlining causes potential join points to be missed -------------------------------------+------------------------------------- Reporter: jheek | 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 bgamari): > What surprises me about this issue is that the gentle run seems to perform inlining while the wiki mentions that inlining is not performed in this stage: ​https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Core2CorePipeline Indeed, as of 2effe18ab51d66474724d38b20e49cc1b8738f60 this is no longer true. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14287#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 15:11:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 15:11:26 -0000 Subject: [GHC] #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 In-Reply-To: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> References: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> Message-ID: <069.0a06ae58936937eb01cc86d704b629a5@haskell.org> #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I believe this is by design. But I agree that the manual does not mention it. Simon, I think this was a part of the big refactoring around `HsImplicitBndrs` and `HsSigType`s and such. Do you agree? Regardless, we should update the manual. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14288#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 15:16:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 15:16:39 -0000 Subject: [GHC] #14290: Strictness bug with existential contexts on data constructors Message-ID: <047.5982a590b871aad7c07e701c3f87fe86@haskell.org> #14290: Strictness bug with existential contexts on data constructors -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- The following: {{{ {-# LANGUAGE ExistentialQuantification #-} module Main (main) where main :: IO () main = r `seq` return () r :: Rec r = Rec{ a = error "xxx", b = 3, c = True } class C t instance C Bool data Rec = forall t. C t => Rec { a :: () , b :: !Int , c :: t } }}} Fails with `error "xxx"`, when it should succeed. The problem is that the strictness signature for the data con wrapper doesn't take into account the dictionary fields. I have a patch which I'll upload to Phabricator shortly... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14290> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 15:18:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 15:18:12 -0000 Subject: [GHC] #14290: Strictness bug with existential contexts on data constructors In-Reply-To: <047.5982a590b871aad7c07e701c3f87fe86@haskell.org> References: <047.5982a590b871aad7c07e701c3f87fe86@haskell.org> Message-ID: <062.3e68eb9e49ded7023c2370395ebad8ed@haskell.org> #14290: Strictness bug with existential contexts on data constructors -------------------------------------+------------------------------------- Reporter: simonmar | 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: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonmar: Old description: > The following: > > {{{ > {-# LANGUAGE ExistentialQuantification #-} > module Main (main) where > > main :: IO () > main = r `seq` return () > > r :: Rec > r = Rec{ a = error "xxx", b = 3, c = True } > > class C t > instance C Bool > > data Rec = forall t. C t => Rec > { a :: () > , b :: !Int > , c :: t > } > }}} > > Fails with `error "xxx"`, when it should succeed. The problem is that the > strictness signature for the data con wrapper doesn't take into account > the dictionary fields. > > I have a patch which I'll upload to Phabricator shortly... New description: The following: {{{ {-# LANGUAGE ExistentialQuantification #-} module Main (main) where main :: IO () main = r `seq` return () r :: Rec r = Rec{ a = error "xxx", b = 3, c = True } class C t instance C Bool data Rec = forall t. C t => Rec { a :: () , b :: !Int , c :: t } }}} Should succesed, but fails with `error "xxx"` (but only when compiled with `-O`). The problem is that the strictness signature for the data con wrapper doesn't take into account the dictionary fields. I have a patch which I'll upload to Phabricator shortly... -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14290#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 15:18:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 15:18:27 -0000 Subject: [GHC] #14290: Strictness bug with existential contexts on data constructors In-Reply-To: <047.5982a590b871aad7c07e701c3f87fe86@haskell.org> References: <047.5982a590b871aad7c07e701c3f87fe86@haskell.org> Message-ID: <062.e9cd725ec080c748c6aea243ecbb33e4@haskell.org> #14290: Strictness bug with existential contexts on data constructors -------------------------------------+------------------------------------- Reporter: simonmar | 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: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonmar: Old description: > The following: > > {{{ > {-# LANGUAGE ExistentialQuantification #-} > module Main (main) where > > main :: IO () > main = r `seq` return () > > r :: Rec > r = Rec{ a = error "xxx", b = 3, c = True } > > class C t > instance C Bool > > data Rec = forall t. C t => Rec > { a :: () > , b :: !Int > , c :: t > } > }}} > > Should succesed, but fails with `error "xxx"` (but only when compiled > with `-O`). The problem is that the strictness signature for the data con > wrapper doesn't take into account the dictionary fields. > > I have a patch which I'll upload to Phabricator shortly... New description: The following: {{{ {-# LANGUAGE ExistentialQuantification #-} module Main (main) where main :: IO () main = r `seq` return () r :: Rec r = Rec{ a = error "xxx", b = 3, c = True } class C t instance C Bool data Rec = forall t. C t => Rec { a :: () , b :: !Int , c :: t } }}} Should succeed, but fails with `error "xxx"` (but only when compiled with `-O`). The problem is that the strictness signature for the data con wrapper doesn't take into account the dictionary fields. I have a patch which I'll upload to Phabricator shortly... -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14290#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 15:24:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 15:24:22 -0000 Subject: [GHC] #14290: Strictness bug with existential contexts on data constructors In-Reply-To: <047.5982a590b871aad7c07e701c3f87fe86@haskell.org> References: <047.5982a590b871aad7c07e701c3f87fe86@haskell.org> Message-ID: <062.5fea70fb15c391e5683faab21d364fec@haskell.org> #14290: Strictness bug with existential contexts on data constructors -------------------------------------+------------------------------------- Reporter: simonmar | 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: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4040 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * differential: => Phab:D4040 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14290#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 15:35:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 15:35:30 -0000 Subject: [GHC] #14287: Early inlining causes potential join points to be missed In-Reply-To: <044.afeda1d17d7fca2451446457f502779c@haskell.org> References: <044.afeda1d17d7fca2451446457f502779c@haskell.org> Message-ID: <059.f4424ef5fe14f4ee1ca99a26a4302b94@haskell.org> #14287: Early inlining causes potential join points to be missed -------------------------------------+------------------------------------- Reporter: jheek | 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 jheek): I’m not sure whether early inlining is really the issue here but it does seem to avoid it. I also found arity analysis to be important in this case. Would it make sense to (optionally) run the float out step only after a full simplify, arity, and simplify cycle? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14287#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 15:39:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 15:39:54 -0000 Subject: [GHC] #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints In-Reply-To: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> References: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> Message-ID: <065.e1fbffe744d388ade9e2fdc38730c202@haskell.org> #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #9091, #9479 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): vanto, I don't think many others will agree with you. But if you feel strongly about it, you can write up a GHC proposal at https://github.com /ghc-proposals/ghc-proposals -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14273#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 16:03:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 16:03:19 -0000 Subject: [GHC] #12376: Allow function definitions in record syntax In-Reply-To: <051.ff1dad08610f3c1f3808a2894d40fdae@haskell.org> References: <051.ff1dad08610f3c1f3808a2894d40fdae@haskell.org> Message-ID: <066.874f124ab7fa9042624a514728b3b4b7@haskell.org> #12376: Allow function definitions in record syntax -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:8 goldfire]: > But, @Iceland_jack, I encourage you to use the ghc-proposals process for ideas like this, as it's now the official place for the community to weigh in on new language ideas. I'm not sure if this is worth the effort but I did similar sugar in [https://www.microsoft.com/en-us/research/wp- content/uploads/2016/02/scopedlabels.pdf Extensible records with scoped labels]: > As convenient syntactic sugar, we abbreviate the binding of a functional value `(l = \x1 ... xn → e)` as `(l x1 ... xn = e)`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12376#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 16:27:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 16:27:59 -0000 Subject: [GHC] #14291: Tests tend to fail in the ext-interp when testing a tree built with a source distribution Message-ID: <046.50939ac6d09fd8ac7c487275ec7ee681@haskell.org> #14291: Tests tend to fail in the ext-interp when testing a tree built with a source distribution -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- One issue I've noticed while working on #13716 is that most (if not all) of the tests runs in the `ext-interp` way fail when run inside a tree derived from a source distribution tarball. For instance, {{{ $ git clone git://git.haskell.org/ghc $ cd ghc $ git submodule update --init $ mk/get-win32-tarballs.sh download all $ ./boot $ ./configure $ make sdist $ mkdir tmp; cd tmp $ ls ../sdistprep/ghc-*-src.tar.xz | xargs -n1 tar -xf $ cd ghc-* $ ./boot $ ./configure $ make -j9 $ make test TEST=T10638 ... =====> T10638(normal) 1 of 1 [0, 0, 0] cd "./th/T10638.run" && "/mnt/work/ghc/ghc- testing/temp/ghc-8.3.20170927/inplace/bin/ghc-stage2" -c T10638.hs -dcore- lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output -XTemplateHaskell -package template-haskell -v0 =====> T10638(ext-interp) 1 of 1 [0, 0, 0] cd "./th/T10638.run" && "/mnt/work/ghc/ghc- testing/temp/ghc-8.3.20170927/inplace/bin/ghc-stage2" -c T10638.hs -dcore- lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output -XTemplateHaskell -package template-haskell -fexternal-interpreter -v0 Actual stderr output differs from expected: diff -uw "./th/T10638.run/T10638.stderr.normalised" "./th/T10638.run/T10638.comp.stderr.normalised" --- ./th/T10638.run/T10638.stderr.normalised 2017-09-27 12:18:45.737974039 -0400 +++ ./th/T10638.run/T10638.comp.stderr.normalised 2017-09-27 12:18:45.737974039 -0400 @@ -1,5 +1,18 @@ +ghc-iserv.bin: internal evacuate(static): strange closure type 16476 + (GHC version 8.3.20170927 for x86_64_unknown_linux) + Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -T10638.hs:26:11: - ‘static test2’ is not a valid C identifier - When checking declaration: - foreign import prim safe "static test2" cmm_test2 :: Int# -> Int# +T10638.hs:26:9: + Exception when trying to run compile-time code: + {handle: <file descriptor: 11>}: GHCi.Message.remoteCall: end of file + Code: do t <- [t| Int# -> Int# |] + cmm_test2 <- newName "cmm_test2" + addTopDecls + [ForeignD (ImportF Prim Safe "static test2" cmm_test2 t)] + .... + In the untyped splice: + $(do t <- [t| Int# -> Int# |] + cmm_test2 <- newName "cmm_test2" + addTopDecls + [ForeignD (ImportF Prim Safe "static test2" cmm_test2 t)] + [| test1 |]) *** unexpected failure for T10638(ext-interp) Unexpected results from: TEST="T10638" ... }}} The crashes are generally RTS panics or segmentation faults. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14291> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 16:28:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 16:28:11 -0000 Subject: [GHC] #13716: Move CI to Jenkins In-Reply-To: <046.48e2facaae8e965ca7d5990f8113aa95@haskell.org> References: <046.48e2facaae8e965ca7d5990f8113aa95@haskell.org> Message-ID: <061.59a6fbbad5609f5f325051ec6f24c052@haskell.org> #13716: Move CI to Jenkins -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13897, 14291 | Blocking: Related Tickets: #11958, #13205 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * blockedby: 13897 => 13897, 14291 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13716#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 16:33:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 16:33:11 -0000 Subject: [GHC] #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints In-Reply-To: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> References: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> Message-ID: <065.8387e3ba8eb042445fa64c01f402e22a@haskell.org> #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #9091, #9479 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): Thank you very much. It is a matter of point of view. If I drive on a road I know with my car, I do not operate the GPS. I do not have to listen to the details of the road. I think it makes sense. But I also have the choice of putting it into operation. So if I had the same possibility with the compiler about Typed Holes, then it would be perfect. No proposal for that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14273#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 17:14:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 17:14:35 -0000 Subject: [GHC] #11295: Figure out what LLVM passes are fruitful In-Reply-To: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> References: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> Message-ID: <061.106c43d782bfab48a13a35fe30120e4d@haskell.org> #11295: Figure out what LLVM passes are fruitful -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): One useful tool for this may be [[http://opentuner.org/publications/|OpenTuner]], which is mentioned in [[https://www.youtube.com/watch?v=P3eJwoD97bY|this talk]] in the context of tuning optimization pass sequences. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11295#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 17:15:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 17:15:53 -0000 Subject: [GHC] #14292: Coercing between constraints of newtypes Message-ID: <051.e9d001b6d6e7069b1e2d96a31ac34922@haskell.org> #14292: Coercing between constraints of newtypes -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This doesn't work {{{#!hs {-# Language ConstraintKinds #-} {-# Language GADTs #-} import Data.Coerce newtype USD = USD Int data Dict c where Dict :: c => Dict c num :: Dict (Num Int) -> Dict (Num USD) num = coerce }}} but this does {{{#!hs data NUM a = NUM (a -> a -> a) num' :: NUM Int -> NUM USD num' = coerce }}} is this a fundamental limitation? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14292> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 17:30:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 17:30:41 -0000 Subject: [GHC] #14291: Tests tend to fail in the ext-interp when testing a tree built with a source distribution In-Reply-To: <046.50939ac6d09fd8ac7c487275ec7ee681@haskell.org> References: <046.50939ac6d09fd8ac7c487275ec7ee681@haskell.org> Message-ID: <061.cf199bf37088dd53fa4f0191eac84e62@haskell.org> #14291: Tests tend to fail in the ext-interp when testing a tree built with a source distribution -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.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: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Well, unsurprisingly, the culprit is actually not the fact that the compiler was built from a source tarball. Doing the build on the git tree gives the same result. I suspect the problem is rather that the `validate` build flavour isn't being used since I didn't provide a `build.mk`. Here are some relevant settings from the two configurations, No `build.mk`: {{{ DYNAMIC_BY_DEFAULT="NO" DYNAMIC_GHC_PROGRAMS="YES" GhcLibHcOpts="-O2" GhcRtsCcOpts="-O2 -fomit-frame-pointer -g" GhcRtsHcOpts="-O2 -Wcpp-undef" GhcStage1HcOpts=" -Wcpp-undef" GhcStage2HcOpts="-O2 -Wcpp-undef" SplitObjs="NO" SplitSections="YES" SRC_HC_OPTS="-H32m -O -Wall" SRC_HC_OPTS_STAGE1=" " }}} Validate: {{{ DYNAMIC_BY_DEFAULT="NO" DYNAMIC_GHC_PROGRAMS="YES" GhcLibHcOpts="-O -dcore-lint -dno-debug-output" GhcRtsCcOpts="-O2 -fomit-frame-pointer -g" GhcRtsHcOpts="-O2" GhcStage1HcOpts="-O -DDEBUG" GhcStage2HcOpts="-O -dcore-lint -dno-debug-output" SplitObjs="NO" SplitSections="NO" SRC_HC_OPTS="-O0 -H64m -Wall" SRC_HC_OPTS_STAGE1="-fllvm-fill-undef-with-garbage -Werror" }}} These differ as follows, {{{#!diff --- good 2017-09-27 13:27:52.809897224 -0400 +++ bad 2017-09-27 13:28:01.425893705 -0400 @@ -1,11 +1,11 @@ DYNAMIC_BY_DEFAULT="NO" DYNAMIC_GHC_PROGRAMS="YES" -GhcLibHcOpts="-O -dcore-lint -dno-debug-output" +GhcLibHcOpts="-O2" GhcRtsCcOpts="-O2 -fomit-frame-pointer -g" -GhcRtsHcOpts="-O2" -GhcStage1HcOpts="-O -DDEBUG" -GhcStage2HcOpts="-O -dcore-lint -dno-debug-output" +GhcRtsHcOpts="-O2 -Wcpp-undef" +GhcStage1HcOpts=" -Wcpp-undef" +GhcStage2HcOpts="-O2 -Wcpp-undef" SplitObjs="NO" -SplitSections="NO" -SRC_HC_OPTS="-O0 -H64m -Wall" -SRC_HC_OPTS_STAGE1="-fllvm-fill-undef-with-garbage -Werror" +SplitSections="YES" +SRC_HC_OPTS="-H32m -O -Wall" +SRC_HC_OPTS_STAGE1=" " }}} There are a number of differences here. However, what catches my eye most is `SplitSections` since this sort of crash is often due to linker issues. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14291#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 17:34:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 17:34:46 -0000 Subject: [GHC] #14293: View patterns with locally defined functions in restructuring don't compile Message-ID: <048.c31716401fbaaf0de63b3851966b01cc@haskell.org> #14293: View patterns with locally defined functions in restructuring don't compile -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE ViewPatterns #-} foo x = x Just (id -> res) = pure 'a' -- WORKS Just (foo -> res') = pure 'a' -- FAILS bar (foo -> res) = res -- WORKS {- [1 of 1] Compiling Main ( T14293.hs, interpreted ) T14293.hs:6:7-9: error: Variable not in scope: foo :: Char -> t | 6 | Just (foo -> res') = pure 'a' | ^^^ Failed, 0 modules loaded. -} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14293> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 18:01:15 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 18:01:15 -0000 Subject: [GHC] #14294: IndexError: pop from empty list Message-ID: <048.d023a95248a740b652c7c9c06b669e05@haskell.org> #14294: IndexError: pop from empty list -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ==== How to Reproduce ==== While doing a GET operation on `/attachment/ticket/14293/`, Trac issued an internal error. ''(please provide additional details here)'' Request parameters: {{{ {u'action': u'new', 'path': u'14293/', 'realm': u'ticket'} }}} User agent: `Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/603.3.8 (KHTML, like Gecko) Version/10.1.2 Safari/603.3.8` ==== System Information ==== ''Systeminformation nicht verfügbar'' ==== Enabled Plugins ==== ''Plugininformation nicht verfügbar'' ==== Interface Customization ==== ''Interface customization information not available'' ==== Python Traceback ==== {{{ Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/trac/web/main.py", line 623, in _dispatch_request dispatcher.dispatch(req) File "/usr/local/lib/python2.7/dist-packages/trac/web/main.py", line 259, in dispatch iterable=chrome.use_chunked_encoding) File "/usr/local/lib/python2.7/dist-packages/trac/web/chrome.py", line 1165, in render_template encoding='utf-8') File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 184, in render return encode(generator, method=method, encoding=encoding, out=out) File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 58, in encode for chunk in iterator: File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 350, in __call__ for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 829, in __call__ for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 669, in __call__ for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 774, in __call__ for kind, data, pos in chain(stream, [(None, None, None)]): File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 594, in __call__ for ev in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/trac/web/chrome.py", line 1432, in _strip_accesskeys for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/trac/web/chrome.py", line 1421, in _generate for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 706, in _unmark for mark, event in stream: File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 1101, in __call__ for mark, event in stream: File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 118, in __iter__ event = self.stream.next() File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 734, in __call__ for mark, event in stream: File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 702, in _mark for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 378, in _match ctxt, start=idx + 1, **vars): File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 378, in _match ctxt, start=idx + 1, **vars): File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 362, in _match content = list(content) File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 326, in _match for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 315, in _strip event = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 558, in _flatten for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/path.py", line 588, in _generate subevent = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 315, in _strip event = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 558, in _flatten for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/path.py", line 588, in _generate subevent = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 315, in _strip event = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 558, in _flatten for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/filters/i18n.py", line 178, in _generate for event in msgbuf.translate(gettext(msgbuf.format())): File "/usr/local/lib/python2.7/dist-packages/genshi/filters/i18n.py", line 1051, in translate events = self.events[order].pop(0) IndexError: pop from empty list }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14294> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 18:02:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 18:02:22 -0000 Subject: [GHC] #14294: IndexError: pop from empty list In-Reply-To: <048.d023a95248a740b652c7c9c06b669e05@haskell.org> References: <048.d023a95248a740b652c7c9c06b669e05@haskell.org> Message-ID: <063.150a811a91a29e9650abfe433156718c@haskell.org> #14294: IndexError: pop from empty list -------------------------------------+------------------------------------- Reporter: heisenbug | 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 heisenbug): I wanted to add the test file as an attachment. It did not work :-( adding it here instead, if it works... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14294#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 18:03:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 18:03:59 -0000 Subject: [GHC] #14292: Coercing between constraints of newtypes In-Reply-To: <051.e9d001b6d6e7069b1e2d96a31ac34922@haskell.org> References: <051.e9d001b6d6e7069b1e2d96a31ac34922@haskell.org> Message-ID: <066.df79cd149317ddcf2f4d7db33b6d7642@haskell.org> #14292: Coercing between constraints of newtypes -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I wouldn't say that this is rejected due to a fundamental limitation so much as a deliberate design choice. The immediate reason that the former program is rejected is due to roles. By default, all class parameters are given role `nominal`, so you can't coerce between `Num a` and `Num b` unless `a ~ b`. Why is the case? Even if `a` and `b` are representationally equal, there's absolutely no guarantee that their corresponding `Num` dictionaries are also representationally equal. After all, a `Num` instance for `USD` might do something crazy like `fromInteger _ = USD 42`. Defaulting class parameters to `nominal` is thus a conservative way to avoid the shenanigans that would unfold if you treated a `Num USD` dictionary as a `Num Int` one, or vice versa. Now you might object: "But I'm a careful programmer! I promise to only use `Num Int` and `Num USD` dictionaries that are representationally equivalent!" In that case, there is a fallback mechanism in the form of `IncoherentInstances`: {{{#!hs {-# Language ConstraintKinds #-} {-# Language GADTs #-} {-# Language IncoherentInstances #-} {-# Language RoleAnnotations #-} import Data.Coerce import Prelude hiding (Num(..)) newtype USD = USD Int data Dict c where Dict :: c => Dict c type role Num representational class Num a where -- ... instance Num Int instance Num USD num :: Dict (Num Int) -> Dict (Num USD) num = coerce }}} I hope it should be obvious from the name `IncoherentInstances` alone that this fallback carries significant risks. Use this trick at your own discretion. Does that answer the question satisfactorily? If so, please feel free to close the ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14292#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 18:11:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 18:11:04 -0000 Subject: [GHC] #14291: Tests tend to fail in the ext-interp when testing a tree built with a source distribution In-Reply-To: <046.50939ac6d09fd8ac7c487275ec7ee681@haskell.org> References: <046.50939ac6d09fd8ac7c487275ec7ee681@haskell.org> Message-ID: <061.14fc54a2d65d4dfba6347776ddf28ec4@haskell.org> #14291: Tests tend to fail in the ext-interp when testing a tree built with a source distribution -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.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: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed `SplitSections` is the culprit. It seems enabling `SplitSections` breaks `ext-interp`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14291#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 18:55:38 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 18:55:38 -0000 Subject: [GHC] #14292: Coercing between constraints of newtypes In-Reply-To: <051.e9d001b6d6e7069b1e2d96a31ac34922@haskell.org> References: <051.e9d001b6d6e7069b1e2d96a31ac34922@haskell.org> Message-ID: <066.acb4f3facd4db1fe0eb75201377c8587@haskell.org> #14292: Coercing between constraints of newtypes -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Ryan is, as usual, spot on. The need for `-XIncoherentInstances` in Ryan's example was a deliberate design choice to discourage non-nominally roled classes. And the extension name is accurate: you're using instances in a fundamentally incoherent (but still type-safe) way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14292#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 19:29:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 19:29:03 -0000 Subject: [GHC] #14294: IndexError: pop from empty list In-Reply-To: <048.d023a95248a740b652c7c9c06b669e05@haskell.org> References: <048.d023a95248a740b652c7c9c06b669e05@haskell.org> Message-ID: <063.70a79f9f06c4e621cd9cd418fb57e730@haskell.org> #14294: IndexError: pop from empty list -------------------------------------+------------------------------------- Reporter: heisenbug | 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 bgamari): Was the URL you were requesting https://ghc.haskell.org/trac/ghc/attachment/ticket/14293/ ? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14294#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 19:32:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 19:32:29 -0000 Subject: [GHC] #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 In-Reply-To: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> References: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> Message-ID: <069.8ba973a774aa330ae5f70542af5dd17c@haskell.org> #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): For what it's worth, it's quite simple to change the behavior to make it work the way you desire: {{{#!diff diff --git a/compiler/hsSyn/HsTypes.hs b/compiler/hsSyn/HsTypes.hs index b9cd946..5e0f885 100644 --- a/compiler/hsSyn/HsTypes.hs +++ b/compiler/hsSyn/HsTypes.hs @@ -54,7 +54,8 @@ module HsTypes ( hsScopedTvs, hsWcScopedTvs, dropWildCards, hsTyVarName, hsAllLTyVarNames, hsLTyVarLocNames, hsLTyVarName, hsLTyVarLocName, hsExplicitLTyVarNames, - splitLHsInstDeclTy, getLHsInstDeclHead, getLHsInstDeclClass_maybe, + splitLHsInstDeclTy, splitNestedLHsSigmaTys, + getLHsInstDeclHead, getLHsInstDeclClass_maybe, splitLHsPatSynTy, splitLHsForAllTy, splitLHsQualTy, splitLHsSigmaTy, splitHsFunType, splitHsAppsTy, @@ -76,7 +77,7 @@ import PlaceHolder ( PlaceHolder(..) ) import HsExtension import Id ( Id ) -import Name( Name ) +import Name( Name, NamedThing(..) ) import RdrName ( RdrName ) import NameSet ( NameSet, emptyNameSet ) import DataCon( HsSrcBang(..), HsImplBang(..), @@ -843,17 +844,19 @@ hsWcScopedTvs sig_ty | HsWC { hswc_wcs = nwcs, hswc_body = sig_ty1 } <- sig_ty , HsIB { hsib_vars = vars, hsib_body = sig_ty2 } <- sig_ty1 = case sig_ty2 of - L _ (HsForAllTy { hst_bndrs = tvs }) -> vars ++ nwcs ++ - map hsLTyVarName tvs + fa_ty@(L _ (HsForAllTy {})) + | (tvs, _, _) <- splitNestedLHsSigmaTys fa_ty + -> vars ++ nwcs ++ map hsLTyVarName tvs -- include kind variables only if the type is headed by forall -- (this is consistent with GHC 7 behaviour) - _ -> nwcs + _ -> nwcs hsScopedTvs :: LHsSigType GhcRn -> [Name] -- Same as hsWcScopedTvs, but for a LHsSigType hsScopedTvs sig_ty | HsIB { hsib_vars = vars, hsib_body = sig_ty2 } <- sig_ty - , L _ (HsForAllTy { hst_bndrs = tvs }) <- sig_ty2 + , fa_ty@(L _ (HsForAllTy {})) <- sig_ty2 + , (tvs, _, _) <- splitNestedLHsSigmaTys fa_ty = vars ++ map hsLTyVarName tvs | otherwise = [] @@ -953,9 +956,10 @@ mkHsAppTys = foldl mkHsAppTy -- splitHsFunType decomposes a type (t1 -> t2 ... -> tn) -- Breaks up any parens in the result type: -- splitHsFunType (a -> (b -> c)) = ([a,b], c) --- Also deals with (->) t1 t2; that is why it only works on LHsType Name +-- Also deals with (->) t1 t2; that is why it only works on NamedThings. -- (see Trac #9096) -splitHsFunType :: LHsType GhcRn -> ([LHsType GhcRn], LHsType GhcRn) +splitHsFunType :: NamedThing (IdP pass) + => LHsType pass -> ([LHsType pass], LHsType pass) splitHsFunType (L _ (HsParTy ty)) = splitHsFunType ty @@ -966,7 +970,7 @@ splitHsFunType (L _ (HsFunTy x y)) splitHsFunType orig_ty@(L _ (HsAppTy t1 t2)) = go t1 [t2] where -- Look for (->) t1 t2, possibly with parenthesisation - go (L _ (HsTyVar _ (L _ fn))) tys | fn == funTyConName + go (L _ (HsTyVar _ (L _ fn))) tys | getName fn == funTyConName , [t1,t2] <- tys , (args, res) <- splitHsFunType t2 = (t1:args, res) @@ -1044,6 +1048,7 @@ splitLHsPatSynTy ty = (univs, reqs, exis, provs, ty4) (exis, ty3) = splitLHsForAllTy ty2 (provs, ty4) = splitLHsQualTy ty3 +-- | Split a sigma type into its parts. splitLHsSigmaTy :: LHsType pass -> ([LHsTyVarBndr pass], LHsContext pass, LHsType pass) splitLHsSigmaTy ty @@ -1051,6 +1056,50 @@ splitLHsSigmaTy ty , (ctxt, ty2) <- splitLHsQualTy ty1 = (tvs, ctxt, ty2) +-- | Split a sigma type into its parts, going underneath as many 'HsForAllTy's +-- and 'HsQualTy's as possible. +-- +-- 'splitNestedLHsSigmaTys' is to 'splitLHsSigmaTy' as 'tcSplitNestedSigmaTys' +-- is to 'tcSplitSigmaTy' (from "TcType"). +splitNestedLHsSigmaTys + :: NamedThing (IdP pass) + => LHsType pass + -> ([LHsTyVarBndr pass], LHsContext pass, LHsType pass) +splitNestedLHsSigmaTys ty + -- If there's a forall or context, split it apart and try splitting the + -- rho type underneath it. + | Just (arg_tys, tvs1, L src1 theta1, rho1) <- deepSplitLHsSigmaTy_maybe ty + = let (tvs2, L src2 theta2, rho2) = splitNestedLHsSigmaTys rho1 + in ( tvs1 ++ tvs2, L (combineSrcSpans src1 src2) (theta1 ++ theta2) + , nlHsFunTys arg_tys rho2 ) + -- If there's no forall or context, we're done. + | otherwise = ([], L noSrcSpan [], ty) + where + -- These really should be imported from HsUtils, but that would lead + -- to import cycles. + nlHsFunTy :: LHsType name -> LHsType name -> LHsType name + nlHsFunTy a b = noLoc (HsFunTy a b) + + nlHsFunTys :: [LHsType name] -> LHsType name -> LHsType name + nlHsFunTys args res = foldr nlHsFunTy res args + +deepSplitLHsSigmaTy_maybe + :: NamedThing (IdP pass) + => LHsType pass + -> Maybe ( [LHsType pass], [LHsTyVarBndr pass], LHsContext pass + , LHsType pass ) +deepSplitLHsSigmaTy_maybe ty + | (arg_tys1, res_ty) <- splitHsFunType ty + , not (null arg_tys1) -- If not, splitHsFunType didn't find any arrow types + , Just (arg_tys2, tvs, theta, rho) <- deepSplitLHsSigmaTy_maybe res_ty + = Just (arg_tys1 ++ arg_tys2, tvs, theta, rho) + + | (tvs, hs_theta@(L _ theta), rho) <- splitLHsSigmaTy ty + , not (null tvs && null theta) + = Just ([], tvs, hs_theta, rho) + + | otherwise = Nothing + splitLHsForAllTy :: LHsType pass -> ([LHsTyVarBndr pass], LHsType pass) splitLHsForAllTy (L _ (HsForAllTy { hst_bndrs = tvs, hst_body = body })) = (tvs, body) splitLHsForAllTy body = ([], body) }}} Applying this patch makes that test case compile successfully. The only question is if we //should// apply the patch at all. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14288#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 19:53:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 19:53:00 -0000 Subject: [GHC] #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 In-Reply-To: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> References: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> Message-ID: <069.b70b68e8c9dd5c8a1522e982a7518db5@haskell.org> #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): In this rare case I have no preference. I assumed this is a bug, because it suddenly changed in 8.0.2. The current version indeed makes sense, e.g., if one wants different variables to be scoped differently. Are we sure that anything one can write with many foralls can be written with one forall? No edge cases with line-breaks, kinds, etc.? If so, perhaps that's a good thing to write in the manual as well. Thank you for the feedback and for the patch. You, guys, rock. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14288#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 20:16:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 20:16:53 -0000 Subject: [GHC] #14291: Tests tend to fail in the ext-interp when testing a tree built with a source distribution In-Reply-To: <046.50939ac6d09fd8ac7c487275ec7ee681@haskell.org> References: <046.50939ac6d09fd8ac7c487275ec7ee681@haskell.org> Message-ID: <061.647873f00fe510979932c521798a3ff8@haskell.org> #14291: Tests tend to fail in the ext-interp when testing a tree built with a source distribution -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.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: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): In particular only the statically-linked `iserv` is affected. `ghci -dynamic -fexternal-interpreter` appears to work fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14291#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 20:54:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 20:54:24 -0000 Subject: [GHC] #14295: tagToEnum# leads to some silly closures Message-ID: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> #14295: tagToEnum# leads to some silly closures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: datacon-tags | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I don't know how important this is in practice, but it smells pretty silly. Suppose I write {{{#!hs foo :: (Bool -> a) -> Int# -> a foo f x = f (tagToEnum# x) }}} Since `tagToEnum#` can fail, GHC compiles this to {{{#!hs foo = \ (@ a_a10v) (f_s1by [Occ=Once!] :: GHC.Types.Bool -> a_a10v) (x_s1bz [Occ=Once] :: GHC.Prim.Int#) -> let { sat_s1bA [Occ=Once] :: GHC.Types.Bool [LclId] sat_s1bA = GHC.Prim.tagToEnum# @ GHC.Types.Bool x_s1bz } in f_s1by sat_s1bA }}} That seems pretty silly! We know that `tagToEnum#` is applied to `Bool`, so we can transform this to something like {{{#!hs foo f x = case x <=# 1# of 1# -> f $! tagToEnum# x _ -> f (error "tagToEnum# was used at Bool with tag ...") }}} which avoids an extra closure at the cost of a single `Int#` comparison. The same goes for arbitrary known enumeration types. I suspect the right place to fix this up is in CorePrep. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14295> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 20:55:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 20:55:13 -0000 Subject: [GHC] #14295: tagToEnum# leads to some silly closures In-Reply-To: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> References: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> Message-ID: <060.7a4da21ac8d0939ae5ddfb39b35c75fa@haskell.org> #14295: tagToEnum# leads to some silly closures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > I don't know how important this is in practice, but it smells pretty > silly. > > Suppose I write > > {{{#!hs > foo :: (Bool -> a) -> Int# -> a > foo f x = f (tagToEnum# x) > }}} > > Since `tagToEnum#` can fail, GHC compiles this to > > {{{#!hs > foo > = \ (@ a_a10v) > (f_s1by [Occ=Once!] :: GHC.Types.Bool -> a_a10v) > (x_s1bz [Occ=Once] :: GHC.Prim.Int#) -> > let { > sat_s1bA [Occ=Once] :: GHC.Types.Bool > [LclId] > sat_s1bA = GHC.Prim.tagToEnum# @ GHC.Types.Bool x_s1bz } in > f_s1by sat_s1bA > }}} > > That seems pretty silly! We know that `tagToEnum#` is applied to `Bool`, > so we can transform this to something like > > {{{#!hs > foo f x = case x <=# 1# of > 1# -> f $! tagToEnum# x > _ -> f (error "tagToEnum# was used at Bool with tag ...") > }}} > > which avoids an extra closure at the cost of a single `Int#` comparison. > The same goes for arbitrary known enumeration types. I suspect the right > place to fix this up is in CorePrep. New description: I don't know how important this is in practice, but it looks unfortunate. Suppose I write {{{#!hs foo :: (Bool -> a) -> Int# -> a foo f x = f (tagToEnum# x) }}} Since `tagToEnum#` can fail, GHC compiles this to {{{#!hs foo = \ (@ a_a10v) (f_s1by [Occ=Once!] :: GHC.Types.Bool -> a_a10v) (x_s1bz [Occ=Once] :: GHC.Prim.Int#) -> let { sat_s1bA [Occ=Once] :: GHC.Types.Bool [LclId] sat_s1bA = GHC.Prim.tagToEnum# @ GHC.Types.Bool x_s1bz } in f_s1by sat_s1bA }}} That seems pretty bad! We know that `tagToEnum#` is applied to `Bool`, so we can transform this to something like {{{#!hs foo f x = case x <=# 1# of 1# -> f $! tagToEnum# x _ -> f (error "tagToEnum# was used at Bool with tag ...") }}} which avoids an extra closure at the cost of a single `Int#` comparison. The same goes for arbitrary known enumeration types. I suspect the right place to fix this up is in CorePrep. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14295#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 20:58:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 20:58:11 -0000 Subject: [GHC] #14295: tagToEnum# leads to some silly closures In-Reply-To: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> References: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> Message-ID: <060.1506779f2480cf29f675cd739ae75610@haskell.org> #14295: tagToEnum# leads to some silly closures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > I don't know how important this is in practice, but it looks unfortunate. > > Suppose I write > > {{{#!hs > foo :: (Bool -> a) -> Int# -> a > foo f x = f (tagToEnum# x) > }}} > > Since `tagToEnum#` can fail, GHC compiles this to > > {{{#!hs > foo > = \ (@ a_a10v) > (f_s1by [Occ=Once!] :: GHC.Types.Bool -> a_a10v) > (x_s1bz [Occ=Once] :: GHC.Prim.Int#) -> > let { > sat_s1bA [Occ=Once] :: GHC.Types.Bool > [LclId] > sat_s1bA = GHC.Prim.tagToEnum# @ GHC.Types.Bool x_s1bz } in > f_s1by sat_s1bA > }}} > > That seems pretty bad! We know that `tagToEnum#` is applied to `Bool`, so > we can transform this to something like > > {{{#!hs > foo f x = case x <=# 1# of > 1# -> f $! tagToEnum# x > _ -> f (error "tagToEnum# was used at Bool with tag ...") > }}} > > which avoids an extra closure at the cost of a single `Int#` comparison. > The same goes for arbitrary known enumeration types. I suspect the right > place to fix this up is in CorePrep. New description: I don't know how important this is in practice, but it looks unfortunate. Suppose I write {{{#!hs foo :: (Bool -> a) -> Int# -> a foo f x = f (tagToEnum# x) }}} Since `tagToEnum#` can fail, GHC compiles this to {{{#!hs foo = \ (@ a_a10v) (f_s1by [Occ=Once!] :: GHC.Types.Bool -> a_a10v) (x_s1bz [Occ=Once] :: GHC.Prim.Int#) -> let { sat_s1bA [Occ=Once] :: GHC.Types.Bool [LclId] sat_s1bA = GHC.Prim.tagToEnum# @ GHC.Types.Bool x_s1bz } in f_s1by sat_s1bA }}} That seems pretty bad! We know that `tagToEnum#` is applied to `Bool`, so we can transform this to something like {{{#!hs foo f x = case leWord# (intToWord# x) 1## of 1# -> f $! tagToEnum# x _ -> f (error "tagToEnum# was used at Bool with tag ...") }}} which avoids an extra closure at the cost of a single `Word#` comparison. The same goes for arbitrary known enumeration types. I suspect the right place to fix this up is in CorePrep. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14295#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 20:59:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 20:59:21 -0000 Subject: [GHC] #14285: Entered absent arg - triggered by INLINEABLE, regression from 8.0.2 In-Reply-To: <049.09fbd6d1ad4f0a97bcd76579dd68ae8a@haskell.org> References: <049.09fbd6d1ad4f0a97bcd76579dd68ae8a@haskell.org> Message-ID: <064.96e855a77d89bc70987c63715090ec24@haskell.org> #14285: Entered absent arg - triggered by INLINEABLE, regression from 8.0.2 ---------------------------------+-------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) Comment: I managed to bisect this down to 2effe18ab51d66474724d38b20e49cc1b8738f60 (`The Early Inline Patch`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14285#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 21:12:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 21:12:58 -0000 Subject: [GHC] #14295: tagToEnum# leads to some silly closures In-Reply-To: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> References: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> Message-ID: <060.15799d8dfde0a80f40068bd81c8c73cc@haskell.org> #14295: tagToEnum# leads to some silly closures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Specifically, any time CorePrep is tempted to produce {{{#!hs let x = tagToEnum# @KnownType y in e }}} it should pause a moment and instead produce {{{#!hs case leWord# (int2Word# y) limit of DEFAULT -> error "blah" 1# -> case tagToEnum# @KnownType y of x DEFAULT -> e }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14295#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 21:13:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 21:13:25 -0000 Subject: [GHC] #14294: IndexError: pop from empty list In-Reply-To: <048.d023a95248a740b652c7c9c06b669e05@haskell.org> References: <048.d023a95248a740b652c7c9c06b669e05@haskell.org> Message-ID: <063.f1949df6b55d0c41ac0b06abd7b0fcea@haskell.org> #14294: IndexError: pop from empty list -------------------------------------+------------------------------------- Reporter: heisenbug | 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 heisenbug): Yes. But attaching to this ticket gave the same error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14294#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 21:28:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 21:28:21 -0000 Subject: [GHC] #14295: tagToEnum# leads to some silly closures In-Reply-To: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> References: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> Message-ID: <060.eaf9ea35204fa5f6fcaaa753d917c1f5@haskell.org> #14295: tagToEnum# leads to some silly closures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Unsurprisingly, exactly the same thing is true for `quotInt#` and such. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14295#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 21:38:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 21:38:29 -0000 Subject: [GHC] #14233: Remove old GetTickCount() code path for Windows In-Reply-To: <042.60b838660adf324b88964ba3ae6d930d@haskell.org> References: <042.60b838660adf324b88964ba3ae6d930d@haskell.org> Message-ID: <057.b60edc3d4f52d54f65875504d3493232@haskell.org> #14233: Remove old GetTickCount() code path for Windows ---------------------------------+---------------------------------------- Reporter: nh2 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Ben Gamari <ben@…>): In [changeset:"9bf6310d2002ef57dc726a4d9240bd520925114d/ghc" 9bf6310d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9bf6310d2002ef57dc726a4d9240bd520925114d" Add TODO about getMonotonicNSec() wrapping that can no longer happen. Knowing this is important for followup commits, where we will subtract getProcessElapsedTime() values from each other, in a way that assumes that there is no wrapping every 49 days. Reviewers: bgamari, austin, erikd, simonmar, NicolasT Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14233 Differential Revision: https://phabricator.haskell.org/D3964 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14233#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 21:38:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 21:38:29 -0000 Subject: [GHC] #13897: Ship check-ppr in bindist and compile during testsuite run In-Reply-To: <046.c1d9498de95e82cc15e6c9fd657e4d84@haskell.org> References: <046.c1d9498de95e82cc15e6c9fd657e4d84@haskell.org> Message-ID: <061.790dc24a290e73303e01929101c4cf9d@haskell.org> #13897: Ship check-ppr in bindist and compile during testsuite run -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alanz Type: task | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Phab:D4039 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"1e9f90af7311c33de0f7f5b7dba594725596d675/ghc" 1e9f90af/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1e9f90af7311c33de0f7f5b7dba594725596d675" Move check-ppr and check-api-annotations to testsuite/utils These are needed by the testsuite and consequently must be shipped in the testsuite tarball to ensure that we can test binary distributions. See #13897. Test Plan: Validate Reviewers: austin Subscribers: snowleopard, rwbarton, thomie GHC Trac Issues: #13897 Differential Revision: https://phabricator.haskell.org/D4039 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13897#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 21:38:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 21:38:29 -0000 Subject: [GHC] #14280: Aarch64 build is broken In-Reply-To: <046.08b94a5c2943170ec3f3a9caa0180ab0@haskell.org> References: <046.08b94a5c2943170ec3f3a9caa0180ab0@haskell.org> Message-ID: <061.9c14b6e04ffae9ee8328147cc39e53da@haskell.org> #14280: Aarch64 build is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"a10729f028d7175980d9f65e22c9bb9a933461c2/ghc" a10729f0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a10729f028d7175980d9f65e22c9bb9a933461c2" configure: Make sure we try all possible linkers Previously if we had both ld.lld and ld.gold installed but a gcc which didn't support -fuse-ld=lld we would fail when trying ld.lld and fall immediately back to plain ld. Now we will try ld.gold as well. This was brought to light by #14280, where using ld.bfd resulted in a broken stage2 compiler. Test Plan: Configure Reviewers: angerman, hvr, austin Reviewed By: angerman Subscribers: rwbarton, thomie, erikd GHC Trac Issues: #14280 Differential Revision: https://phabricator.haskell.org/D4038 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14280#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Sep 27 23:16:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Sep 2017 23:16:57 -0000 Subject: [GHC] #14292: Coercing between constraints of newtypes In-Reply-To: <051.e9d001b6d6e7069b1e2d96a31ac34922@haskell.org> References: <051.e9d001b6d6e7069b1e2d96a31ac34922@haskell.org> Message-ID: <066.9d2cab7eef7ceb14436c0fc035cf027c@haskell.org> #14292: Coercing between constraints of newtypes -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): `IncoherentInstances` is a module-wide setting; and nowadays we're supposed to use the more surgical `{-# INCOHERENT #-}` pragma on the instance. Does that also apply for the role mungling? How does the `{-# INCOHERENT #-}` pragma go for `StandaloneDeriving` or `GeneralizedNewtypeDeriving`? It seems to be accepted by GHC OK, does it have the right effect? (It's hard to put together a test case.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14292#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 00:46:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 00:46:02 -0000 Subject: [GHC] #14291: Tests tend to fail in the ext-interp way when split sections is enabled (was: Tests tend to fail in the ext-interp when testing a tree built with a source distribution) In-Reply-To: <046.50939ac6d09fd8ac7c487275ec7ee681@haskell.org> References: <046.50939ac6d09fd8ac7c487275ec7ee681@haskell.org> Message-ID: <061.4dfcd4ae39561c3e1c45f16444a9242e@haskell.org> #14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.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: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > One issue I've noticed while working on #13716 is that most (if not all) > of the tests runs in the `ext-interp` way fail when run inside a tree > derived from a source distribution tarball. For instance, > {{{ > $ git clone git://git.haskell.org/ghc > $ cd ghc > $ git submodule update --init > $ mk/get-win32-tarballs.sh download all > $ ./boot > $ ./configure > $ make sdist > $ mkdir tmp; cd tmp > $ ls ../sdistprep/ghc-*-src.tar.xz | xargs -n1 tar -xf > $ cd ghc-* > $ ./boot > $ ./configure > $ make -j9 > $ make test TEST=T10638 > ... > =====> T10638(normal) 1 of 1 [0, 0, 0] > cd "./th/T10638.run" && "/mnt/work/ghc/ghc- > testing/temp/ghc-8.3.20170927/inplace/bin/ghc-stage2" -c T10638.hs > -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- > specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- > diagnostics-show-caret -dno-debug-output -XTemplateHaskell -package > template-haskell -v0 > =====> T10638(ext-interp) 1 of 1 [0, 0, 0] > cd "./th/T10638.run" && "/mnt/work/ghc/ghc- > testing/temp/ghc-8.3.20170927/inplace/bin/ghc-stage2" -c T10638.hs > -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- > specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- > diagnostics-show-caret -dno-debug-output -XTemplateHaskell -package > template-haskell -fexternal-interpreter -v0 > Actual stderr output differs from expected: > diff -uw "./th/T10638.run/T10638.stderr.normalised" > "./th/T10638.run/T10638.comp.stderr.normalised" > --- ./th/T10638.run/T10638.stderr.normalised 2017-09-27 > 12:18:45.737974039 -0400 > +++ ./th/T10638.run/T10638.comp.stderr.normalised 2017-09-27 > 12:18:45.737974039 -0400 > @@ -1,5 +1,18 @@ > +ghc-iserv.bin: internal evacuate(static): strange closure type 16476 > + (GHC version 8.3.20170927 for x86_64_unknown_linux) > + Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > > -T10638.hs:26:11: > - ‘static test2’ is not a valid C identifier > - When checking declaration: > - foreign import prim safe "static test2" cmm_test2 :: Int# -> Int# > +T10638.hs:26:9: > + Exception when trying to run compile-time code: > + {handle: <file descriptor: 11>}: GHCi.Message.remoteCall: end of > file > + Code: do t <- [t| Int# -> Int# |] > + cmm_test2 <- newName "cmm_test2" > + addTopDecls > + [ForeignD (ImportF Prim Safe "static test2" cmm_test2 > t)] > + .... > + In the untyped splice: > + $(do t <- [t| Int# -> Int# |] > + cmm_test2 <- newName "cmm_test2" > + addTopDecls > + [ForeignD (ImportF Prim Safe "static test2" cmm_test2 t)] > + [| test1 |]) > *** unexpected failure for T10638(ext-interp) > > Unexpected results from: > TEST="T10638" > ... > }}} > > The crashes are generally RTS panics or segmentation faults. New description: One issue I've noticed while working on #13716 is that most (if not all) of the tests runs in the `ext-interp` way fail when run with a compiler built with `SplitSections=YES`. {{{ $ git clone git://git.haskell.org/ghc $ cd ghc $ git submodule update --init $ mk/get-win32-tarballs.sh download all $ ./boot $ ./configure $ make sdist $ mkdir tmp; cd tmp $ ls ../sdistprep/ghc-*-src.tar.xz | xargs -n1 tar -xf $ cd ghc-* $ ./boot $ ./configure $ make -j9 $ make test TEST=T10638 ... =====> T10638(normal) 1 of 1 [0, 0, 0] cd "./th/T10638.run" && "/mnt/work/ghc/ghc- testing/temp/ghc-8.3.20170927/inplace/bin/ghc-stage2" -c T10638.hs -dcore- lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output -XTemplateHaskell -package template-haskell -v0 =====> T10638(ext-interp) 1 of 1 [0, 0, 0] cd "./th/T10638.run" && "/mnt/work/ghc/ghc- testing/temp/ghc-8.3.20170927/inplace/bin/ghc-stage2" -c T10638.hs -dcore- lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output -XTemplateHaskell -package template-haskell -fexternal-interpreter -v0 Actual stderr output differs from expected: diff -uw "./th/T10638.run/T10638.stderr.normalised" "./th/T10638.run/T10638.comp.stderr.normalised" --- ./th/T10638.run/T10638.stderr.normalised 2017-09-27 12:18:45.737974039 -0400 +++ ./th/T10638.run/T10638.comp.stderr.normalised 2017-09-27 12:18:45.737974039 -0400 @@ -1,5 +1,18 @@ +ghc-iserv.bin: internal evacuate(static): strange closure type 16476 + (GHC version 8.3.20170927 for x86_64_unknown_linux) + Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -T10638.hs:26:11: - ‘static test2’ is not a valid C identifier - When checking declaration: - foreign import prim safe "static test2" cmm_test2 :: Int# -> Int# +T10638.hs:26:9: + Exception when trying to run compile-time code: + {handle: <file descriptor: 11>}: GHCi.Message.remoteCall: end of file + Code: do t <- [t| Int# -> Int# |] + cmm_test2 <- newName "cmm_test2" + addTopDecls + [ForeignD (ImportF Prim Safe "static test2" cmm_test2 t)] + .... + In the untyped splice: + $(do t <- [t| Int# -> Int# |] + cmm_test2 <- newName "cmm_test2" + addTopDecls + [ForeignD (ImportF Prim Safe "static test2" cmm_test2 t)] + [| test1 |]) *** unexpected failure for T10638(ext-interp) Unexpected results from: TEST="T10638" ... }}} The crashes are generally RTS panics or segmentation faults. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14291#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 00:46:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 00:46:28 -0000 Subject: [GHC] #14292: Coercing between constraints of newtypes In-Reply-To: <051.e9d001b6d6e7069b1e2d96a31ac34922@haskell.org> References: <051.e9d001b6d6e7069b1e2d96a31ac34922@haskell.org> Message-ID: <066.10b95be4a1ee09923d95601cdd6dae36@haskell.org> #14292: Coercing between constraints of newtypes -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:3 AntC]: > `IncoherentInstances` is a module-wide setting; and nowadays deprecated in favour of the more surgical `{-# INCOHERENT #-}` pragma on the instance. > > Does that also apply for the role mungling? As far as I know, you do need to enable the `IncoherentInstances` extension proper in order to assign non-nominal roles to class parameters, as the `{-# INCOHERENT #-}` pragma only works for instance declarations, not class declarations. (This might be partly why you don't get a deprecation warning when enabling `IncoherentInstances`, but you do with `OverlappingInstances`, which doesn't have a dual purpose like `IncoherentInstances` does.) > How does the `{-# INCOHERENT #-}` pragma go for `StandaloneDeriving` or `GeneralizedNewtypeDeriving`? It seems to be accepted by GHC OK, does it have the right effect? (It's hard to put together a test case.) I'm not sure I understand the question. Derived instances never use `{-# INCOHERENT #-}` (or even `{-# OVERLAPS #-}`/`{-# OVERLAPPING #-}`/`{-# OVERLAPPABLE #-}`, for that matter) in their emitted code, if that's what you're wondering. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14292#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 00:57:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 00:57:38 -0000 Subject: [GHC] #13897: Ship check-ppr in bindist and compile during testsuite run In-Reply-To: <046.c1d9498de95e82cc15e6c9fd657e4d84@haskell.org> References: <046.c1d9498de95e82cc15e6c9fd657e4d84@haskell.org> Message-ID: <061.2afb56bfd7c03cca8425d0c2b2d5738c@haskell.org> #13897: Ship check-ppr in bindist and compile during testsuite run -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alanz Type: task | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Phab:D4039 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This also needs to be done in Hadrian. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13897#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 00:57:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 00:57:46 -0000 Subject: [GHC] #14280: Aarch64 build is broken In-Reply-To: <046.08b94a5c2943170ec3f3a9caa0180ab0@haskell.org> References: <046.08b94a5c2943170ec3f3a9caa0180ab0@haskell.org> Message-ID: <061.f0bc83b34c5159c072cdbf6a98d28c94@haskell.org> #14280: Aarch64 build is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14280#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 01:02:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 01:02:44 -0000 Subject: [GHC] #14284: -Weverything is undocumented In-Reply-To: <045.9f4cfb2606fbf67e7f4d80b618b36bf9@haskell.org> References: <045.9f4cfb2606fbf67e7f4d80b618b36bf9@haskell.org> Message-ID: <060.0e78aeb057c9961345870a1043e15d15@haskell.org> #14284: -Weverything is undocumented -------------------------------------+------------------------------------- Reporter: refold | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Documentation | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab;D4043 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab;D4043 * milestone: => 8.4.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14284#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 02:03:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 02:03:32 -0000 Subject: [GHC] #14291: Tests tend to fail in the ext-interp way when split sections is enabled In-Reply-To: <046.50939ac6d09fd8ac7c487275ec7ee681@haskell.org> References: <046.50939ac6d09fd8ac7c487275ec7ee681@haskell.org> Message-ID: <061.b1475ab0d5ede043175d49dcef6148b3@haskell.org> #14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.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: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Bisection log within `rts/`, {{{ $ git bisect log git bisect start 'rts' # bad: [4364f1e7543b6803cfaef321105d253e0bdf08a4] Typofixes git bisect bad 4364f1e7543b6803cfaef321105d253e0bdf08a4 # good: [2b5b9dc69e5d0af20b6e7be31638c2e3a1bb765f] Fix typo in base changelog git bisect good 2b5b9dc69e5d0af20b6e7be31638c2e3a1bb765f # good: [bea18a0e9ea5ff2063ca4900acad9995f40276eb] Fix GCC 7 warning in the RTS git bisect good bea18a0e9ea5ff2063ca4900acad9995f40276eb # bad: [ee2e9ece388e75ac433097ac726a555a07ae0830] Correct incorrect free in PE linker git bisect bad ee2e9ece388e75ac433097ac726a555a07ae0830 # bad: [3eeb55e9578f6eaebccf27170eb1324990affb51] rts/sm/Storage.c: tweak __clear_cache proto for clang git bisect bad 3eeb55e9578f6eaebccf27170eb1324990affb51 # good: [1e471265c1ea9b2c4e9709adc182c36d0635f071] rts: Clarify whitehole logic in threadPaused git bisect good 1e471265c1ea9b2c4e9709adc182c36d0635f071 # bad: [a6f3d1b00e9c37a56cd4db9e519309e94a65d181] rts: Fix isByteArrayPinned#'s treatment of large arrays git bisect bad a6f3d1b00e9c37a56cd4db9e519309e94a65d181 # bad: [f9c6d53fe997f1c560cda6f346f4b201711df37c] Tag the FUN before making a PAP (#13767) git bisect bad f9c6d53fe997f1c560cda6f346f4b201711df37c # bad: [9b514dedf090c5e21e3be38d174cf1390e21879f] rts/RetainerProfile: Const-correctness fixes git bisect bad 9b514dedf090c5e21e3be38d174cf1390e21879f # first bad commit: [9b514dedf090c5e21e3be38d174cf1390e21879f] rts/RetainerProfile: Const-correctness fixes }}} Unfortunately it looks like the problem isn't in `rts/`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14291#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 06:13:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 06:13:15 -0000 Subject: [GHC] #14292: Coercing between constraints of newtypes In-Reply-To: <051.e9d001b6d6e7069b1e2d96a31ac34922@haskell.org> References: <051.e9d001b6d6e7069b1e2d96a31ac34922@haskell.org> Message-ID: <066.ef90f6fa6c92f230210a70387a6174c9@haskell.org> #14292: Coercing between constraints of newtypes -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:4 RyanGlScott]: > > `IncoherentInstances` is a module-wide setting; and nowadays deprecated in favour of the more surgical `{-# INCOHERENT #-}` pragma on the instance. > > > > Does that also apply for the role mungling? > > As far as I know, you do need to enable the `IncoherentInstances` extension proper in order to assign non-nominal roles to class parameters, Thanks Ryan, yes that's what the User Guide says -- if I look up about Roles, section 9.36. Then BTW the User Guide for `IncoherentInstances` section 9.8.3.6 doesn't mention it has anything to do with Roles, but only with Overlaps. Likewise the doco for `-XIncoherentInstances` compiler flag section 6.6.12; which also implies `XOverlappingInstances`. Does it? > as the `{-# INCOHERENT #-}` pragma only works for instance declarations, not class declarations. (This might be partly why you don't get a deprecation warning when enabling `IncoherentInstances`, but you do with `OverlappingInstances`, which doesn't have a dual purpose like `IncoherentInstances` does.) Hmm. Certainly you could say that `IncoherentInstances` is a poor choice of name if what it means is `IncoherentOverlaps`. Giving it a "dual purpose" seems like asking for trouble. Why wasn't there a new flag for `IncoherentInstanceRoles`? (And "dual purpose" seems in violation of the principles in the debate just going on about derived instances for `EmptyDataDecls`.) . > > > How does the `{-# INCOHERENT #-}` pragma go for `StandaloneDeriving` or `GeneralizedNewtypeDeriving`? It seems to be accepted by GHC OK, does it have the right effect? (It's hard to put together a test case.) > > I'm not sure I understand the question. Derived instances never use `{-# INCOHERENT #-}` (or even `{-# OVERLAPS #-}`/`{-# OVERLAPPING #-}`/`{-# OVERLAPPABLE #-}`, for that matter) in their emitted code, ... I managed to get GHC to accept Standalone {{{ deriving instance {-# INCOHERENT #-} Num USD }}} I think you're saying: that pragma would be ignored; wouldn't enable the incoherent Role (in absence of `IncoherentInstances` on the module); would complain if that instance overlaps. OK there couldn't be an overlap for USD; let's say `deriving instance {-# INCOHERENT #-} Num a => Num (N a)` where there's also a hand-crafted `instance {-# OVERLAPS #-} Num (N Int) where ...`, for `newtype N a`. If the module has `IncoherentInstances`, do both those instances get accepted even without the pragmas? (Or perhaps a more devious scenario where one of the instances is imported.) > ... if that's what you're wondering. I'm wondering about the combination of these "dual purposes". Suppose I want GHC to trust the Roles on my instances; but I don't want instances to overlap. That is, if I by accident write instances that overlap, I want GHC to reject them. Thinking out loud: I perhaps want the effect of `IncoherentInstances` on the module (to get Role mungling); but `{-# NOOVERLAPS #-}` on the instance -- no such pragma at the moment. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14292#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 06:55:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 06:55:27 -0000 Subject: [GHC] #14292: Coercing between constraints of newtypes In-Reply-To: <051.e9d001b6d6e7069b1e2d96a31ac34922@haskell.org> References: <051.e9d001b6d6e7069b1e2d96a31ac34922@haskell.org> Message-ID: <066.b50bf195548a98a1940326d9dde0968a@haskell.org> #14292: Coercing between constraints of newtypes -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:5 AntC]: > If the module has `IncoherentInstances`, do both those instances get accepted even without the pragmas? (Or perhaps a more devious scenario where one of the instances is imported.) > Yes, here we go: {{{ {-# LANGUAGE GeneralizedNewtypeDeriving, StandaloneDeriving, FlexibleInstances, IncoherentInstances #-} main = print $ MkN (7 :: Int) + MkN 5 newtype N a = MkN a deriving (Show) instance Num a => Num (N a) where MkN x + MkN y = MkN (x - y) deriving instance Num (N Int) }}} Without `IncoherentInstances` the `MkN 7 + MkN 5` is rejected: overlapping instances [good! that's what I want]. With `IncoherentInstances`, this is accepted and prints `12`. If I switch round the instance decls such that the hand-crafted one is for `Num (N Int)` and the derived is for `Num (N a)`, this prints `2`. Ugh! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14292#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 07:43:57 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 07:43:57 -0000 Subject: [GHC] #14292: Coercing between constraints of newtypes In-Reply-To: <051.e9d001b6d6e7069b1e2d96a31ac34922@haskell.org> References: <051.e9d001b6d6e7069b1e2d96a31ac34922@haskell.org> Message-ID: <066.3005530bec21283541f8cda03294a3e8@haskell.org> #14292: Coercing between constraints of newtypes -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think the right thing to do here is to use a different flag for the "allow a representational role annotation on a class", or better yet to make it a per-role-annotation flag. Using `IncoherentInstances` for ''both'' that ''and'' the old meaning is asking for trouble. I think we could make this change without hurting anyone much, because I bet that almost no one uses a representational role annotation on a class! (One other thought. Allowing per-decl things like `{-# OVERLAPS #-}` means you can't look at the top of the file and see what extensions it uses. Really we should have a language extensions `{-# LANGUAGE OverlapsAllowed #-}` or something, which enables the per-decl pragmas. Doing that ''would'' have a bigger impact!) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14292#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 07:55:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 07:55:20 -0000 Subject: [GHC] #14295: tagToEnum# leads to some silly closures In-Reply-To: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> References: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> Message-ID: <060.2af614f513481682a2cb38b1990e8b5d@haskell.org> #14295: tagToEnum# leads to some silly closures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think we can do better. Add a `BuiltInRule` for `tagToEnum#`. {{{ tagToEnum# Bool ===> \x -> case x of 0# -> False 1# -> True DEFAULT -> error "blah" }}} The rule can fire whenever `tagToEnum#` is applied to a known type, albeit perhaps one without too many constructors. It's a bit like inlining `tagToEnum#`. }}} The built-in rule mechanism works well; we can use it here too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14295#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 07:55:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 07:55:44 -0000 Subject: [GHC] #14295: tagToEnum# leads to some silly closures In-Reply-To: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> References: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> Message-ID: <060.f7e13ad1e30cd66a5810d89a314e4bbd@haskell.org> #14295: tagToEnum# leads to some silly closures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Unsurprisingly, exactly the same thing is true for quotInt# and such. I don't understand. Can you explain? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14295#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 08:09:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 08:09:31 -0000 Subject: [GHC] #14295: tagToEnum# leads to some silly closures In-Reply-To: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> References: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> Message-ID: <060.164388bc52e2efbe2979eb52404f2885@haskell.org> #14295: tagToEnum# leads to some silly closures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:6 simonpj]: > > Unsurprisingly, exactly the same thing is true for quotInt# and such. > > I don't understand. Can you explain? {{{#!hs foo :: (Int -> a) -> Int# -> Int# -> a foo f x y = f (I# (quotInt# x y)) }}} will suspend the division for fear of a zero denominator. We can fix that similarly by testing for 0 and forcing the division in the good branch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14295#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 08:11:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 08:11:54 -0000 Subject: [GHC] #14295: tagToEnum# leads to some silly closures In-Reply-To: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> References: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> Message-ID: <060.95d01ec9cce20473f15ddc7bd1aecf52@haskell.org> #14295: tagToEnum# leads to some silly closures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:5 simonpj]: > I think we can do better. Add a `BuiltInRule` for `tagToEnum#`. > {{{ > tagToEnum# Bool > ===> > \x -> case x of > 0# -> False > 1# -> True > DEFAULT -> error "blah" > }}} > The rule can fire whenever `tagToEnum#` is applied to a known type, albeit perhaps one without too many constructors. It's a bit like inlining `tagToEnum#`. > }}} > The built-in rule mechanism works well; we can use it here too. Yes, I thought about that too. But it's probably really only a good idea if there aren't many constructors; otherwise we're inlining too much. When we don't inline, we should still perform a bounds check to avoid the thunk, no? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14295#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 08:12:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 08:12:14 -0000 Subject: [GHC] #14295: tagToEnum# leads to some silly closures In-Reply-To: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> References: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> Message-ID: <060.9191b9e3c8b0c9ca4326a0ff8c8708da@haskell.org> #14295: tagToEnum# leads to some silly closures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Really? I get {{{ ==================== STG syntax: ==================== Foo.foo :: forall a. (GHC.Types.Int -> a) -> GHC.Prim.Int# -> GHC.Prim.Int# -> a [GblId, Arity=3, Caf=NoCafRefs, Unf=OtherCon []] = \r [f_s1av x_s1aw y_s1ax] let { sat_s1az [Occ=Once] :: GHC.Types.Int [LclId] = \u [] case quotInt# [x_s1aw y_s1ax] of wild_s1ay { __DEFAULT -> GHC.Types.I# [wild_s1ay]; }; } in f_s1av sat_s1az; }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14295#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 08:16:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 08:16:27 -0000 Subject: [GHC] #14295: tagToEnum# leads to some silly closures In-Reply-To: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> References: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> Message-ID: <060.bd637628b8290190ca62047f6f167ec4@haskell.org> #14295: tagToEnum# leads to some silly closures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Am I reading that wrong? I thought the outer `let` was suspending that whole thing. Compare it to the modified version. I'm going to sleep shortly, do I can't post the comparison right now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14295#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 08:22:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 08:22:36 -0000 Subject: [GHC] #14295: tagToEnum# leads to some silly closures In-Reply-To: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> References: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> Message-ID: <060.c64acea31941ac113bafe8f0f4c230be@haskell.org> #14295: tagToEnum# leads to some silly closures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > When we don't inline, we should still perform a bounds check to avoid the thunk, no? Good point. I suppose so... but * If we did this we'd better give a different name to the primop that can't fail; otherwise the transformation is plain confusing. * I'm uncomfortable with transformations that are not readily expressed in Core. E.g. we could have {{{ case x of 0# -> blah DEFAULT -> ...(noFailQuotInt# y x)... }}} since we know that `x` is non-zero in the default branch. But then we might float the subexpression out, and the claim would no longer hold. We don't have a solid way to prevent this. So yes one could do it as a `CorePrep` tactic, but it's delicate; and we risk not getting the benefits because we don't implement the follow-on transformations. * I doubt it's worth doing in practice. i.e. the same engineering effort spent elsewhere might yield more benefit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14295#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 09:44:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 09:44:22 -0000 Subject: [GHC] #13707: xmobar crashes with segmentation faults? In-Reply-To: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> References: <046.fbf7af7bdea4e00dc6b71cd4d89ec01e@haskell.org> Message-ID: <061.3113d229c3c5ea805f18f0b61e9b9878@haskell.org> #13707: xmobar crashes with segmentation faults? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc2 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 Rufflewind): Okay, so I think I've found a semi-reliable way to reproduce the bug without waiting days. You need to have two X screens (you can also have one X screen and one Linux terminal instead, but I got the impression that crashes are less reliable that way). Suppose you have one screen on TTY1 (Ctrl+Alt+F2) and another on TTY2 (Ctrl+Alt+F2). I found the that if I have xmobar on one of them and repeatedly spam Ctrl+Alt+F1 and Ctrl+Alt+F2 (*) to switch the screens back and forth, I can occasionally reproduce the crash. What I did essentially was to load 10 instances of xmobar and then switch screens repeatedly, and I could get it to crash fairly often. In one particular run of 100 attempts, it crashed on the attempt 3, 5, 6, 10, 20, 21, 21, 22, 33, 53, 54, 60, 60, 62, 69, 83, 85. Two of the instances crashed one after the other on 21 and 60. Therefore I conclude it has about a 2% chance of crashing each time the screen gets blanked. I think the bug has something to do with screen blanking / switching. In retrospect, I think the reason I often discover this bug overnight is because my screensaver blanks out the screen while I'm away, so that has a small chance of triggering the bug. The xmobar configuration seems irrelevant for the most part. I could reproduce this with the default config. (*) You'll have to fully release the Ctrl and Alt keys between each hit, or else Linux will fail to interpret the key correctly. Given that I'm able to reproduce a wide variety of stack traces, I think these errors are all somewhat related in cause despite the apparent ways in which they crash. I even got a crash like this: {{{ xmobar: internal error: evacuate: strange closure type 4689 (GHC version 8.3.20170927 for x86_64_unknown_linux) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13707#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 10:26:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 10:26:45 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.7a37f5074bbd2683750fdb77eaec32ee@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What's the status here Joachim? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14068#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 10:27:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 10:27:17 -0000 Subject: [GHC] #13966: Skip-less stream fusion: a missed opportunity In-Reply-To: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> References: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> Message-ID: <063.d2efed4dd4cef033de041fe0975559b7@haskell.org> #13966: Skip-less stream fusion: a missed opportunity -------------------------------------+------------------------------------- Reporter: jmspiewak | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints, | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14067 #14068 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm getting lost. > Implementing this leads to * What exactly is "this"? * Does `chain1` have "this" implemented? Or `chain2`? * Which do you think is most desirable, and why? (`chain2` looks simpler.) * Are you assuming loopification #14068 is done? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13966#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 10:32:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 10:32:12 -0000 Subject: [GHC] #11342: Character kind In-Reply-To: <048.855ee5d87e4065ad6e74a034645189d9@haskell.org> References: <048.855ee5d87e4065ad6e74a034645189d9@haskell.org> Message-ID: <063.db30d403f2cdefb9e69354e66ed51e54@haskell.org> #11342: Character kind -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: alexvieth Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: DataKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10776, #12162 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vagarenko): * cc: vagarenko (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11342#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 10:36:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 10:36:37 -0000 Subject: [GHC] #14287: Early inlining causes potential join points to be missed In-Reply-To: <044.afeda1d17d7fca2451446457f502779c@haskell.org> References: <044.afeda1d17d7fca2451446457f502779c@haskell.org> Message-ID: <059.b8ca3357ea46fedd5a7550e9bf207fd4@haskell.org> #14287: Early inlining causes potential join points to be missed -------------------------------------+------------------------------------- Reporter: jheek | 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 mpickering): Another way to make the program faster is to write {{{ sfilter3 :: (a -> Bool) -> Stream s a -> Stream s a sfilter3 pred (Stream step s0) = Stream filterStep s0 where filterStep s = let go s = case step s of Done -> Done Yield x ns | pred x -> Yield x ns | otherwise -> go ns in go s }}} or to perform the transformation described by Simon in #13966. Both leads to precisely the same core as the `INLINE [2]` version. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14287#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 11:00:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 11:00:26 -0000 Subject: [GHC] #13966: Skip-less stream fusion: a missed opportunity In-Reply-To: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> References: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> Message-ID: <063.30d8648f65b7a6f439c569eb19ed24eb@haskell.org> #13966: Skip-less stream fusion: a missed opportunity -------------------------------------+------------------------------------- Reporter: jmspiewak | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints, | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14067 #14068 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Here is the exact file I am using. {{{ {-# LANGUAGE ExistentialQuantification #-} module Main where import GHC.Prim import Criterion.Main import GHC.Prim main :: IO () main = defaultMain [b1, b2] where b1 = bench "Skip-less" $ whnf chain1 x b2 = bench "Skip" $ whnf chain2 x x = 100000000 -------------------------------------------------------------------------------- data Step1 s a = Done1 | Yield1 s a data Stream1 a = forall s. Stream1 s (s -> Step1 s a) enumFromTo1 :: (Ord a, Num a) => a -> a -> Stream1 a enumFromTo1 start high = Stream1 start f where f i | i > high = Done1 | otherwise = Yield1 (i + 1) i filter1 :: (a -> Bool) -> Stream1 a -> Stream1 a filter1 predicate (Stream1 s0 next) = Stream1 s0 loop where loop s = case next s of Done1 -> Done1 Yield1 s' x | predicate x -> Yield1 s' x | otherwise -> loop s' sum1 :: Num a => Stream1 a -> a sum1 (Stream1 s0 next) = loop 0 s0 where loop total s = case next s of Done1 -> total Yield1 s' x -> loop (total + x) s' chain1 :: Int -> Int chain1 = sum1 . filter1 even . enumFromTo1 1 -------------------------------------------------------------------------------- data Step2 s a = Done2 | Skip2 s | Yield2 s a data Stream2 a = forall s. Stream2 s (s -> Step2 s a) enumFromTo2 :: (Ord a, Num a) => a -> a -> Stream2 a enumFromTo2 start high = Stream2 start f where f i | i > high = Done2 | otherwise = Yield2 (i + 1) i filter2 :: (a -> Bool) -> Stream2 a -> Stream2 a filter2 predicate (Stream2 s0 next) = Stream2 s0 loop where loop s = case next s of Done2 -> Done2 Skip2 s' -> Skip2 s' Yield2 s' x | predicate x -> Yield2 s' x | otherwise -> Skip2 s' sum2 :: Num a => Stream2 a -> a sum2 (Stream2 s0 next) = loop 0 s0 where loop total s = case next s of Done2 -> total Skip2 s' -> loop total s' Yield2 s' x -> loop (total + x) s' chain2 :: Int -> Int chain2 = sum2 . filter2 even . enumFromTo2 1 }}} I modified the SAT pass to ignore information about static arguments, perform the SAT transformation and then check whether we created a join point. If we create a join point then we keep the transformed version, otherwise we leave the code as it was. (This is what you suggested in comment:8) I then compiled the above program with this transformation turned on. `chain2` was unaffected, the core is as before but the core for `chain1` changed quite a bit. It seems from running the benchmarks that `chain1` is better but I didn't look yet why this might be the case. I am building from a recent HEAD (11d9615e9f751d6ed084f1cb20c24ad6b408230e) so whether loopification is in there or not I don't know. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13966#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 11:30:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 11:30:55 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.49e4766646d106868b24345054b96c5f@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Joachim has said that Phab:D3811 is ready for review. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14068#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 12:02:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 12:02:53 -0000 Subject: [GHC] #13966: Skip-less stream fusion: a missed opportunity In-Reply-To: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> References: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> Message-ID: <063.b03ca13545888bab1e51dab811631cea@haskell.org> #13966: Skip-less stream fusion: a missed opportunity -------------------------------------+------------------------------------- Reporter: jmspiewak | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints, | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14067 #14068 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I read #14068 now which I thought the whole point of this ticket was? What is the difference meant to be? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13966#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 12:10:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 12:10:39 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.238828fde7f323b7fb864bf4c85ad659@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3903 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D3811 => Phab:D3903 Comment: Phab:D3811 has been abandoned in favor of Phab:D3903. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14068#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 12:15:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 12:15:12 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.80680ba96167f5ee754a935e7c3ac720@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D3903 => Phab:D3811 Comment: Never mind, Phab:D3811 was broader in scope than just the exitification work in Phab:D3903. Only Joachim knows the status of the broader loopification work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14068#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 12:21:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 12:21:51 -0000 Subject: [GHC] #13966: Skip-less stream fusion: a missed opportunity In-Reply-To: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> References: <048.658094e04650fa97f55165f5bc2ec9a8@haskell.org> Message-ID: <063.e0f1ad3d5c7e68c93951ed8dc0aee819@haskell.org> #13966: Skip-less stream fusion: a missed opportunity -------------------------------------+------------------------------------- Reporter: jmspiewak | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: JoinPoints, | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14067 #14068 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): To summarize (excerpting from comment:8), this ticket consists of two parts, * #14067: Transforming a tail-recursive function into a non-recursive function with a joinrec. * #14068: SAT for tail-recursive functions It might be best to keep specific discussion on those tickets where possible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13966#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 13:24:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 13:24:43 -0000 Subject: [GHC] #13497: GHC does not use select()/poll() correctly on non-Linux platforms In-Reply-To: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> References: <042.1128e10ab8554fd96dc5544fa1537019@haskell.org> Message-ID: <057.80e125ee593940001492d9487a190238@haskell.org> #13497: GHC does not use select()/poll() correctly on non-Linux platforms -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8684 Related Tickets: #8684, #12912 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by nh2: Old description: > From my discovery at https://phabricator.haskell.org/D42#30542: > > {{{ > Why does the existing code work on platforms that are not Linux? In my > select man page it says: > > On Linux, select() modifies timeout to reflect the amount of time not > slept; most other implementations do not do this. (POSIX.1-2001 per‐ > mits either behavior.) This causes problems both when Linux code which > reads timeout is ported to other operating systems, and when code is > ported to Linux that reuses a struct timeval for multiple select()s in > a loop without reinitializing it. Consider timeout to be undefined > after select() returns. > > The existing select loop seems to rely on the fact that &tv is updated as > described here. > }}} > > Same for `man 2 poll`. > > E.g. `man 2 select` on FreeBSD 11 says explicitly: > > {{{ > BUGS > Version 2 of the Single UNIX Specification (``SUSv2'') allows > systems to > modify the original timeout in place. Thus, it is unwise to assume > that > the timeout value will be unmodified by the select() system call. > FreeBSD does not modify the return value, which can cause problems > for > applications ported from other systems. > }}} > > I have tested this now on FreeBSD, and indeed it doesn't work as > expected. > > With GHC 7.10.2: > > {{{ > import System.IO > main = hWaitForInput stdin (1 * 1000) > }}} > > `ghc --make test.hs -rtsopts` > > {{{ > [root@ ~]# time ./test > > real 0m1.386s > user 0m0.004s > sys 0m0.000s > [root@ ~]# time ./test +RTS -V0.01 > > real 0m1.386s > user 0m0.001s > sys 0m0.000s > [root@ ~]# time ./test +RTS -V0.001 > > real 0m1.678s > user 0m0.003s > sys 0m0.002s > [root@ ~]# time ./test +RTS -V0.0001 > > real 0m11.311s > user 0m0.032s > sys 0m0.139s > }}} > > See how when we increase the timer signal, the sleep suddenly takes 10x > longer than it should. > > That's because it triggers the case where EINTR is received in > https://github.com/ghc/ghc/blob/f46369b8a1bf90a3bdc30f2b566c3a7e03672518%5E/libraries/base/cbits/inputReady.c#L48, > letting us use the same unmodified 1-second `struct timeval *timeout` > again and again. > > This demo of the bug works for GHC 7.10 and 8.0.1; in 8.0.2 > `hWaitForInput` is broken > (https://ghc.haskell.org/trac/ghc/ticket/12912#comment:4) so the demo > doesn't work there. New description: From my discovery at https://phabricator.haskell.org/D42#30542: {{{ Why does the existing code work on platforms that are not Linux? In my select man page it says: On Linux, select() modifies timeout to reflect the amount of time not slept; most other implementations do not do this. (POSIX.1-2001 per‐ mits either behavior.) This causes problems both when Linux code which reads timeout is ported to other operating systems, and when code is ported to Linux that reuses a struct timeval for multiple select()s in a loop without reinitializing it. Consider timeout to be undefined after select() returns. The existing select loop seems to rely on the fact that &tv is updated as described here. }}} Same for `man 2 poll`. E.g. `man 2 select` on FreeBSD 11 says explicitly: {{{ BUGS Version 2 of the Single UNIX Specification (``SUSv2'') allows systems to modify the original timeout in place. Thus, it is unwise to assume that the timeout value will be unmodified by the select() system call. FreeBSD does not modify the return value, which can cause problems for applications ported from other systems. }}} I have tested this now on FreeBSD, and indeed it doesn't work as expected. With GHC 7.10.2: {{{ import System.IO main = hWaitForInput stdin (1 * 1000) }}} `ghc --make test.hs -rtsopts` {{{ [root@ ~]# time ./test real 0m1.386s user 0m0.004s sys 0m0.000s [root@ ~]# time ./test +RTS -V0.01 real 0m1.386s user 0m0.001s sys 0m0.000s [root@ ~]# time ./test +RTS -V0.001 real 0m1.678s user 0m0.003s sys 0m0.002s [root@ ~]# time ./test +RTS -V0.0001 real 0m11.311s user 0m0.032s sys 0m0.139s }}} See how when we increase the timer signal, the sleep suddenly takes 10x longer than it should. That's because it triggers the case where EINTR is received in https://github.com/ghc/ghc/blob/f46369b8a1bf90a3bdc30f2b566c3a7e03672518%5E/libraries/base/cbits/inputReady.c#L48, letting us use the same unmodified 1-second `struct timeval *timeout` again and again. This demo of the bug works for GHC 7.10 and 8.0.1; in 8.0.2 `hWaitForInput` is broken (https://ghc.haskell.org/trac/ghc/ticket/12912#comment:4) so the demo doesn't work there. --- Convenience: Here is the call chain of [https://gist.github.com/nh2/6f571ce00667bc49d845ab4c8fdf9769 hWaitForInput] -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13497#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 13:47:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 13:47:13 -0000 Subject: [GHC] #14293: View patterns with locally defined functions in restructuring don't compile In-Reply-To: <048.c31716401fbaaf0de63b3851966b01cc@haskell.org> References: <048.c31716401fbaaf0de63b3851966b01cc@haskell.org> Message-ID: <063.2d6f6b5c675b2496ab65a6c630e0dde1@haskell.org> #14293: View patterns with locally defined functions in restructuring don't compile -------------------------------------+------------------------------------- Reporter: heisenbug | 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 RyanGlScott): I looked into this yesterday, but this seems much harder to fix than I would have originally thought. The issue is that we rename top-level bindings in two phases: 1. First, we rename the LHSes of each top-level binding, and gather up the names of each binding form. 2. We then extend the global `RdrEnv` with these binding forms and proceed to rename the RHSes of each top-level binding. The problem concerns what constitutes a "LHS". For `FunBind`s, like `foo` and `bar`, the LHS is just the name of the function itself. As a result, the RHS of `bar` includes its `(foo -> res)` pattern, so by the time the RHS is renamed, `foo` is already in scope. For `PatBind`s, however, the LHS includes the pattern itself. This is out of necessity, since for example, `Just (foo -> res')` is binding `res'` at the top level, so we must dig into the pattern itself in order to rename `res'`. But that means that when we are renaming `Just (foo -> res')`, we haven't yet brought `foo` into scope in the `RdrEnv`, causing the error observed in this ticket. This is quite a sticky situation, and I'm not sure it's easy to resolve. Perhaps there's some sort of SCC analysis that could save us here? I'll have to defer to the wisdom of those who know more about the renamer than I do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14293#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 14:00:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 14:00:42 -0000 Subject: [GHC] #14287: Early inlining causes potential join points to be missed In-Reply-To: <044.afeda1d17d7fca2451446457f502779c@haskell.org> References: <044.afeda1d17d7fca2451446457f502779c@haskell.org> Message-ID: <059.f90e00ac3a4e5c9e55bba852ce445a01@haskell.org> #14287: Early inlining causes potential join points to be missed -------------------------------------+------------------------------------- Reporter: jheek | 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 jheek): Actually sfilter3 does not produce optimal code for me. It is correctly recognized as a join point but it gets floated out of to be a top-level binding before the recursive case-of-case transformation jumps in. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14287#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 14:12:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 14:12:58 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.279ccbd118e89a58f304bcee387f5904@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I’d like to get ​Phab:D3903 in first, and then I will come back to this one. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14068#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 14:17:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 14:17:22 -0000 Subject: [GHC] #10941: Large heap address space breaks valgrind In-Reply-To: <046.bc51ed910abe4837d799aba373b5c152@haskell.org> References: <046.bc51ed910abe4837d799aba373b5c152@haskell.org> Message-ID: <061.a9a0806698776a9c285268c15e7dd2c5@haskell.org> #10941: Large heap address space breaks valgrind -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): This also happens with `--disable-large-address-space` when ghc runs out of memory during compilation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10941#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 14:32:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 14:32:40 -0000 Subject: [GHC] #14287: Early inlining causes potential join points to be missed In-Reply-To: <044.afeda1d17d7fca2451446457f502779c@haskell.org> References: <044.afeda1d17d7fca2451446457f502779c@haskell.org> Message-ID: <059.053b81ec91aa7367672d1291e7c52077@haskell.org> #14287: Early inlining causes potential join points to be missed -------------------------------------+------------------------------------- Reporter: jheek | 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 mpickering): How are you compiling, with which version of the compiler? All 3 `filterTest`s were csed to the same definition when I tried with my modified compiler. Here is the test file and results. https://gist.github.com/7c7cb362206f60bc85a76ceb30d786c3 Observe that in the `loopification.simpl` dump file, all 3 are CSEd but in `no-loopification.simpl` only 1 and 3 are CSEd. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14287#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 15:05:21 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 15:05:21 -0000 Subject: [GHC] #14291: Tests tend to fail in the ext-interp way when split sections is enabled In-Reply-To: <046.50939ac6d09fd8ac7c487275ec7ee681@haskell.org> References: <046.50939ac6d09fd8ac7c487275ec7ee681@haskell.org> Message-ID: <061.9cf6966af369b10430d9919583f6468f@haskell.org> #14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.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: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Here is another bisection, this time over the whole tree. Sadly the result is just as non-sensical, {{{ git bisect start # bad: [4364f1e7543b6803cfaef321105d253e0bdf08a4] Typofixes git bisect bad 4364f1e7543b6803cfaef321105d253e0bdf08a4 # good: [2b5b9dc69e5d0af20b6e7be31638c2e3a1bb765f] Fix typo in base changelog git bisect good 2b5b9dc69e5d0af20b6e7be31638c2e3a1bb765f # good: [af9612bf862daaa99384eefa3059054053ecbee8] Make -w less aggressive (Trac #12056) git bisect good af9612bf862daaa99384eefa3059054053ecbee8 # good: [b0285d1fa76769d59e69cb9bf97675868d90a028] Bump nofib submodule git bisect good b0285d1fa76769d59e69cb9bf97675868d90a028 # bad: [dab0e515eadecaee3e9e9f5f8eee3159fa39bb27] Canonicalise Monoid instances in GHC git bisect bad dab0e515eadecaee3e9e9f5f8eee3159fa39bb27 # good: [29da01e0a023eea4bbbfd69dd5d854db721233e6] Make parsed AST dump output lazily git bisect good 29da01e0a023eea4bbbfd69dd5d854db721233e6 # bad: [8a1de424143f5b75e12976ca739e58fe04ae04d6] Add testcase for #14178 git bisect bad 8a1de424143f5b75e12976ca739e58fe04ae04d6 # bad: [a27bb1bd6206bdd5e6004ec1f7e95144a0fcc4d4] base: Add support for file unlocking git bisect bad a27bb1bd6206bdd5e6004ec1f7e95144a0fcc4d4 # good: [a6c448b403dbe8720178ca82100f34baedb1f47e] Small refactor of getRuntimeRep git bisect good a6c448b403dbe8720178ca82100f34baedb1f47e # good: [5266ab9059dffa741b172636f50f1fbfd491dbb4] Remove dll-split. git bisect good 5266ab9059dffa741b172636f50f1fbfd491dbb4 # good: [3c6b2fc3b5ca11a5410405664e4640767ef941dd] Fix decomposition error on Windows git bisect good 3c6b2fc3b5ca11a5410405664e4640767ef941dd # good: [f86de44dac0a6ca40c5fcd65f3a1944c45fa6011] ghc-pkg: Try opening lockfiles in read-write mode first git bisect good f86de44dac0a6ca40c5fcd65f3a1944c45fa6011 # first bad commit: [a27bb1bd6206bdd5e6004ec1f7e95144a0fcc4d4] base: Add support for file unlocking }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14291#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 15:41:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 15:41:13 -0000 Subject: [GHC] #14291: Tests tend to fail in the ext-interp way when split sections is enabled In-Reply-To: <046.50939ac6d09fd8ac7c487275ec7ee681@haskell.org> References: <046.50939ac6d09fd8ac7c487275ec7ee681@haskell.org> Message-ID: <061.5ddbc1afd443da198bd663bf20f86a67@haskell.org> #14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.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: 13716 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Huh, well this is unfortunate: It looks like a27bb1bd6206bdd5e6004ec1f7e95144a0fcc4d4 really is bad and f86de44dac0a6ca40c5fcd65f3a1944c45fa6011 is in fact good. I still have a hard time seeing how a27bb1bd6206bdd5e6004ec1f7e95144a0fcc4d4 is directly the cause. It's look more and more like this isn't entirely reproducible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14291#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 16:08:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 16:08:18 -0000 Subject: [GHC] #14285: Entered absent arg - triggered by INLINEABLE, regression from 8.0.2 In-Reply-To: <049.09fbd6d1ad4f0a97bcd76579dd68ae8a@haskell.org> References: <049.09fbd6d1ad4f0a97bcd76579dd68ae8a@haskell.org> Message-ID: <064.7c5382c53df61982a73b780c072c514c@haskell.org> #14285: Entered absent arg - triggered by INLINEABLE, regression from 8.0.2 ---------------------------------+-------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by simonpj): I know what is going on. It's extremely annoying. In module `Foo` we get this after demand analysis: {{{ pre_images [InlPrag=INLINABLE] :: forall a k k. Enum a => a -> Rel k k -> Set k [Str=<S(LLLC(S(S))LLLL),1*U(A,A,A,1*C1(U(U)),A,A,A,A)> <L,U> <S(LS),1*U(A,U)>, <----------- NB Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [30 0 20] 120 0 Tmpl= \ (@ a_a52c) (@ k_a52e) (@ k_a52d) ($dEnum_a52n [Occ=Once] :: Enum a_a52c) (x_a2k0 [Occ=Once] :: a_a52c) (rel_a2k1 [Occ=Once!] :: Rel k_a52e k_a52d) -> case rel_a2k1 of { Rel f_a2k2 [Occ=Once] g_a2k3 [Occ=Once] -> NB -------> case T14285a.$WRel @ k_a52d @ k_a52e g_a2k3 f_a2k2 of { Rel f_a2jY [Occ=Once] _ [Occ=Dead] -> IM.findWithDefault @ (Set k_a52e) (empty @ k_a52e) (fromEnum @ a_a52c $dEnum_a52n x_a2k0) (f_a2jY `cast` (T14285a.N:Map[0] <k_a52d>_P <Set k_a52e>_N :: (Map k_a52d (Set k_a52e) :: *) ~R# (IM.IntMap (Set k_a52e) :: *))) } }}] pre_images = \ (@ a_a52c) (@ k_a52e) (@ k_a52d) ($dEnum_a52n [Dmd=<S(LLLC(S(S))LLLL),1*U(A,A,A,1*C1(U(U)),A,A,A,A)>] :: Enum a_a52c) (x_a2k0 :: a_a52c) (rel_a2k1 [Dmd=<S(LS),1*U(A,U)>] :: Rel k_a52e k_a52d) -> case rel_a2k1 of { Rel f_a2k2 [Dmd=<L,A>] g_a2k3 [Dmd=<S,1*U>] -> case fromEnum @ a_a52c $dEnum_a52n x_a2k0 of { GHC.Types.I# ww1_a57r [Dmd=<S,U>] -> Data.IntMap.Internal.$wfindWithDefault @ (Set k_a52e) (empty @ k_a52e) ww1_a57r (g_a2k3 `cast` (T14285a.N:Map[0] <k_a52d>_P <Set k_a52e>_N :: (Map k_a52d (Set k_a52e) :: *) ~R# (IM.IntMap (Set k_a52e) :: *))) } } }}} Note that * The third arg is marked `<S(LS),1*U(A,U)>`, and so is strict, but its first component is unused. * And indeed `f_a2k2` is unsed in the body of `pre_images` * But alas, in the stable-unfolding, `f_a2k2` '''is''' used. It is passed to `$WRel`, the wrapper for the strict data contructor `Rel`; it evaluates both arguments. * So if we w/w this function, we won't pass the first component; instead we'll make up `absentError "blah"` to fill the hole, expecting it not to be used. * Alas, when we do the same thing to the stable unfolding (see `Note [Worker-wrapper for INLINABLE functions]` in `WorkWrap.hs`) we ''do'' evaluate that `absentError` call. Sigh. I'm not at all clear what to do about this, but at least we can see what is going on. It's very much a corner case, so I don't want to harm mainstream cases for the sake of this one. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14285#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 16:16:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 16:16:15 -0000 Subject: [GHC] #14017: "make install" with non-standard umask causes bad permission on package.cache In-Reply-To: <042.5806d86f4e310ee9a216a4e21aa656b9@haskell.org> References: <042.5806d86f4e310ee9a216a4e21aa656b9@haskell.org> Message-ID: <057.23e78a3393a3e13abb4f7bd699263c4d@haskell.org> #14017: "make install" with non-standard umask causes bad permission on package.cache -------------------------------------+------------------------------------- Reporter: djf | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #13375, #13354, | Differential Rev(s): #13194 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.2 => 8.2.3 Comment: This won't happen for 8.2.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14017#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 17:44:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 17:44:01 -0000 Subject: [GHC] #14290: Strictness bug with existential contexts on data constructors In-Reply-To: <047.5982a590b871aad7c07e701c3f87fe86@haskell.org> References: <047.5982a590b871aad7c07e701c3f87fe86@haskell.org> Message-ID: <062.df197b88e637ebc235df6d1cdcd64867@haskell.org> #14290: Strictness bug with existential contexts on data constructors -------------------------------------+------------------------------------- Reporter: simonmar | 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: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4040 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"5935acdb1302263011c2023d5e7f4ec496c972c0/ghc" 5935acd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5935acdb1302263011c2023d5e7f4ec496c972c0" mkDataConRep: fix bug in strictness signature (#14290) The strictness signature for a data con wrapper wasn't including any dictionary arguments, which meant that bangs on the fields of a constructor with an existential context would be moved to the wrong fields. See T14290 for an example. Test Plan: * New test T14290 * validate Reviewers: simonpj, niteria, austin, bgamari, erikd Reviewed By: simonpj, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14290 Differential Revision: https://phabricator.haskell.org/D4040 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14290#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 18:11:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 18:11:27 -0000 Subject: [GHC] #14190: Typeable imposes seemingly redundant constraints on polykinded instances In-Reply-To: <045.10ac00c982131e42012d99b318054ca4@haskell.org> References: <045.10ac00c982131e42012d99b318054ca4@haskell.org> Message-ID: <060.044c5df1ac2bc49be2a4e7f4dd2bc341@haskell.org> #14190: Typeable imposes seemingly redundant constraints on polykinded instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4000 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I like comment:7 and Simon's suggested implementation of comment:7 in comment:9. Ben's worry about redundant constraints floating around (comment:8) is a valid concern, but GHC already worries about this with any superclass constraints (as comment:9 hints). Re Simon's comment:12: You can't always pass the `TypeRep` for a kind separately. If you have the `TypeRep` for `(a :: k -> Type) (b :: k)`, then you don't always have the `TypeRep` for `k` to hand. `typeRepKind` allows you to get the kind once you've decompose an application. Also, while we're thinking about changing the concrete representation of `TypeRep`, might we consider getting rid of `TrFun`? GHC has very good reasons for having a streamlined representation for functions, but `TypeRep` doesn't have as clear-cut a use-case for this. Getting rid of `TrFun` would greatly simplify, e.g., `splitApp`. Was it motivated directly by performance (or other) problems? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14190#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 18:43:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 18:43:18 -0000 Subject: [GHC] #14290: Strictness bug with existential contexts on data constructors In-Reply-To: <047.5982a590b871aad7c07e701c3f87fe86@haskell.org> References: <047.5982a590b871aad7c07e701c3f87fe86@haskell.org> Message-ID: <062.ab5c092429e3bc1d30f47c8634d9fc81@haskell.org> #14290: Strictness bug with existential contexts on data constructors -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 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:D4040 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Merged to `ghc-8.2` as a0671e2de97c5801bfba4b12f16e498492681bc1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14290#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 19:13:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 19:13:22 -0000 Subject: [GHC] #14190: Typeable imposes seemingly redundant constraints on polykinded instances In-Reply-To: <045.10ac00c982131e42012d99b318054ca4@haskell.org> References: <045.10ac00c982131e42012d99b318054ca4@haskell.org> Message-ID: <060.bec6bbd3622eba91be0be4c31a284fc1@haskell.org> #14190: Typeable imposes seemingly redundant constraints on polykinded instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4000 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Getting rid of `TrFun` does seem to simplify the story substantially. If we end up keeping it, by the way, I think we should really have a `Note` explaining why the fingerprinting is safe. It's because whenever `p q` is well-kinded, `p -> q` is not. Not a complicated matter, but I think one worth mentioning. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14190#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 19:55:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 19:55:27 -0000 Subject: [GHC] #14295: tagToEnum# leads to some silly closures In-Reply-To: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> References: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> Message-ID: <060.5ac5cc73a68b9ead4c6f781f65557ec4@haskell.org> #14295: tagToEnum# leads to some silly closures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:11 simonpj]: > So yes one could do it as a `CorePrep` tactic, but it's delicate; and we risk not getting the benefits because we don't implement the follow-on transformations. What makes it delicate? For `quotInt#` et al, I don't imagine that there ''are'' many interesting follow-on transformations in most cases, although I could be wrong. For `tagToEnum#`, we should decide whether to "inline" in core2core. If we go to the trouble of a `quotInt#` cleanup in `CorePrep`, then we can just tack the `tagToEnum#` cleanup on in the same way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14295#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 23:47:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 23:47:51 -0000 Subject: [GHC] #14296: Add `Lift Exp` instance to `Language.Haskell.TH.Syntax` Message-ID: <048.92979204b2aa32d363d344d2b3964024@haskell.org> #14296: Add `Lift Exp` instance to `Language.Haskell.TH.Syntax` -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 8.2.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Being open-minded, I played around with TH quotations and encountered a strange error message: TyFamWitnesses.hs:106:40-71: error: • No instance for (Lift Exp) arising from a use of ‘lift’ • In the expression: lift eqTypeRep In the expression: {{{ [| eqTypeRep (typeRep @Maybe) |] pending(rn) [<eqTypeRep, lift eqTypeRep>] In an equation for ‘fun'’: fun' = [| eqTypeRep (typeRep @Maybe) |] pending(rn) [<eqTypeRep, lift eqTypeRep>] | 106 | fun' = [e|eqTypeRep (typeRep @ Maybe)|] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Failed, 0 modules loaded. Adding an orphan instance locally helped (of course). {{{#!hs instance Lift Exp where lift = pure }}} It appears to be the right thing to do... Why isn't this in `Language.Haskell.TH.Syntax`? Just forgotten? If so, and somebody gives me a thumbs up, I'll add it tomorrow to HEAD (with a corresponding @since annotation). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14296> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 23:51:57 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 23:51:57 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.ec3c9db3f023d8948f41ef31f338ad5c@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10577, #13117 | Differential Rev(s): Phab:D4047 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: Phab:D978 => Phab:D4047 Comment: Phab:D4047 implements the aforementioned proposal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7401#comment:52> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Sep 28 23:53:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Sep 2017 23:53:43 -0000 Subject: [GHC] #10577: Use empty cases where appropriate when deriving instances for empty types In-Reply-To: <047.96e36644fa4dc515076cb2f2c2be615c@haskell.org> References: <047.96e36644fa4dc515076cb2f2c2be615c@haskell.org> Message-ID: <062.e4a39d30b9ead5605437dfe7cc9b8932@haskell.org> #10577: Use empty cases where appropriate when deriving instances for empty types -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13117, #7401 | Differential Rev(s): Phab:D4047 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4047 Comment: Phab:D4047 fixes this ticket in the sense that more classes now use `EmptyCase` in derived code for empty data types (namely, `Show`, `Lift`, and `Data`). Note that `Eq` and `Ord` are not among these classes—refer to the [https://github.com/ghc-proposals/ghc- proposals/blob/dbf516088d2839432c9568c3d1f7ae28d46aeb43/proposals/0006 -deriving-empty.rst proposal] which Phab:D4047 implements. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10577#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 01:03:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 01:03:01 -0000 Subject: [GHC] #13391: PolyKinds is more permissive in GHC 8 In-Reply-To: <047.7921462df1c636dc7a1bfe3d9149887d@haskell.org> References: <047.7921462df1c636dc7a1bfe3d9149887d@haskell.org> Message-ID: <062.5b4aca502a989c84eb5b8e66bae60e76@haskell.org> #13391: PolyKinds is more permissive in GHC 8 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3859 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg <rae@…>): In [changeset:"7aa000b625c677534c87da43de31c27a2b969183/ghc" 7aa000b6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7aa000b625c677534c87da43de31c27a2b969183" Fix #13391 by checking for kind-GADTs The check is a bit gnarly, but I couldn't think of a better way. See the new code in TcTyClsDecls. test case: polykinds/T13391 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13391#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 01:04:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 01:04:26 -0000 Subject: [GHC] #13391: PolyKinds is more permissive in GHC 8 In-Reply-To: <047.7921462df1c636dc7a1bfe3d9149887d@haskell.org> References: <047.7921462df1c636dc7a1bfe3d9149887d@haskell.org> Message-ID: <062.8388341f5ae3ad0aa9cd6673eefcfc1c@haskell.org> #13391: PolyKinds is more permissive in GHC 8 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | polykinds/T13391{,a} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3859 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: patch => closed * testcase: => polykinds/T13391{,a} * resolution: => fixed Comment: I don't think this should be merged. It's not ruining anyone's day, and it will cause fewer programs to be accepted. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13391#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 01:13:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 01:13:00 -0000 Subject: [GHC] #14296: Add `Lift Exp` instance to `Language.Haskell.TH.Syntax` In-Reply-To: <048.92979204b2aa32d363d344d2b3964024@haskell.org> References: <048.92979204b2aa32d363d344d2b3964024@haskell.org> Message-ID: <063.c7e2679275314c453f5de422a4900daa@haskell.org> #14296: Add `Lift Exp` instance to `Language.Haskell.TH.Syntax` -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14030 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #14030 Comment: This is planned as part of a larger proposal to derive `Lift` instances for all data types in `template-haskell`. See #14030. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14296#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 01:20:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 01:20:16 -0000 Subject: [GHC] #14296: Add `Lift Exp` instance to `Language.Haskell.TH.Syntax` In-Reply-To: <048.92979204b2aa32d363d344d2b3964024@haskell.org> References: <048.92979204b2aa32d363d344d2b3964024@haskell.org> Message-ID: <063.2699e49bbd16b059dcb3a364ea26079f@haskell.org> #14296: Add `Lift Exp` instance to `Language.Haskell.TH.Syntax` -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14030 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): However, it should be noted that a derived `Lift` instance for `Exp` would not produce the code above. The problem with that instance is that if `x :: Exp`, then `$(lift x)` would not necessarily equal `x` (or even be of type `Exp`!), which is a rule you'd generally expect to hold. (I realize this law isn't started anywhere in the Haddocks at the moment, but it probably should be.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14296#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 06:08:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 06:08:23 -0000 Subject: [GHC] #14297: make bindist packages the wrong binaries for cross compilers Message-ID: <047.8ce36e512d360b3f2bbb1d08d268dbe1@haskell.org> #14297: make bindist packages the wrong binaries for cross compilers -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Package | Version: 8.2.1 system | Keywords: | Operating System: Unknown/Multiple Architecture: Other | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When building binary distributions via `make binary-dist`, the resulting binaries in the package end up being compiled for the target instead of the host when cross compiling. E.g. building a cross compiler for iOS on macOS yields: {{{ ./inplace/bin/ghc-cabal: Mach-O 64-bit executable x86_64 ./utils/ghc-cabal/dist/build/tmp/ghc-cabal: Mach-O 64-bit executable x86_64 ./utils/ghc-cabal/dist-install/build/tmp/ghc-cabal: Mach-O 64-bit executable arm64 ./inplace/lib/bin/hsc2hs: Mach-O 64-bit executable x86_64 ./utils/hsc2hs/dist/build/tmp/hsc2hs: Mach-O 64-bit executable x86_64 ./utils/hsc2hs/dist-install/build/tmp/hsc2hs: Mach-O 64-bit executable arm64 }}} to just name `ghc-cabal` and `hsc2hs`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14297> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 06:08:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 06:08:36 -0000 Subject: [GHC] #14297: make bindist packages the wrong binaries for cross compilers In-Reply-To: <047.8ce36e512d360b3f2bbb1d08d268dbe1@haskell.org> References: <047.8ce36e512d360b3f2bbb1d08d268dbe1@haskell.org> Message-ID: <062.abbb93e8092674cf30ca10d0d92c8fbd@haskell.org> #14297: make bindist packages the wrong binaries for cross compilers -------------------------------------+-------------------------------- Reporter: angerman | Owner: angerman Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Package system | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Other Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+-------------------------------- Changes (by angerman): * owner: (none) => angerman -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14297#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 07:40:59 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 07:40:59 -0000 Subject: [GHC] #14295: tagToEnum# leads to some silly closures In-Reply-To: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> References: <045.7db84fc80c6f0b5787895d679dd23f44@haskell.org> Message-ID: <060.8e55c4730df9e7b4bd103ac40c8bfd87@haskell.org> #14295: tagToEnum# leads to some silly closures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > What makes it delicate? Just that `CorePrep` is trying to establish some tricky output invariants (about ANF) etc, and is ''not'' a simplification engine. If there are zero knock-on transformations then that's fine, but that's a delicate situation all by itself. Anyway, I'm not opposed, just doubtful about the cost/benefit tradeoff. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14295#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 08:01:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 08:01:01 -0000 Subject: [GHC] #10577: Use empty cases where appropriate when deriving instances for empty types In-Reply-To: <047.96e36644fa4dc515076cb2f2c2be615c@haskell.org> References: <047.96e36644fa4dc515076cb2f2c2be615c@haskell.org> Message-ID: <062.d06a50d297aec6b2b110f9e5ca13f509@haskell.org> #10577: Use empty cases where appropriate when deriving instances for empty types -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13117, #7401 | Differential Rev(s): Phab:D4047 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I still think there should be a "few examples where folks tied knots with fixed points to get inhabitants of Void" seeing as that is the primary motivation for this implementation. They are good for tests and notes even though I accept I will find them dubious. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10577#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 08:14:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 08:14:05 -0000 Subject: [GHC] #14296: Add `Lift Exp` instance to `Language.Haskell.TH.Syntax` In-Reply-To: <048.92979204b2aa32d363d344d2b3964024@haskell.org> References: <048.92979204b2aa32d363d344d2b3964024@haskell.org> Message-ID: <063.588b578448d5ce2cb6aef1c132b2a339@haskell.org> #14296: Add `Lift Exp` instance to `Language.Haskell.TH.Syntax` -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14030 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:2 RyanGlScott]: > However, it should be noted that a derived `Lift` instance for `Exp` would not produce the code above. The problem with that instance is that if `x :: Exp`, then `$(lift x)` would not necessarily equal `x` (or even be of type `Exp`!), which is a rule you'd generally expect to hold. (I realize this law isn't started anywhere in the Haddocks at the moment, but it probably should be.) Interesting. I did not think about that too deeply. Maybe worth documenting this. But in my case (the specific usage in `[e|eqTypeRep (typeRep @ Maybe)|]`) the invariant is satisfied: `lift eqTypeRep` should encode an `Exp`. After all, I use it in this context `[p|($here -> Just HRefl)|]` as the view function. So I should be safe, right? Should I err, the type checker will remind me after quotation expansion, won't it? What about the derivation mechanism for `Lift` instances? Will it do ''the right thing'' in this case too? Anyway, thanks for the insight! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14296#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 08:30:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 08:30:52 -0000 Subject: [GHC] #14282: tagToEnum# . dataToTag# not optimized away In-Reply-To: <045.5438ce0b3dc299cc3f08e924d6abe37c@haskell.org> References: <045.5438ce0b3dc299cc3f08e924d6abe37c@haskell.org> Message-ID: <060.0cc8b3c54cfdc83f98eb1d0179c08dbb@haskell.org> #14282: tagToEnum# . dataToTag# not optimized away -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: 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): * owner: (none) => dfeuer Comment: Yes, please do. In `PrelRules` I see that `dataToTagRule` has a rule for when the argument is `tagToEnum#`. It should be easy to do the same thing for `tagToEnumRule`. Low impact, but low cost. Thanks. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14282#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 08:40:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 08:40:17 -0000 Subject: [GHC] #14283: Remove the special case for tagToEnum# in the code generator? In-Reply-To: <045.8ba2def23565b96372814e1341ba709b@haskell.org> References: <045.8ba2def23565b96372814e1341ba709b@haskell.org> Message-ID: <060.953736b85e9a6bfa173d7935611417d9@haskell.org> #14283: Remove the special case for tagToEnum# in the code generator? -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > The only remaining primop (aside from unsafeCoerce# and seq) that produces an enumeration type is tagToEnum#. There is some magic in the code generator to make garbage collection relating to this work as it has historically. What/where is the magic you want to remove? I think it might be {{{ cgCase (StgOpApp (StgPrimOp op) args _) bndr (AlgAlt tycon) alts | isEnumerationTyCon tycon -- Note [case on bool] = do { tag_expr <- do_enum_primop op args -- If the binder is not dead, convert the tag to a constructor -- and assign it. ; unless (isDeadBinder bndr) $ do { dflags <- getDynFlags ; tmp_reg <- bindArgToReg (NonVoid bndr) ; emitAssign (CmmLocal tmp_reg) (tagToClosure dflags tycon tag_expr) } ; (mb_deflt, branches) <- cgAlgAltRhss (NoGcInAlts,AssignedDirectly) (NonVoid bndr) alts -- See Note [GC for conditionals] ; emitSwitch tag_expr branches mb_deflt 0 (tyConFamilySize tycon - 1) ; return AssignedDirectly } where do_enum_primop :: PrimOp -> [StgArg] -> FCode CmmExpr do_enum_primop TagToEnumOp [arg] -- No code! = getArgAmode (NonVoid arg) do_enum_primop primop args = do dflags <- getDynFlags tmp <- newTemp (bWord dflags) cgPrimOp [tmp] primop args return (CmmReg (CmmLocal tmp)) }}} in `StgCmmExpr`. Right? If so, what is the effect of just removing it? Why is it bad to have {{{ case tagToEnum# x of y DEFAULT -> f y }}} ? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14283#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 08:54:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 08:54:01 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.b4cf2273df705cd87ded4d01dda8e766@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Fair enough. Let's get on with Phab:D3903 (i.e. #14152) then. I've commented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14068#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 09:07:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 09:07:42 -0000 Subject: [GHC] #14287: Early inlining causes potential join points to be missed In-Reply-To: <044.afeda1d17d7fca2451446457f502779c@haskell.org> References: <044.afeda1d17d7fca2451446457f502779c@haskell.org> Message-ID: <059.c1d38710416e0c90c761949201ef37d6@haskell.org> #14287: Early inlining causes potential join points to be missed -------------------------------------+------------------------------------- Reporter: jheek | 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 simonpj): A major goal in GHC is to avoid sensitivity to ordering of transformations. Otherwise things become too finely balanced. Here are three programs {{{ -- Recursive function -- go is not a join point f1 x = letrec go s = case s of Done -> Done Yield x s' | pred x -> Yield x s' | otherwise -> go s' in case go s2 of ... -- Same but float inwards -- Now go becomes a join point f2 x = case letrec go s = case s of Done -> Done Yield x s' | pred x -> Yield x s' | otherwise -> go s' in go s2 of ... -- Same but float outwards -- Now go becomes top-level go pred s = case s of Done -> Done Yield x s' | pred x -> Yield x s' | otherwise -> go s' f3 x = case go pred s2 of ... }}} Points to note: * Float-in can create join points; see the transition from `f1` to `f2` * Even though `go` is a join point in `f2`, we need a run of the Simplifier to mark it as such. Once it is marked as a join point, it'll stay that way. * Float-out is currently pretty aggressive about floating things to top level, and so will tend to generate `f3`. By itself that is not too bad. But now the `case` in `f3` can't fuse with the loop. * Don't forget that the user might write the program in the `f3` form in the first place. Ideally we want all forms to optimise the same way. I think that the Right Solution to these fragilities is the loopification plan in #14068. Then, even in the top-level form we'd get {{{ go pred s = letrec go' s = case s of Done -> Done Yield x s' | pred x -> Yield x s' | otherwise -> go' s' in go' s f3 x = case go pred s2 of ... }}} Now (a) `go'` is a join point, and (b) `go` is non-recursive and will inline. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14287#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 09:08:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 09:08:00 -0000 Subject: [GHC] #14287: Early inlining causes potential join points to be missed In-Reply-To: <044.afeda1d17d7fca2451446457f502779c@haskell.org> References: <044.afeda1d17d7fca2451446457f502779c@haskell.org> Message-ID: <059.cdf978596509ac836792c4c7f90602bd@haskell.org> #14287: Early inlining causes potential join points to be missed -------------------------------------+------------------------------------- Reporter: jheek | Owner: (none) 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => JoinPoints -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14287#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 09:09:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 09:09:06 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.a7f4c4591965e87e514543c88b5150f7@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > The function > {{{ > let f x y = case y of > A -> f x' y' > B -> e2 > C -> e3 > in g f > }}} > is not turned into a recursive join point, because the call to `f` is not > in tail call position. But the recursive calls are, and these matter > performance-wise! Hence, it would be beneficial to turn this into > {{{ > let f x y = joinrec $j x y = case x y of > A -> $j x' y' > B -> e2 > C -> e3 > in $j x y > in g f > }}} > > This has the additional effect that now `f` is no longer recursive and > may get inlined. > > The idea is described under "New idea: use join points" in > [wiki:Commentary/Compiler/Loopification]. > > Some notes: > > * We should to this both at top level and for nested definitions. > > * We can remove the "loopification" code from the code generator when > this is done. > > * It came up in #13966, and might go well with #14067. > > * It might work well with #13051, which Thomas Jakway is still thinking > about. New description: The function {{{ let f x y = case y of A -> f x' y' B -> e2 C -> e3 in g f }}} is not turned into a recursive join point, because the call to `f` is not in tail call position. But the recursive calls are, and these matter performance-wise! Hence, it would be beneficial to turn this into {{{ let f x y = joinrec $j x y = case x y of A -> $j x' y' B -> e2 C -> e3 in $j x y in g f }}} This has the additional effect that now `f` is no longer recursive and may get inlined. The idea is described under "New idea: use join points" in [wiki:Commentary/Compiler/Loopification]. Some notes: * We should to this both at top level and for nested definitions. * We can remove the "loopification" code from the code generator when this is done. * It came up in #13966, and might go well with #14067. * It might work well with #13051, which Thomas Jakway is still thinking about. * Should fix #14287 too. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14068#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 09:32:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 09:32:49 -0000 Subject: [GHC] #14293: View patterns with locally defined functions in restructuring don't compile In-Reply-To: <048.c31716401fbaaf0de63b3851966b01cc@haskell.org> References: <048.c31716401fbaaf0de63b3851966b01cc@haskell.org> Message-ID: <063.c7e34f0c4a90c9bcd0a1be18f16f8516@haskell.org> #14293: View patterns with locally defined functions in restructuring don't compile -------------------------------------+------------------------------------- Reporter: heisenbug | 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 simonpj): Here's an even more tricky case: {{{ (foo -> (a,b), foo) = ([True,False], \(a:b:_) -> (a,b)) }}} The lazy pattern binding matches a pair, binding `foo`, which is used as the viewing function in another part of the same pattern. I think the Right Thing here is to rename the ''binders'' of the pattern first, and then later rename the ''occurrences'' of bound variables. The latter occur in view patterns. At the moment a `HsBindLR` has two pass parameters, and goes through these stages: * `HsBindLR Parsed Parsed`: after the parser * `HsBindLR` Renamed Parsed`: binders renamed, but RHSs not renamed yet * `HsBindLR` Renamed Renamed`: fully renamed But patterns have only one pass parameter! So perhaps we can give them two, like `HsBindLR`. Then `rnPat` would be split into two, * `rnPatLHS` that deals with the binders, and * `rnPatRHS` that deals with the expressions in view patterns. The latter would be much simpler than the current `rnPat`: just find the view patterns and renamed the view function. The former is pretty much what we have now in `rnPat`. In the case of lambda/case patterns we don't want to split in this way. We positively want a left-to-right bias. For example {{{ f (foo -> (a,b), foo) = ... }}} is ill-scoped. So maybe `rnPatLHS` has type (roughly) {{{ rnPatLHS :: Pat GhcPs GhcPs -> (LHsExpr GhcPs -> RnM (LHsExpr p)) -> (LPat GhcRn p -> RnM (a, FreeVars)) -> RnM (a, FreeVars) }}} Here the second argument is used to rename the view functions; either it's a no-op (used in bindings) or it's `rnLHsExpr` (use in case/lambda). I have not worked through the details but it seems plausible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14293#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 11:15:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 11:15:34 -0000 Subject: [GHC] #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 In-Reply-To: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> References: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> Message-ID: <069.e3be0e372938444f62b3ea584f67dd83@haskell.org> #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Richard and I both think we should stick with the current behaviour, and specify it in the user manual. That is, with `-XScopedTypeVariables`, and a signature {{{ f :: forall a b c. blah <definition of f> }}} then `a`, `b` and `c` scope over f's definition, but no other type variables do. This applies unconditionally, even if `blah` starts with another `forall`. The `forall` must appear literally, not hidden by a type synonym. Eg. no variables scope here {{{ type Foo = forall a b. a -> b -> Int f :: Foo f = e -- a and b are not in scope here }}} This rule is simple, and does not restrict expressiveness. Otherwise we land up trying to decide where to draw the line (and having to explain where it is drawn, in the user manual). Eg {{{ f :: forall a. forall b. blah f :: forall a. a -> forall b. blah f :: forall a. Eq a => forall b. blah }}} Would someone care to update the user manual? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14288#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 12:36:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 12:36:58 -0000 Subject: [GHC] #14141: Custom type errors don't trigger when matching on a GADT constructor with an error in the constraint In-Reply-To: <048.8c7c6e99fe9fa4831df87e7c0f062c98@haskell.org> References: <048.8c7c6e99fe9fa4831df87e7c0f062c98@haskell.org> Message-ID: <063.64788680eba5770d23de00ec96f49b3c@haskell.org> #14141: Custom type errors don't trigger when matching on a GADT constructor with an error in the constraint -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Keywords: Resolution: | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: GHC accepts | (amd64) invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #11503 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #11503 Comment: I think this ticket is #11503 in disguise (or at least shares a symptom with it). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14141#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 12:37:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 12:37:19 -0000 Subject: [GHC] #11503: TypeError woes (incl. pattern match checker) In-Reply-To: <047.92c703997fce99f046395b5c889b1ab4@haskell.org> References: <047.92c703997fce99f046395b5c889b1ab4@haskell.org> Message-ID: <062.7db0e2fd7b29d1a92b8256df44948af2@haskell.org> #11503: TypeError woes (incl. pattern match checker) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternMatchWarnings, | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14141 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: PatternMatchWarnings => PatternMatchWarnings, CustomTypeErrors * related: => #14141 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11503#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 13:12:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 13:12:01 -0000 Subject: [GHC] #14296: Add `Lift Exp` instance to `Language.Haskell.TH.Syntax` In-Reply-To: <048.92979204b2aa32d363d344d2b3964024@haskell.org> References: <048.92979204b2aa32d363d344d2b3964024@haskell.org> Message-ID: <063.29ffac3725136330c2845ccb4df460dc@haskell.org> #14296: Add `Lift Exp` instance to `Language.Haskell.TH.Syntax` -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14030 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Let me try and articulate more precisely what this invariant is capturing. Here are some examples of the invariant at work: {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH.Syntax test :: IO () test = mapM_ print [ $(lift True) == True , $(lift "hello") == "hello" ] }}} These should all print `True`, and more generally, you should be able to stick in any other `Bool` or `String` and also have it print all `True`s. But it's easy to subvert this with your proposed `Lift Exp` instance, since you can have, e.g.: {{{#!hs uhOh :: Exp uhOh = lift "uhOh" }}} Now `$(lift uhOh)` won't be an `Exp`, but rather a `String`. This is not at all what we want. Replying to [comment:3 heisenbug]: > What about the derivation mechanism for `Lift` instances? Will it do ''the right thing'' in this case too? Right. Here is an except of the `-ddump-deriv` output from deriving a `Lift` instance for `Exp`: {{{#!hs deriving instance Lift Exp ===> instance Lift Exp where lift (VarE a) = conE 'VarE `appE` lift a lift (ConE a) = conE 'ConE `appE` lift a lift (AppE f x) = conE 'AppE `appE` lift f `appE` lift x ... }}} Now calling `lift` on an `Exp` will produce an `ExpQ` that represents an `Exp` value. It's quite meta, granted, but that's how it should be :) In any case, I've been meaning to resolve #14030 for a while now, but haven't had much time to look into it recently. One obstacle is that deriving `Lift` instances for data types in `template-haskell` during stage-1 compilation is harder than it sounds because GHC HEAD moved around the locations of functions that are used when deriving `Lift` instances themselves. Therefore, I think I'll have to disable generating `Lift` instances on stage-1 compilers for now to make it work, but I've yet to figure out how to accomplish that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14296#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 13:15:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 13:15:38 -0000 Subject: [GHC] #10577: Use empty cases where appropriate when deriving instances for empty types In-Reply-To: <047.96e36644fa4dc515076cb2f2c2be615c@haskell.org> References: <047.96e36644fa4dc515076cb2f2c2be615c@haskell.org> Message-ID: <062.0d437f425275eaf485d0ce1ac9a5e781@haskell.org> #10577: Use empty cases where appropriate when deriving instances for empty types -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13117, #7401 | Differential Rev(s): Phab:D4047 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm not sure if you're asking me to add something here or in the Diff. If the latter, are you asking for a test case to see if something like this evaluates to `True`? {{{#!hs {-# LANGUAGE EmptyDataDeriving #-} module Main where import Data.Function data Foo deriving Eq foo1 :: Foo foo1 = fix id foo2 :: Foo foo2 = let x = y y = x in y main :: IO () main = print (foo1 == foo2) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10577#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 14:09:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 14:09:17 -0000 Subject: [GHC] #14296: Add `Lift Exp` instance to `Language.Haskell.TH.Syntax` In-Reply-To: <048.92979204b2aa32d363d344d2b3964024@haskell.org> References: <048.92979204b2aa32d363d344d2b3964024@haskell.org> Message-ID: <063.d435fd001168211a657172ae0c7e872f@haskell.org> #14296: Add `Lift Exp` instance to `Language.Haskell.TH.Syntax` -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14030 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:4 RyanGlScott]: > <SNIP> > > But it's easy to subvert this with your proposed `Lift Exp` instance, since you can have, e.g.: > > {{{#!hs > uhOh :: Exp > uhOh = lift "uhOh" > }}} > You mean {{{#!hs uhOh :: ExpQ uhOh = lift "uhOh" }}} > Now `$(lift uhOh)` won't be an `Exp`, but rather a `String`. This is not at all what we want. Totally agree. My question is when this happens in a `[p|($uhOh -> binding)|]` and this ends up in a splice, ultimately being compiled by GHC, then I'll get a type error "Expected `Exp`, got: `String`", correct? > > Replying to [comment:3 heisenbug]: > > What about the derivation mechanism for `Lift` instances? Will it do ''the right thing'' in this case too? > > Right. Here is an except of the `-ddump-deriv` output from deriving a `Lift` instance for `Exp`: > > {{{#!hs > deriving instance Lift Exp > > ===> > > instance Lift Exp where > lift (VarE a) = conE 'VarE `appE` lift a > lift (ConE a) = conE 'ConE `appE` lift a > lift (AppE f x) = conE 'AppE `appE` lift f `appE` lift x > ... > }}} > > Now calling `lift` on an `Exp` will produce an `ExpQ` that represents an `Exp` value. It's quite meta, granted, but that's how it should be :) That's good. Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14296#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 14:22:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 14:22:21 -0000 Subject: [GHC] #13945: 'ghc-pkg update' fails due to bad file descriptor error In-Reply-To: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> References: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> Message-ID: <064.2cf4f1a6d31cbd3fa330e7b8baa4356d@haskell.org> #13945: 'ghc-pkg update' fails due to bad file descriptor error ---------------------------------+---------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3897 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by simonpj): I'm still stuck on this. Sigh. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13945#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 14:24:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 14:24:57 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.20346ab29d3b2c0e2d0e8e36637dfca2@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 simonpj): I'm having trouble understanding comment:24. Would it be possible to give a concrete example for each situation you describe? And what's the bottom line? Are there any situations where it predictably wins? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9374#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 14:30:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 14:30:03 -0000 Subject: [GHC] #11228: Interaction between ORF and record pattern synonyms needs to be resolved. In-Reply-To: <049.5473d22bfd3f33e57adb2d754a0b62d6@haskell.org> References: <049.5473d22bfd3f33e57adb2d754a0b62d6@haskell.org> Message-ID: <064.7010d365dadd6dff384998b4c74c0343@haskell.org> #11228: Interaction between ORF and record pattern synonyms needs to be resolved. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternSynonyms, orf Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9975, #11283 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * cc: gridaphobe (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11228#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 15:04:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 15:04:08 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.21f38aa2408d930f400d2c871aa4e3aa@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 mpickering): The main benefit (in nofib) was when SAT was acting to eliminate dictionary arguments which the specialiser has failed to deal with for whatever reason. The other big benefit is like in #14211 where a lot more simplification could happen by a function being inlined into a loop. There were not any of these cases that I saw in nofib but might be more common in real code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9374#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 15:09:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 15:09:06 -0000 Subject: [GHC] #14296: Add `Lift Exp` instance to `Language.Haskell.TH.Syntax` In-Reply-To: <048.92979204b2aa32d363d344d2b3964024@haskell.org> References: <048.92979204b2aa32d363d344d2b3964024@haskell.org> Message-ID: <063.625d01e6a131944fcef8d415d68d490e@haskell.org> #14296: Add `Lift Exp` instance to `Language.Haskell.TH.Syntax` -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14030 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:5 heisenbug]: > You mean > {{{#!hs > uhOh :: ExpQ > uhOh = lift "uhOh" > }}} Oops. That's right. > My question is when this happens in a `[p|($uhOh -> binding)|]` and this ends up in a splice, ultimately being compiled by GHC, then I'll get a type error "Expected `Exp`, got: `String`", correct? Sure, GHC will definitely catch the mistake in the form of a (sometimes hard-to-scrutinize) type error. But I would still be frustrated that that happened in the first place, since it would violate my intuition of how `lift` interacts with splicing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14296#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 15:13:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 15:13:38 -0000 Subject: [GHC] #10941: Large heap address space breaks valgrind In-Reply-To: <046.bc51ed910abe4837d799aba373b5c152@haskell.org> References: <046.bc51ed910abe4837d799aba373b5c152@haskell.org> Message-ID: <061.acc6ad361430a2f0fcff8cdfe6dff316@haskell.org> #10941: Large heap address space breaks valgrind -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Does this still happen with 1d1b991ee15e0428be16d1bfad7087051e000bdc? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10941#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 15:22:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 15:22:36 -0000 Subject: [GHC] #13554: Allow the user to provide a C function that is called on each thread the RTS creates before running any Haskell code In-Reply-To: <047.8330d7f9bec3b64bb6803d51d3c05214@haskell.org> References: <047.8330d7f9bec3b64bb6803d51d3c05214@haskell.org> Message-ID: <062.11aabd259c34e29961a61a60d048ecd7@haskell.org> #13554: Allow the user to provide a C function that is called on each thread the RTS creates before running any Haskell code -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by fendor): Hi, As an API proposal: {{{ data ThreadCallbackHandle data ThreadCallbacks = ThreadCallbacks { threadCreationCb :: IO () , threadDestructionCb :: IO () } -- function calls would be blocking until -- the callbacks have been executed on all threads. registerCallbacks :: ThreadCallbacks -> IO ThreadCallbackHandle unregisterCallbacks :: ThreadCallbackHandle -> IO () }}} In this proposal, one can submit callbacks that are executed on thread creation or thread termination. These callbacks are also executed on every thread that is currently being executed, since it seems impossible to guarantee that no code execution migrates to threads that have not executed the callback functions. When registering new callbacks, the function should block, until it is guaranteed that every thread has executed the new callback function. Several calls to this function should save existing callbacks and execute all callback functions that have been supplied upon thread creation and termination. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13554#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 15:28:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 15:28:13 -0000 Subject: [GHC] #13945: 'ghc-pkg update' fails due to bad file descriptor error In-Reply-To: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> References: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> Message-ID: <064.0ab2f29c66dcb94b3615f870c604ff7a@haskell.org> #13945: 'ghc-pkg update' fails due to bad file descriptor error ---------------------------------+---------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3897 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): Sigh indeed; this is on `master`, yes? Same exact error? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13945#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 15:37:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 15:37:10 -0000 Subject: [GHC] #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 In-Reply-To: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> References: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> Message-ID: <069.f874dd12dbbeaa1db4be9385df814c2c@haskell.org> #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm worried that this design decision will come back to bite us once the [https://github.com/ghc-proposals/ghc- proposals/blob/dbf516088d2839432c9568c3d1f7ae28d46aeb43/proposals/0005 -bidir-constr-sigs.rst pattern synonym construction function signatures] proposal is implemented. To recap, if you have an explicitly bidirectional pattern synonym like: {{{#!hs data T a where MkT :: forall a b. (Show b) => a -> b -> T a pattern ExNumPat :: forall a. (Num a, Eq a) => forall b. (Show b) => b -> T a pattern ExNumPat x <- MkT 42 x where ExNumPat x = MkT 42 x }}} Then this proposal would allow you to write an explicit type signature for the builder expression, like so: {{{#!hs pattern ExNumPat :: forall a. (Num a, Eq a) => forall b. (Show b) => b -> T a pattern ExNumPat x <- MkT 42 x where ExNumPat :: forall a. (Num a, Ord a) => forall b. (Show b) => b -> T a ExNumPat x = MkT 42 x }}} Where this type signature must be the same as the pattern signature save for the required constraints, which are allowed to be different. Once we gain the ability to write type signatures for builder expressions like this (and thus, the ability to lexically scope type variables with `-XScopedTypeVariables`), folks will naturally want to write builders with `-XTypeApplications` like this: {{{#!hs ExNumPat :: forall a. (Num a, Ord a) => forall b. (Show b) => b -> T a ExNumPat x = MkT @a @b 42 x }}} (This is a relatively simple example, but you could imagine this being more useful when fancier types are involved.) But there's a big problem here—. By the rules of `-XScopedTypeVariables`, only `a` will be in scope in the builder's RHS, not `b`! With normal function type signatures, you can work around this problem by just smashing `forall a. forall b` into `forall a b`, but with pattern synonyms, we cannot do this—the required type variables and the provided type variables //must// be quantified separately! So this design prevents us from writing pattern synonym builders that visibly apply provided type variables using `-XTypeApplications`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14288#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 15:52:59 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 15:52:59 -0000 Subject: [GHC] #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 In-Reply-To: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> References: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> Message-ID: <069.4ab21d4079f159fcabc5d0d007b51857@haskell.org> #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): As far as specifying how GHC should bring variables from nested `forall`s into scope, I don't think it's nearly as difficult as you're making it out to be. The algorithm would be as follows: when `ScopedTypeVariables` is enabled and an identifier with an explicit type signature `T` is being typechecked, then the set of variables `foralls(T)` is brought into scope, where: * `foralls(forall a_1 ... a_k. T) = {a_1, ..., a_k} ∪ foralls (T)` * `foralls(C => T) = foralls(T)` * `foralls(b -> c) = foralls(c)` Note that this doesn't expand type synonyms, so we needn't worry about your `Foo` example in comment:5 bringing variables into scope. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14288#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 17:02:56 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 17:02:56 -0000 Subject: [GHC] #14298: Let Template Haskell dynamically add a library against which to link Message-ID: <050.5b84ef44d6dba8c28fe71b17d035f8a7@haskell.org> #14298: Let Template Haskell dynamically add a library against which to link -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 8.2.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As of today, Template Haskell supports emitting foreign files (for C compiler languages) via `addForeignFile`. In doing so, GHC takes on the work of compiling these, linking against them, and then cleaning up any other files. This makes packages like `inline-c` ([https://hackage.haskell.org/package/inline-c]) possible, where you can write C snippets in quasiquotes and these can interact with your Haskell code. The user doesn't need to pass extra options to GHC (except to enable the right language extensions), and they don't have to see any of the intermediate generated artifacts. Unfortunately, that breaks down for non C compiler languages. It would be nice for TH to also support directly adding a static library, since then one could * use TH's `runIO` to generate static libraries by calling out to whatever other compilers * add the contents of those libraries via TH * delete the temporary files created in the process (again using `runIO`) * have GHC statically link against the content (from the second bullet point) I'm not sure what the API for this could be, but maybe adding a `StaticLibrary` constructor to the `ForeignSrcLang` data type (so one could use `addForeignFile :: ForeignSrcLang -> String -> Q ()`)? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14298> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 17:29:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 17:29:48 -0000 Subject: [GHC] #14296: Add `Lift Exp` instance to `Language.Haskell.TH.Syntax` In-Reply-To: <048.92979204b2aa32d363d344d2b3964024@haskell.org> References: <048.92979204b2aa32d363d344d2b3964024@haskell.org> Message-ID: <063.71559bfcb514547fa20ba78659ad45fc@haskell.org> #14296: Add `Lift Exp` instance to `Language.Haskell.TH.Syntax` -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14030 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate Comment: I've added a Diff for documenting this `Lift` law in Phab:D4050. Since we seem to both be in agreement that deriving `Lift` for `Exp` is the better way to go, I'll close this in favor of #14030. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14296#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 18:52:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 18:52:54 -0000 Subject: [GHC] #13554: Allow the user to provide a C function that is called on each thread the RTS creates before running any Haskell code In-Reply-To: <047.8330d7f9bec3b64bb6803d51d3c05214@haskell.org> References: <047.8330d7f9bec3b64bb6803d51d3c05214@haskell.org> Message-ID: <062.ebb78159b5fde61bb6923ee095ab2ab4@haskell.org> #13554: Allow the user to provide a C function that is called on each thread the RTS creates before running any Haskell code -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): dobenour, does this help your use-case(s)? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13554#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 19:22:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 19:22:19 -0000 Subject: [GHC] #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 In-Reply-To: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> References: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> Message-ID: <069.90336939bbb9163c95cca05944f6ece5@haskell.org> #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): What do you think of {{{#!hs f :: forall a. a -> Int -> forall b. (a, b) f x = const (x, undefined :: b) }}} Note that the quantifier for `b` hasn't been encountered in the term definition, which takes only one argument. Accepting this would be strange, indeed, in my view. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14288#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 19:30:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 19:30:44 -0000 Subject: [GHC] #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 In-Reply-To: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> References: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> Message-ID: <069.c2f40fa4e99420109370c5509a866442@haskell.org> #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I don't see what is strange about this? It's no stranger than `f :: forall a b. a -> Int -> (a, b)` at least, which is accepted. Replying to [comment:8 goldfire]: > Note that the quantifier for `b` hasn't been encountered in the term definition, which takes only one argument. Yeah... and? I don't see what the term definition has to do with anything here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14288#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 20:37:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 20:37:12 -0000 Subject: [GHC] #14299: GHCi for GHC 8.2.1 crashed with simple function? Message-ID: <048.a4a45b6e4f4301891e63f7e5dbc2d991@haskell.org> #14299: GHCi for GHC 8.2.1 crashed with simple function? --------------------------------------+------------------------------- Reporter: mathiassm | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 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: --------------------------------------+------------------------------- I'm a newbie here, but I'm following your instructions! I started GHCi, defined a simple factorial function and then called it and... it crashed. {{{#!hs let f 0 = 0 f n = n * f (n-1) f 0 }}} That is what I introduced in the console... After that computer hanged and gave me the following error: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14299> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 20:40:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 20:40:06 -0000 Subject: [GHC] #14299: GHCi for GHC 8.2.1 crashed with simple function? In-Reply-To: <048.a4a45b6e4f4301891e63f7e5dbc2d991@haskell.org> References: <048.a4a45b6e4f4301891e63f7e5dbc2d991@haskell.org> Message-ID: <063.c543d2c948404cdaf4eb5c4b0435e3da@haskell.org> #14299: GHCi for GHC 8.2.1 crashed with simple function? -------------------------------+-------------------------------------- Reporter: mathiassm | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 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 mathiassm: Old description: > I'm a newbie here, but I'm following your instructions! > > I started GHCi, defined a simple factorial function and then called it > and... it crashed. > > {{{#!hs > let f 0 = 0 > f n = n * f (n-1) > f 0 > }}} > > That is what I introduced in the console... After that computer hanged > and gave me the following error: > > {{{ > ghc: panic! (the 'impossible' happened) > (GHC version 8.2.1 for x86_64-apple-darwin): > thread blocked indefinitely in an MVar operation > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} New description: I'm a newbie here, but I'm following your instructions! I started GHCi, defined a simple factorial function and then called it and... it crashed. {{{#!hs let f 0 = 0 f n = n * f (n-1) f 0 }}} That is what I introduced in the console... After that computer hanged and gave me the following error: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): thread blocked indefinitely in an MVar operation Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} EDIT: This was done on a macOS 10.12.6 system with the Haskell Platform installed via Homebrew, with no further "customization". -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14299#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Sep 29 21:04:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Sep 2017 21:04:50 -0000 Subject: [GHC] #14282: tagToEnum# . dataToTag# not optimized away In-Reply-To: <045.5438ce0b3dc299cc3f08e924d6abe37c@haskell.org> References: <045.5438ce0b3dc299cc3f08e924d6abe37c@haskell.org> Message-ID: <060.998aa62b10ab1478aa7095eafda24525@haskell.org> #14282: tagToEnum# . dataToTag# not optimized away -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: 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): I'm trying, but I've hit a snag. Desugaring (even before optimization) produces {{{ bar :: Bool -> Bool [LclIdX] bar = \ (x_aHq :: Bool) -> case dataToTag# @ Bool x_aHq of wild_00 { __DEFAULT -> tagToEnum# @ Bool wild_00 } end Rec } }}} so looking for the application directly doesn't work. Is there a way to look through the unfolding of `wild_00` to see the `dataToTag#`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14282#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 30 13:59:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Sep 2017 13:59:29 -0000 Subject: [GHC] #14292: Coercing between constraints of newtypes In-Reply-To: <051.e9d001b6d6e7069b1e2d96a31ac34922@haskell.org> References: <051.e9d001b6d6e7069b1e2d96a31ac34922@haskell.org> Message-ID: <066.a119a9e5116a5952d735139e32ee944e@haskell.org> #14292: Coercing between constraints of newtypes -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14292#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 30 15:17:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Sep 2017 15:17:19 -0000 Subject: [GHC] #14284: -Weverything is undocumented In-Reply-To: <045.9f4cfb2606fbf67e7f4d80b618b36bf9@haskell.org> References: <045.9f4cfb2606fbf67e7f4d80b618b36bf9@haskell.org> Message-ID: <060.ecdf3436d992e873265c49ad21dd7126@haskell.org> #14284: -Weverything is undocumented -------------------------------------+------------------------------------- Reporter: refold | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Documentation | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab;D4043 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"9c05fc4c31edde34a68317b45fdd71510d868f60/ghc" 9c05fc4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9c05fc4c31edde34a68317b45fdd71510d868f60" user-guide: Document -Weverything [skip ci] Reviewers: hvr, austin, dfeuer Reviewed By: dfeuer Subscribers: rwbarton, thomie GHC Trac Issues: #14284 Differential Revision: https://phabricator.haskell.org/D4043 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14284#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 30 15:17:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Sep 2017 15:17:19 -0000 Subject: [GHC] #14296: Add `Lift Exp` instance to `Language.Haskell.TH.Syntax` In-Reply-To: <048.92979204b2aa32d363d344d2b3964024@haskell.org> References: <048.92979204b2aa32d363d344d2b3964024@haskell.org> Message-ID: <063.2d3838b7b36532ead223fa1faa6e62b4@haskell.org> #14296: Add `Lift Exp` instance to `Language.Haskell.TH.Syntax` -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14030 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"626f0454ef1ca8f40c38064197dba97a36d52dbb/ghc" 626f045/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="626f0454ef1ca8f40c38064197dba97a36d52dbb" Document a law for TH's Lift class Inspired by the discussion in #14296, I've decided to document a law which is usually in the back of my mind when I'm using Template Haskell's `Lift` class, but isn't formally stated anywhere. That is, every `Lift` instance should satisfy (for all `x`): ```lang=haskell $(lift x) == x ``` Test Plan: Read it Reviewers: austin, goldfire, bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4050 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14296#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 30 15:19:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Sep 2017 15:19:40 -0000 Subject: [GHC] #14299: GHCi for GHC 8.2.1 crashed with simple function? In-Reply-To: <048.a4a45b6e4f4301891e63f7e5dbc2d991@haskell.org> References: <048.a4a45b6e4f4301891e63f7e5dbc2d991@haskell.org> Message-ID: <063.a3e06548abc4702f824c50576d974536@haskell.org> #14299: GHCi for GHC 8.2.1 crashed with simple function? -------------------------------+-------------------------------------- Reporter: mathiassm | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 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 bgamari): Wow, what a disaster. Thanks for reporting this. There are a few issues intertwined here. Let's cover them in turn. == Problem 1: Unexpected binding shadowing The first problem here is a bit subtle and has to do with the fact that GHCi accepts two different types of syntax for defining bindings. You can say, {{{#!hs let f n = n * f (n-1) }}} or you can use {{{#!hs f n = n * f (n-1) }}} In your case you used both; GHCi interpreted this as two distinct bindings, one shadowing the other. That is to say, first you defined `f 0 = 0`, then you "overwrote" `f` with, `f n = n * f (n-1)`. When you end up with is a factorial function that doesn't define its base case and consequently will never terminate. When I do this on my machine I get the error, {{{ $ ghci GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Prelude> let f 0 = 0 Prelude> f n = n * f (n-1) Prelude> f 0 Stopped in <exception thrown>, <unknown> _exception :: e = _ [<unknown>] λ> :force _exception _exception = GHC.Exception.SomeException (GHC.IO.Exception.SomeAsyncException GHC.IO.Exception.StackOverflow) }}} That is, a `StackOverflow` exception. In contrast, if I defining these two bindings in one GHCi command, I get the expected behavior (modulo the incorrect definition of factorial), {{{ Prelude> f 0 = 0; f n = n * f (n-1) Prelude> f 0 0 Prelude> f 2 0 }}} or, using the `let` syntax, {{{ Prelude> :{ Prelude| let f 0 = 0 Prelude| f n = n * f (n-1) Prelude| :} Prelude> f 0 0 Prelude> f 4 0 }}} I can see that the fact that the syntax works out this way would be quite surprising. I'm not entirely sure what to do about it, however. Out of curiosity, what instructions are you following? == Problem 2: MVar exception This is almost certainly a bug in GHC(i) {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): thread blocked indefinitely in an MVar operation }}} Unfortunately I'm able to reproduce on neither my Linux box nor an OS X machine, both running 8.2.1. Are you able to reliably reproduce this crash? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14299#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 30 15:34:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Sep 2017 15:34:59 -0000 Subject: [GHC] #13945: 'ghc-pkg update' fails due to bad file descriptor error In-Reply-To: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> References: <049.b152863155a8f5ca5d2c78f97fc10495@haskell.org> Message-ID: <064.b9c52a8b8fa69a29dc5f95bdce7fcf82@haskell.org> #13945: 'ghc-pkg update' fails due to bad file descriptor error ---------------------------------+---------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3897 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: infoneeded => new Comment: Reopening so we don't lose track of this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13945#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 30 15:46:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Sep 2017 15:46:30 -0000 Subject: [GHC] #14300: FreeBSD 10.3 toolchain is terribly broken Message-ID: <046.2e6e216e2555895c84fcbcae84e4e04e@haskell.org> #14300: FreeBSD 10.3 toolchain is terribly broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #13974 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- == `ld.bfd` with `SplitSections=NO` Fails in the final bindist test with, {{{ /usr/bin/install -c -m 755 libraries/gen_contents_index "/usr/home/ben /bin- dist-8.2.1.20170929-FreeBSD/test/inst/share/doc/ghc-8.2.1.20170929/html/libraries/" [1 of 1] Compiling Main ( /usr/home/ben/bin- dist-8.2.1.20170929-FreeBSD/test/hi.hs, /usr/home/ben/bin- dist-8.2.1.20170929-FreeBSD/test/hi.o ) Linking /usr/home/ben/bin-dist-8.2.1.20170929-FreeBSD/test/hi ... /usr/bin/ld: Base__199.o: access beyond end of merged section (-24) /usr/bin/ld: Base__201.o: access beyond end of merged section (-24) ... }}} == `ld.bfd` with `SplitSections=YES` fails with, {{{ ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14300> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 30 15:46:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Sep 2017 15:46:46 -0000 Subject: [GHC] #14300: FreeBSD 10.3 toolchain is terribly broken In-Reply-To: <046.2e6e216e2555895c84fcbcae84e4e04e@haskell.org> References: <046.2e6e216e2555895c84fcbcae84e4e04e@haskell.org> Message-ID: <061.fe08d4a56e85289a0bdede5e188c62b2@haskell.org> #14300: FreeBSD 10.3 toolchain is terribly broken ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13974 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * os: Unknown/Multiple => FreeBSD -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14300#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 30 15:48:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Sep 2017 15:48:25 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.fc8209a7e7c8c937dea07ff324c48347@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: | -------------------------------------+------------------------------------- Changes (by nomeata): * cc: nomeata (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9374#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 30 15:49:51 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Sep 2017 15:49:51 -0000 Subject: [GHC] #14287: Early inlining causes potential join points to be missed In-Reply-To: <044.afeda1d17d7fca2451446457f502779c@haskell.org> References: <044.afeda1d17d7fca2451446457f502779c@haskell.org> Message-ID: <059.36b6ff0483a9b9849410c8f5e8633fc4@haskell.org> #14287: Early inlining causes potential join points to be missed -------------------------------------+------------------------------------- Reporter: jheek | Owner: (none) 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * cc: nomeata (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14287#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 30 15:52:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Sep 2017 15:52:57 -0000 Subject: [GHC] #14284: -Weverything is undocumented In-Reply-To: <045.9f4cfb2606fbf67e7f4d80b618b36bf9@haskell.org> References: <045.9f4cfb2606fbf67e7f4d80b618b36bf9@haskell.org> Message-ID: <060.1e2b4d2beaebe9a9646b79b172155eba@haskell.org> #14284: -Weverything is undocumented -------------------------------------+------------------------------------- Reporter: refold | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Documentation | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab;D4043 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14284#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 30 16:41:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Sep 2017 16:41:54 -0000 Subject: [GHC] #14300: FreeBSD 10.3 toolchain is terribly broken In-Reply-To: <046.2e6e216e2555895c84fcbcae84e4e04e@haskell.org> References: <046.2e6e216e2555895c84fcbcae84e4e04e@haskell.org> Message-ID: <061.b42cf372354d285591cfede345419af5@haskell.org> #14300: FreeBSD 10.3 toolchain is terribly broken ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13974 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Description changed by bgamari: Old description: > == `ld.bfd` with `SplitSections=NO` > > Fails in the final bindist test with, > {{{ > /usr/bin/install -c -m 755 libraries/gen_contents_index "/usr/home/ben > /bin- > dist-8.2.1.20170929-FreeBSD/test/inst/share/doc/ghc-8.2.1.20170929/html/libraries/" > [1 of 1] Compiling Main ( /usr/home/ben/bin- > dist-8.2.1.20170929-FreeBSD/test/hi.hs, /usr/home/ben/bin- > dist-8.2.1.20170929-FreeBSD/test/hi.o ) > Linking /usr/home/ben/bin-dist-8.2.1.20170929-FreeBSD/test/hi ... > /usr/bin/ld: Base__199.o: access beyond end of merged section (-24) > /usr/bin/ld: Base__201.o: access beyond end of merged section (-24) > ... > }}} > > == `ld.bfd` with `SplitSections=YES` > > fails with, > {{{ > ... > }}} New description: == `ld.bfd` with `SplitSections=NO` Fails in the final bindist test with, {{{ /usr/bin/install -c -m 755 libraries/gen_contents_index "/usr/home/ben /bin- dist-8.2.1.20170929-FreeBSD/test/inst/share/doc/ghc-8.2.1.20170929/html/libraries/" [1 of 1] Compiling Main ( /usr/home/ben/bin- dist-8.2.1.20170929-FreeBSD/test/hi.hs, /usr/home/ben/bin- dist-8.2.1.20170929-FreeBSD/test/hi.o ) Linking /usr/home/ben/bin-dist-8.2.1.20170929-FreeBSD/test/hi ... /usr/bin/ld: Base__199.o: access beyond end of merged section (-24) /usr/bin/ld: Base__201.o: access beyond end of merged section (-24) ... }}} == `ld.bfd` with `SplitSections=YES` fails with, {{{ bindisttest/"install dir"/bin/ghc --make bindisttest/HelloWorld [1 of 1] Compiling Main ( bindisttest/HelloWorld.lhs, bindisttest/HelloWorld.o ) Linking bindisttest/HelloWorld ... /usr/home/ben/bin-dist-8.2.1.20170929-FreeBSD/ghc/bindisttest/install dir/lib/ghc-8.2.1.20170929/base-4.10.0.0/libHSbase-4.10.0.0.a(Base.o):base_ControlziExceptionziBase_absentError_info: warning: relocation refers to discarded section /usr/home/ben/bin-dist-8.2.1.20170929-FreeBSD/ghc/bindisttest/install dir/lib/ghc-8.2.1.20170929/base-4.10.0.0/libHSbase-4.10.0.0.a(Base.o)(.text.r3zN_info+0x44): warning: relocation refers to discarded section /usr/home/ben/bin-dist-8.2.1.20170929-FreeBSD/ghc/bindisttest/install dir/lib/ghc-8.2.1.20170929/base-4.10.0.0/libHSbase-4.10.0.0.a(Base.o)(.text.r3zP_info+0x44): warning: relocation refers to discarded section /usr/home/ben/bin-dist-8.2.1.20170929-FreeBSD/ghc/bindisttest/install dir/lib/ghc-8.2.1.20170929/base-4.10.0.0/libHSbase-4.10.0.0.a(Base.o)(.text.r3zR_info+0x44): warning: relocation refers to discarded section ... }}} == `ld.gold`, `SplitSections=NO` {{{ ... }}} -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14300#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 30 17:05:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Sep 2017 17:05:48 -0000 Subject: [GHC] #14300: FreeBSD 10.3 toolchain is terribly broken In-Reply-To: <046.2e6e216e2555895c84fcbcae84e4e04e@haskell.org> References: <046.2e6e216e2555895c84fcbcae84e4e04e@haskell.org> Message-ID: <061.c39cad8e074934674312fd33bdec5dbe@haskell.org> #14300: FreeBSD 10.3 toolchain is terribly broken ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13974 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Description changed by bgamari: Old description: > == `ld.bfd` with `SplitSections=NO` > > Fails in the final bindist test with, > {{{ > /usr/bin/install -c -m 755 libraries/gen_contents_index "/usr/home/ben > /bin- > dist-8.2.1.20170929-FreeBSD/test/inst/share/doc/ghc-8.2.1.20170929/html/libraries/" > [1 of 1] Compiling Main ( /usr/home/ben/bin- > dist-8.2.1.20170929-FreeBSD/test/hi.hs, /usr/home/ben/bin- > dist-8.2.1.20170929-FreeBSD/test/hi.o ) > Linking /usr/home/ben/bin-dist-8.2.1.20170929-FreeBSD/test/hi ... > /usr/bin/ld: Base__199.o: access beyond end of merged section (-24) > /usr/bin/ld: Base__201.o: access beyond end of merged section (-24) > ... > }}} > > == `ld.bfd` with `SplitSections=YES` > > fails with, > {{{ > bindisttest/"install dir"/bin/ghc --make bindisttest/HelloWorld > [1 of 1] Compiling Main ( bindisttest/HelloWorld.lhs, > bindisttest/HelloWorld.o ) > Linking bindisttest/HelloWorld ... > /usr/home/ben/bin-dist-8.2.1.20170929-FreeBSD/ghc/bindisttest/install > dir/lib/ghc-8.2.1.20170929/base-4.10.0.0/libHSbase-4.10.0.0.a(Base.o):base_ControlziExceptionziBase_absentError_info: > warning: relocation refers to discarded section > /usr/home/ben/bin-dist-8.2.1.20170929-FreeBSD/ghc/bindisttest/install > dir/lib/ghc-8.2.1.20170929/base-4.10.0.0/libHSbase-4.10.0.0.a(Base.o)(.text.r3zN_info+0x44): > warning: relocation refers to discarded section > /usr/home/ben/bin-dist-8.2.1.20170929-FreeBSD/ghc/bindisttest/install > dir/lib/ghc-8.2.1.20170929/base-4.10.0.0/libHSbase-4.10.0.0.a(Base.o)(.text.r3zP_info+0x44): > warning: relocation refers to discarded section > /usr/home/ben/bin-dist-8.2.1.20170929-FreeBSD/ghc/bindisttest/install > dir/lib/ghc-8.2.1.20170929/base-4.10.0.0/libHSbase-4.10.0.0.a(Base.o)(.text.r3zR_info+0x44): > warning: relocation refers to discarded section > ... > }}} > > == `ld.gold`, `SplitSections=NO` > > {{{ > ... > }}} New description: == `clang`, `ld.bfd` with `SplitSections=NO` Fails in the final bindist test with, {{{ /usr/bin/install -c -m 755 libraries/gen_contents_index "/usr/home/ben /bin- dist-8.2.1.20170929-FreeBSD/test/inst/share/doc/ghc-8.2.1.20170929/html/libraries/" [1 of 1] Compiling Main ( /usr/home/ben/bin- dist-8.2.1.20170929-FreeBSD/test/hi.hs, /usr/home/ben/bin- dist-8.2.1.20170929-FreeBSD/test/hi.o ) Linking /usr/home/ben/bin-dist-8.2.1.20170929-FreeBSD/test/hi ... /usr/bin/ld: Base__199.o: access beyond end of merged section (-24) /usr/bin/ld: Base__201.o: access beyond end of merged section (-24) ... }}} == `clang`, `ld.bfd` with `SplitSections=YES` fails with, {{{ bindisttest/"install dir"/bin/ghc --make bindisttest/HelloWorld [1 of 1] Compiling Main ( bindisttest/HelloWorld.lhs, bindisttest/HelloWorld.o ) Linking bindisttest/HelloWorld ... /usr/home/ben/bin-dist-8.2.1.20170929-FreeBSD/ghc/bindisttest/install dir/lib/ghc-8.2.1.20170929/base-4.10.0.0/libHSbase-4.10.0.0.a(Base.o):base_ControlziExceptionziBase_absentError_info: warning: relocation refers to discarded section /usr/home/ben/bin-dist-8.2.1.20170929-FreeBSD/ghc/bindisttest/install dir/lib/ghc-8.2.1.20170929/base-4.10.0.0/libHSbase-4.10.0.0.a(Base.o)(.text.r3zN_info+0x44): warning: relocation refers to discarded section /usr/home/ben/bin-dist-8.2.1.20170929-FreeBSD/ghc/bindisttest/install dir/lib/ghc-8.2.1.20170929/base-4.10.0.0/libHSbase-4.10.0.0.a(Base.o)(.text.r3zP_info+0x44): warning: relocation refers to discarded section /usr/home/ben/bin-dist-8.2.1.20170929-FreeBSD/ghc/bindisttest/install dir/lib/ghc-8.2.1.20170929/base-4.10.0.0/libHSbase-4.10.0.0.a(Base.o)(.text.r3zR_info+0x44): warning: relocation refers to discarded section ... }}} == `clang`, `ld.gold`, `SplitSections=NO` {{{ ... }}} -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14300#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 30 20:38:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Sep 2017 20:38:45 -0000 Subject: [GHC] #14299: GHCi for GHC 8.2.1 crashed with simple function? In-Reply-To: <048.a4a45b6e4f4301891e63f7e5dbc2d991@haskell.org> References: <048.a4a45b6e4f4301891e63f7e5dbc2d991@haskell.org> Message-ID: <063.512f3861829b785b84fae850da7114f6@haskell.org> #14299: GHCi for GHC 8.2.1 crashed with simple function? -------------------------------+-------------------------------------- Reporter: mathiassm | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 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 mathiassm): Hello! Yes, I just learned about indentation problems one can run into writing Haskell. My intention was to have those three as a single definition for `f`, which I now accomplish with a multiline using the let syntax, as you stated. So that part was just my Haskell inexperience (plus the incorrect definition of factorial, my bad!). Now, I supposed the exception could be caused by only defining `f n`, but as I'm testing that, it doesn't happen; it understandably throws a stack overflow exception. It still hangs on the call to `f 0` and throws the MVar error (whatever that is). It doesn't seem to happen elsewhere, if I follow the correct indentation rules (and now I `:set +m` for convenience)... I'm sorry but I can't find another way to reproduce this, but following those simple statements /: I suppose it's my installation (maybe Homebrew failed compiling it, or downloading the binaries...) Thank you for your time (and sorry!) PD. The "instructions" I followed was the "Please report this bug" message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14299#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 30 20:40:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Sep 2017 20:40:08 -0000 Subject: [GHC] #14299: GHCi for GHC 8.2.1 crashed with simple function? In-Reply-To: <048.a4a45b6e4f4301891e63f7e5dbc2d991@haskell.org> References: <048.a4a45b6e4f4301891e63f7e5dbc2d991@haskell.org> Message-ID: <063.542d44375322e1ce7d1bc8550d5b4f0f@haskell.org> #14299: GHCi for GHC 8.2.1 crashed with simple function? -------------------------------+-------------------------------------- Reporter: mathiassm | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 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 mathiassm): Hello! Yes, I just learned about indentation problems one can run into writing Haskell. My intention was to have those three as a single definition for f, which I now accomplish with a multiline using the let syntax, as you stated. So that part was just my Haskell inexperience (plus the incorrect definition of factorial, my bad!). Now, I supposed the exception could be caused by only defining f n, but as I'm testing that, it doesn't happen; it understandably throws a stack overflow exception. It still hangs on the call to f 0 and throws the MVar error (whatever that is). It doesn't seem to happen elsewhere, if I follow the correct indentation rules (and now I :set +m for convenience)... I'm sorry but I can't find another way to reproduce this, but following those simple statements /: I suppose it's my installation (maybe Homebrew failed compiling it, or downloading the binaries...) Thank you for your time (and sorry!) PD. The "instructions" I followed was the "Please report this bug" message. Replying to [comment:2 bgamari] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14299#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 30 21:30:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Sep 2017 21:30:12 -0000 Subject: [GHC] #14299: GHCi for GHC 8.2.1 crashed with simple function? In-Reply-To: <048.a4a45b6e4f4301891e63f7e5dbc2d991@haskell.org> References: <048.a4a45b6e4f4301891e63f7e5dbc2d991@haskell.org> Message-ID: <063.0c575ad97561f681fee67e808a1775f6@haskell.org> #14299: GHCi for GHC 8.2.1 crashed with simple function? -------------------------------+-------------------------------------- Reporter: mathiassm | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 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 bgamari): Well, it definitely seems like there is a bug here regardless of whether or not I can reproduce it. `MVar`s are mutable variables generally used in concurrent settings, so there is definitely the potential for bugs here. > Thank you for your time (and sorry!) No need to be sorry! Thanks for reporting the bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14299#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Sep 30 22:10:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Sep 2017 22:10:25 -0000 Subject: [GHC] #14299: GHCi for GHC 8.2.1 crashed with simple function? In-Reply-To: <048.a4a45b6e4f4301891e63f7e5dbc2d991@haskell.org> References: <048.a4a45b6e4f4301891e63f7e5dbc2d991@haskell.org> Message-ID: <063.3f45d5a1d16ae140c2bc4211226ea697@haskell.org> #14299: GHCi for GHC 8.2.1 crashed with simple function? -------------------------------+-------------------------------------- Reporter: mathiassm | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 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 bgamari): I'll admit I've looked through the `ghci` implementation and all of the `MVar` operations look exception-safe (which is likely the cause of the failure). I have a hard time believing that the issue lies in `ghc` itself, but I don't see much alternative. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14299#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler